1 / 41

Windows DNA and COM Overview Mark Ryland Senior Technical Evangelist Microsoft Corporation

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.

matia
Download Presentation

Windows DNA and COM Overview Mark Ryland Senior Technical Evangelist Microsoft Corporation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Windows DNA and COM OverviewMark Ryland Senior Technical EvangelistMicrosoft Corporation

  2. Outline • Windows DNA Overview • Enhancing the system service platform: Windows NT 5.0 • COM Review and Drilldown • Microsoft Transaction Server • COM Futures

  3. 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.

  4. Components Components Presentation Security Directory Transactions Data Access... Presentation Security Directory Transactions Data Access... Windows DNAUnified Model for 1st, 2d-Nth Tier Broadest client support via ASP, SSL, ECMAScript DHMTL, Java DHTML DHTML Scripting Scripting Standard Protocols (HTTP, DCOM, etc.) Integrate with UNIX, mainframes via standard APIs and protocols (ODBC/XA, DCOM, Kerberos, LDAP, LU6.2, IIOP, etc.) Client System Services Server System Services

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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”

  11. 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

  12. 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

  13. 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(SSPI) MS-RPC Pluggable Transports NTLM DCE Kerberos ETC... TCP UDP IPX SPX HTTP “Falcon”

  14. Sketch of COM Architecture Client of interfaces Server (EXE) InterfacesBar_1 Bar_2 Surrogate e.g., dllhost.exe DLL Server InterfacesFoo_1 Foo_2 Process Boundary Network Boundary DLL Server InterfacesFoo_1 Foo_2 DLL Server (Proxy)InterfacesBar_1 Bar_2 Stub DLL forInterfaces Bar_1 Bar_2 DLL Server (Proxy)InterfacesFoo_1 Foo_2 Stub DLL forInterfaces Foo_1 Foo_2 DCE-compatible RPC

  15. COM Peer-to-Peer Model Client of interfaces Server InterfaceBar_1 Client Interface Foo_2 DLL Server InterfacesFoo_1 Foo_2 Proxy auto-created forincoming IP;receiver canstart calling Process/Network Boundary Foo_2 IP as out paramin Bar_1 call Stub DLL forInterface Foo_2 DLL Server (Proxy)Interface Foo_2 DLL Server (Proxy)InterfaceBar_1 Stub DLL forInterface Bar_1

  16. Proxy to non-COM Servers Client of interfaces Server (EXE) InterfacesBar_1 Bar_2 Arbitrary Network Server or Service DLL Server InterfacesFoo_1 Foo_2 Process/Network Boundary Process/Network Boundary DLL Server (Proxy)InterfacesBar_1 Bar_2 Stub DLL forInterfaces Bar_1 Bar_2 DLL Server InterfacesFoo_1 Foo_2 Arbitrary wireprotocol (e.g., HTTP)

  17. Standard Marshaling IUnknown Stub for IUnknown IUnknown IMarshal Proxy Manager Server object Stub for IFoo IFoo IRPCProxy Process/Network Boundary Proxy for IFoo IFoo IBar Stub for IBar Proxy for IBar IBar IRPCStub Channel, call control, stub manager Channel object, call control IRPCChannel

  18. 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

  19. Custom Marshaling IUnknown IUnknown Proxy Manager Server object Stubs for Iunknown, IFoo IFoo IFoo Process/Network Boundary Proxy for IFoo IRPCStub IUnknown Custom Proxy for IFoo IFoo Magic happens Server object IFoo IMarshal Channel, call control, stub manager Channel object, call control IMarshal IRPCChannel

  20. Proxy to Proxy Marshaling IFoo Proxies implement IMarshal and create special objrefs that connect directly to server, not to proxy Object Bar IFoo Proxy forObject Bar IFoo Proxy forObject Bar IMarshal IFoo as out paramfrom client Object Blat IMarshal Proxy forObject Blat

  21. 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

  22. 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

  23. 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)

  24. 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

  25. 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 Server Machine Keep-alive packet every 2 minutes for all connections Client proc #1 Server (N procs) Logical “Connections” or “Sessions” Client proc #2

  26. 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

  27. 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

  28. 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

  29. Programming In The Middle Browser Windows ContextWho am I? Am I secure?What thread am I on? What transaction am I in?How do I pass transactions? How do I protect my data?How do I clean up failures? New order Write “single user” componentsCall the MTS ContextObjectMTS manages context Sales inventory IBMDB2 on AIX MicrosoftSQL Server

  30. MTS Programming is Simple:One Object Call, Three Methods Set ctxObject = GetObjectContext() YOUR CODE YOUR CODE Set objfoo = ctxObject.CreateInstance() YOUR CODE YOUR CODE ctxObject.SetComplete ctxObject.SetAbort Access my context No TX codeNo thread code No locking code etc. “Call another object, it gets my context” I am happy: reuse and commit I am in trouble: clean things up

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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/complus2.htm

  40. 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

  41. Windows DNA and COM OverviewQuestions?

More Related