Windows DNA and COM Overview Mark Ryland Senior Technical Evangelist Microsoft Corporation Outline Windows DNA Overview Enhancing the system service platform: Windows NT 5.0 COM Review and Drilldown Microsoft Transaction Server COM Futures Windows DNA Distributed InterNet Architecture: a context for application development Building on Win32, DHTML, TCP/IP suite Adding rich new NT5 system services DS, class store, richer security, etc. COM is the universal service packaging and code deployment technology Interconnected to heterogeneous world via standard data formats, protocols IP, HTTP, [D]HTML, ODBC, SSL, X.509/PKI, LDAP, Kerberos, IPSEC, XA, XML, etc. Windows DNA Unified Model for 1st, 2d-Nth Tier Broadest DHTML DHTML client support via ASP, SSL, Scripting Scripting ECMAScript DHMTL, Java Components Components Standard Protocols Integrate (HTTP, with UNIX, DCOM, etc.) mainframes via standard Data Access... Data Access... Transactions Transactions Presentation Presentation APIs and Directory Directory Security Security protocols (ODBC/XA, DCOM, Kerberos, LDAP, LU6.2, Client System Services Server System Services IIOP, etc.) Windows NT 5.0 Services Directory services (client view) LDAP-based wire protocol Standard schemas were available; NDS compatibility; complete extensible COM-based programming model (ADSI); fully scriptable in ECMAScript, VB Script; LDAP C API available Accessible via HTTP/HTML NT5 Services… Directory services (server view) Multi-master replicated database maintained on all DCs (no more PDC) Loosely coupled; configurable events (e.g., password change) can force sync Superset of NT4 domain model; rich backwards compatibility Hierarchical domain model; automatic parent, child, transitive trust Domain scaling (100s of thousands of users), OUs (sub-domain admin) allow single domain enterprise NT5 Services… Kerberos/PKI security Kerb V private key for “NOS” security Known, trusted protocol; provides key features such as account lockout Athena-interoperable (but not DCE) But PKI interwoven throughout Certificate Server bundled Each user object has standard PK properties Certs can be mapped to NT users; groups Basic key management, distribution features Integrated private/public key features make secure “extranets” a reality NT5 Services… Many, many others CIFS-based DFS; filesystem replication; site-based replica selection Integrated admin via Microsoft Management Console (COM-extensible, scriptable admin shell) VLM support on Alpha, Merced (full 64-bit coming soon after 5.0) Plug-n-Play (dynamic driver model=no rebooting) IE5 shell COM: Third Generation Components Unified programming model Between OS, apps — unification of system “objects” and variety of app models Between in-process and remote interaction — unification of DLLs and RPC Binary deployment, connection Software pieces or “components” find and connect through clearly defined interfaces Solves some basic problems of integration, independent evolution Initial COM Principles Binary components Any programming language No centralized authority for dispensing names Any location (in-proc, x-proc, x-machine) Simplest model possible Component-managed lifetimes (refcounts) Enable extensibility and adaptability Zero performance sacrifice for in-proc No official “language bindings” COM Basics Servers expose features through collections of methods in strongly- typed “interfaces” Interfaces named with UUIDs Implementations named with UUIDs Types (categories) named with UUIDs Clients call methods as indirect functions through “interface pointers” Normally, object stateful; methods act it New objects created by class factories N Interfaces Per Object Each object has one or more interfaces Ability of an object to “publish” multiple interfaces used to solve three previously distinct problems: Extensibility—how to add discoverable “non- standard” features without risk to ignorant clients Multiple interface inheritance—how to behave like two or more other objects Versioning—how to support both old and new clients safely (or fail gracefully) Strange at first, yet simple and elegant Structure of the COM “ORB” Components and Applications The COM Runtime Core Services (Automation, Monikers, Storage, ComCat, Data Transfer, etc.) COM and Distributed COM Registry Pluggable Security MS-RPC (SSPI) Pluggable Transports NTLM DCE Kerberos ETC... TCP UDP IPX SPX HTTP “Falcon” Sketch of COM Architecture Server Surrogate DLL (EXE) e.g., Server dllhost.exe Client of Interfaces Boundary Boundary interfaces Network Process Foo_1 Interfaces Foo_2 Bar_1 DLL Bar_2 Server Interfaces DLL Foo_1 Server Foo_2 (Proxy) Interfaces Stub DLL DLL Bar_1 for Server Bar_2 Interfaces Stub DLL (Proxy) Bar_1 for Interfaces Bar_2 Interfaces Foo_1 Foo_1 Foo_2 Foo_2 DCE-compatible RPC COM Peer-to-Peer Model DLL Server Process/Network Server Proxy auto- Interface Client of Interfaces created for Bar_1 Boundary interfaces Foo_1 incoming IP; Foo_2 receiver can start calling Client Foo_2 IP as Interface out param Foo_2 in Bar_1 call Stub DLL DLL for Server DLL Interface (Proxy) Server Foo_2 Interface Stub DLL (Proxy) Foo_2 for Interface Interface Bar_1 Bar_1 Proxy to non-COM Servers Server Process/Network DLL Process/Network Server (EXE) Client of Interfaces Boundary Boundary interfaces Foo_1 Foo_2 Interfaces Bar_1 Bar_2 Arbitrary DLL Server Network (Proxy) Server or Interfaces Stub DLL Service Bar_1 for DLL Bar_2 Interfaces Server Bar_1 Interfaces Bar_2 Foo_1 Foo_2 Arbitrary wire protocol (e.g., HTTP) Standard Marshaling IUnknown Stub IUnknown for IUnknown IMarshal Process/Network Proxy Manager Boundary Stub IFoo IRPCProxy for IFoo IFoo Proxy Server for IFoo IBar object Stub IBar for IBar Proxy for IBar IRPCStub Channel Channel, call object, call control, stub IRPCChannel control manager MIDL Makes it Easy IDL not a necessity, “just” a (very very very useful) convenience Generated marshaling code packaged in proxy/stub COM objects per interface Straightforward transformation into pure DCE-compatible IDL Generated proxies use NDR for marshaling, support complex types Also generates type library for runtime type information (tools) Typelibs can also provide marshaling Custom Marshaling IUnknown IUnknown Process/Network Proxy Manager Stubs Boundary for IFoo Iunknown, Server IFoo IFoo object Proxy for IFoo IRPCStub IUnknown IFoo Magic happens Custom Proxy for IFoo IFoo IMarshal Server Channel Channel, call object object, call control, stub control manager IMarshal IRPCChannel Proxy to Proxy Marshaling IFoo Proxies implement Object Bar IMarshal and create special objrefs that connect directly to server, not to proxy IFoo Proxy for IFoo Object Bar Proxy for IMarshal Object Bar IFoo as out param IMarshal from client Object Blat Proxy for Object Blat COM and Threading Object systems often leave undefined object<->thread relationship COM provides two models: Single-threaded apartment (0->N per proc) Objects associated with particular OS thread, all calls delivered on that thread Integrates with USER32 concurrency model Multi-threaded apartment (0->1 per proc) Classic RPC-style free-threaded model; calls delivered by runtime-managed pool of worker threads Exceptions All COM methods return HRESULTs 32/64 value with success/error/info bits On error, Stub QIs for ISupportErrorInfo (per interface, not per object or per method) GetErrorObject() as created by callee (today from TLS, in future from call object) Marshals error object by-value as extent On client, proxy unmarshals error object Client can QI for ISupportErrorInfo, then same dance as stub (GetErrorObject(), etc.) VB, MS JVM do this automatically COM Security Class may be launched as different security principals Start as X (including service/daemon) Start as current interactive user Start as caller Launching, connection access controls ACL covering who can launch class (EXE or surrogate/DLL) ACL covering who can access a running object in a given process (AppID) Security… Session-level and call-level security Authenticating, signing, sealing per call/connection (same as DCE RPC) “Automatic” security: COM enforces (per process) Or “raw” server-implemented security —thread-level auth, impersonation Installable security providers RPC runtime uses SSPI (GSS-like API) Common provider negotiated by COM Win NT, (soon) SSL, Kerb providers Distributed GC protocol Optional (on by default); allows objects to distinguish between quiescent and dead clients Efficient -- very small keep-alive messages bundled for all connections between machines Server maintains only count, no knowledge of clients Optimized network expression of Addref/Release Turn off with two lines of code (in C/C++) Client Machine Keep-alive packet every 2 Server Machine minutes for all Client proc #1 connections Server (N procs) Client proc #2 What is Microsoft Transaction Server? A runtime for building scalable server/ mid-tier applications A pragmatic combination of Distributed component and transaction processing technology An enabler of high-performance 3-tier client/server computing Vastly simplifies common server tasks Provides good performance on server without explicit multi-threading What is MTS?… Distributed Transaction Coordinator DTC coordinates transactions across heterogeneous resources Runtime (MTX.DLL) and surrogate (MTX.EXE) for COM components Automatic transactions; automatic security roles; JIT activation An administration tool (MTS Explorer) and management infrastructure Where Do You Get It? MTS 2.0 shipping today integrated with Internet Information Server 4.0 as part of Windows NT Option Pack Downloadable free or by CD for $99 MTS 3.0 bundled with Windows NT 5.0 IIS 4.0 integration is fundamental, critical Transactional web sites via script development in Active Server Pages Shared thread pooling, state management between IIS and MTS Programming In The Middle Browser Windows Context New order Who am I? Am I secure? What thread am I on? What transaction am I in? Write “single user” components How do I pass transactions? Sales inventory Call the MTS ContextObject How do I protect my data? MTS manages context How do I clean up failures? IBM Microsoft DB2 SQL Server on AIX MTS Programming is Simple: One Object Call, Three Methods Access my Set ctxObject = GetObjectContext() context YOUR CODE YOUR CODE “Call another Set objfoo = ctxObject.CreateInstance() No TX code object, it gets YOUR CODE No thread code my context” YOUR CODE No locking code etc. ctxObject.SetComplete I am happy: reuse and commit ctxObject.SetAbort I am in trouble: clean things up Three Big Ideas 1) Scalable applications share Remember very little in the server Tell MTS when you are done 2) Context describes the client “Guardian angel” Automatically flows with the client’s work Count on MTS and it’ll be there 3) Transactions make it easier They clean up after failures Three Important Methods 1) CreateInstance (“class”) Create a new component instance inheriting context from creator 2) SetComplete Time to discard state; component is happy 3) SetAbort Time to discard state; component is unhappy MTS should clean up the state These are methods on context object Scalable = Managed State Scalable means lots of clients Want to add more clients and get support from the server Less state per client means more clients per server Trick #1: Use very little state per client Trick #2: Spread work across many servers Automatic Transactions Enables Composition Transaction property set declaratively Requires - create a transaction if not already in one Requires New - create a new transaction always Supported - doesn’t need a transaction, can run in one Not Supported - don’t run in a transaction Automatic transactions begin or enlist when component is activated ADO/OLE DB and Recordsets Recordsets help minimize server state Pass data to client, forget in server Return the Recordset to client Update the Recordset Pass back to server “Optimistic concurrency control” Changes applied if no conflicts Allows efficient two-tier like data browsing in three-tier applications COM Futures Provide richer distributed programming features, infrastructure Provide better support for DCOM on the Internet (firewall, proxy, security issues) Rich asynchronous calling support: Async, Real-Enough Time calls Provide load-balancing, failover, recovery support Collapse COM/MTS distinction Extensible context object generally useful Integrated admin with COM Explorer Futures... Tighter language integration, runtime services Higher-level language binding for C++ eliminates “gunk” coding Standard datatypes to eliminate today’s Automation/COM dichotomy System-supplied (but replaceable) implementations of class factories, events, IDispatch (plus DSI) System code between in-proc components allows automatic ref-counting, GC as well as MTS-style features everywhere Futures... Rich meta-data allows integration of component state w/ COM services Provides Automatic marshaling support Automatic persistence Declarative or programmatic marshal-by- value for objects Declarative event models Declarative transactional behavior for properties Resources Great Overview Book Understanding ActiveX and OLE (by David Chappell) Technical info Inside COM (book by Dale Rogerson) New COM book by Don Box http://www.microsoft.com/com; /workshop/; /oledev/; /transaction/ COM+ articles in MSJ at http://www.microsoft.com/msj/1197/complus.htm http://www.microsoft.com/msj/1297/complus2/complu s2.htm Resources... Implementations Win95 COM upgrade including DCOM http://www.microsoft.com/oledev Also bundled with IE 4.0 Solaris and other non-Win32 versions of COM/DCOM http://www.sagus.com Mailing lists Sign up for DCOM, ATL mailing lists at: http://www.microsoft.com/workshop/resources/email.htm This talk: ftp://ftp.microsoft.com/developr/drg/com/OpenGIS.ppt Windows DNA and COM Overview Questions?