Windows DNA and COM Overview

Document Sample
Windows DNA and COM Overview Powered By Docstoc
					 Windows DNA and
  COM Overview

       Mark Ryland
Senior Technical Evangelist
  Microsoft Corporation

 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

                      DHTML                                                                               DHTML                                                 client
                                                                                                                                                             support via
                                                                                                                                                              ASP, SSL,
                 Scripting                                                                           Scripting                                              ECMAScript
                                                                                                                                                            DHMTL, Java

                 Components                                                                          Components
                                                                                                                                                             with UNIX,
                                                                        DCOM, etc.)
                                                                                                                                                            via standard
                                                       Data Access...

                                                                                                                                           Data Access...


                                                                                                                                                              APIs and



                                                                                                                                                            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
         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
   IE5 shell
   COM: Third Generation
 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
   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
      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



                 Foo_1                 Interfaces
                 Foo_2                   Bar_1                    DLL
                                         Bar_2                   Server
                  DLL                                            Foo_1
                 Server                                          Foo_2
               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

                       Server                        Proxy auto-    Interface
Client of            Interfaces                       created for    Bar_1

interfaces             Foo_1                        incoming IP;
                       Foo_2                         receiver can
                                                    start calling
    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                        (EXE)
Client of           Interfaces

interfaces            Foo_1
                      Foo_2                        Interfaces
                     Server                                                       Network
                    (Proxy)                                                       Server or
                   Interfaces                      Stub DLL                        Service
                     Bar_1                            for
      DLL            Bar_2                         Interfaces
     Server                                          Bar_1
                   Arbitrary wire
                protocol (e.g., HTTP)
                Standard Marshaling
                                                                 Stub                       IUnknown

             Proxy Manager

                                                                       Stub          IFoo
                                                                     for IFoo
     IFoo         Proxy                                                                     Server
                 for IFoo                                                            IBar   object

   IBar                                                                 for IBar
               for IBar

                              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

           Proxy Manager

                                                                   for            IFoo
                                                               Iunknown,                 Server
   IFoo                                                           IFoo                   object
              for IFoo

                                                                  Magic happens
           Custom Proxy
             for IFoo                                                             IFoo
IMarshal                                                                                 Server
                            Channel                         Channel, call
                           object, call                     control, stub
                             control                          manager         IMarshal
Proxy to Proxy Marshaling

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
 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)
 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,
    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?

                                     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
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
    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
   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
 Collapse COM/MTS distinction
   Extensible context object generally useful
   Integrated admin with COM Explorer
 Tighter language integration, runtime
   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
 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

 Great Overview Book
    Understanding ActiveX and OLE (by David
 Technical info
    Inside COM (book by Dale Rogerson)
    New COM book by Don Box
   ; /workshop/;
     /oledev/; /transaction/
    COM+ articles in MSJ at
 Implementations
    Win95 COM upgrade including DCOM
       Also bundled with IE 4.0
    Solaris and other non-Win32 versions of
 Mailing lists
    Sign up for DCOM, ATL mailing lists at:
 This talk:
Windows DNA and
 COM Overview