Application Servers G22.3033-011 Session 5 - Main Theme Object Management Architectures Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Agenda COM and COM+ Introduction to .Net Component Technologies Object Management Architectures Java-Based Application Servers Windows Services Summary Readings Assignment #5 2 1 Summary of Previous Session CORBA Inprise VisiBroker Environment Orbacus RMI and RMI-IIOP DCOM DOC Platform Interoperability Web-Enabled DOC Applications Summary Readings Assignment #4 3 Application Servers Architectures Application Servers for Enhanced HTML (traditional) a.k.a., Page-Based Application Servers Mostly Used to Support Standalone Web Applications New Generation Page-Based Script-Oriented App. Servers First Generation Extensions (e.g., Microsoft IIS with COM+/ASP) Servlet/JSP Environments XSP Environment Can now be used as front-end to enterprise applications Hybrid development environments Distributed Object Computing Platforms Provide an infrastructure for distributed communications enabling Still need to merge traditional web-oriented computing with object computing Object Management Architectures 4 DOC Platform + APIs to reusable services and facilities 2 Part I COM and COM+ 5 COM Overview • COM history • COM fundamentals: client and server communication • Interfaces in COM • How objects are created in COM 6 3 COM history • 1988: Seed work for COM began inside MS – Influenced by prior work done in Smalltalk, C++, and OSF Distributed Computing Environment (DCE) • OLE(Object Liking and Embedding) – solved the problem of compound documents • DDE(Dynamic Data Exchange) – allowed applications to communicate, but had bad performance 7 COM History (continued) • 1993: First public release of COM as part of OLE 2.0 SDK – provided automation – but local communications & 16-bit/single-threaded only • 1994: Windows NT 3.5 ships – 32-bit support + Interface Definition Language – upgraded for better performance – provided multiple thread support 8 4 COM History (continued) • 1992: Work begins on “Viper” project – First artifact is Distributed Transaction Coordinator (DTC) that ships with SQL Server • 1996: Windows NT 4.0 – DCE-based Distributed COM (DCOM) protocol – Better threading/security support • 1996: Microsoft Transaction Server (MTS) 1.0 – Component-based Distributed Application Framework • 1998: Windows NT 4.0 Option Pack – MTS 2.0,MSMQ 1.0, Internet Information Server 4.0 • 2000: Windows 2000 – MTS/COM Integration, new MTS-esque services, Improvements to the remoting infrastructure 9 3 fundamental ideas of COM/COM+ • Clients program in terms of interfaces, not classes • Implementation code is not statically linked, but rather loaded on-demand at runtime • Developers declare their runtime requirements and the system ensures that these requirements are met • The former two are the core of classic COM • The latter is the core of MTS and COM+ 10 5 Using COM • COM is used primarily for two tasks • Task 1: Gluing together multiple components inside a process – Class loading, type information, etc • Task 2: Inter-process/Inter-host communications – Object-based Remote Procedure Calls (ORPC) • Pros: Same programming model and APIs used for both tasks • Cons: Same programming model and APIs used for both tasks • Design around the task at hand 11 COM basics IUnknown IClassFactory Class Factory Client Object Registration Packaging Component 12 6 COM vocabulary • Interface - abstract data type used by clients to talk to objects • Class - concrete data type written by developers to support one or more interfaces • Object - entity in memory that supports one or more interfaces (typically an instance of a class) • Component - loadable code module that exposes one or more COM classes • GUID - 128-bit identifier used to name an interface(IID) or a class(CLSID) 13 Expanded Definitions • Two key terms have been defined so far • A COM Interface is a collection of abstract operations one can perform on an object – Must extend IUnknown directly or indirectly – Identified by a UUID (IID) – Platform-specific vptr/vtable layout • A COM Object is a collection of vptrs in memory that follow the COM identity laws – Must implement at least one COM interface – QueryInterface ties vptrs together into cohesive object • Objects assumed to materialize automatically 14 7 Expanded Definitions (continued) • A COM Class (or coclass) is a named body of code that can be used to produce COM objects • All coclasses are named by a UUID (CLSID) • All coclasses have a distinguished object that is used to create new instances – Called a class object or class factory – Typically implements IClassFactory • All coclasses loaded on demand by class loader – Called the Service Control Manager or (SCM) • For efficiency, a single component DLL can support multiple COM classes 15 Classes, Class Objects, And Components Component DLL Class Instances Class A Class B Class C Class Objects 16 8 Class Versus Type • An Interface represents a data type suitable for declaring variables – Non-trivial operations – Hierarchical with respect to one another – Polymorphic with respect to different objects • A Class represents loadable concrete code used to create objects – Resultant objects implement one or more interfaces • Class unsuitable for declaring variables – Entire motivation for interface-based programming based on relative uselessness of class 17 Class Versus Type IAnimal IMammal IDog ICat IBird Interfaces Classes DogCat Robin Pug Siamese Parrot 18 9 3 types of servers in COM Local COM Server In-Process Server (DLL) DCOM Remote Client Application Server Computer A Computer B 19 COM Proxies and stubs Client Server Proxy Stub RPC DCOM/COM DCOM/COM 1. Use midl compiler to generate necessary files 2. Files generated by midl compiler are packaged in a DLL with make command 3. Register your proxy-stub DLL in the system registry with regsrv32 command 4. The proxy-stub DLL must be installed on every machine 20 10 Interfaces in COM • An interface is not a class – cannot be instantiated, different classes can implement it differently • Interfaces are strongly typed – every interface has it’s globally unique identifier(GUID) • Interfaces are immutable – cannot delete, any change considered to be a new interface • Clients only interact with pointers to interfaces – pointers hide all aspects if implementation • Objects can implement multiple interfaces 21 Interface Architecture Interface component pointer Vtable function1 Pointer to Function1 Vtable pointer Pointer to Function2 function2 Pointer to Function3 function3 COM interface is a binary description of the layout of a block of memory containing an array of function pointers(vtable). The pointers of the array point to the functions of a COM object that can be called by a consumer of the interface 22 11 Standard and Custom Interfaces • Standard interface IUnknown • Has 3 functions: – ULONG AddRef(); object – ULONG Release(); – HRESULT QueryInterface(REFIID riid, void **ppvObject); • All objects will have at least two interfaces: IUnknown and a custom interface • Custom interfaces are derived from IUnknown 23 Defining interfaces with IDL // File Ch3CompCppServer.idl : This file will be processed by the MIDL tool to produce the type library // Ch3CompCppServer.tlb and marshalling code. [ uuid (B5F3E2FE-B376-11D1-BB1E-00207812E629) ] interface IAccount : Iunknown attributes { [propget, helpstring("property Balance")] HRESULT Balance ([out, retval] double *pVal); [propget, helpstring("property Name")] HRESULT Name([out, retval] BSTR *pVal); }; •Every interface method must return HRESULT •32bit integer divided into 3 fields •0-15bits indicate severity •16-30 facility (RPC, Win32 etc) •1 bit to indicate success or failure 24 12 Defining interfaces with IDL (continued) //File Ch3ComCppServer.idl continued [ uuid (B5F3E2F0-B376-11D1-BB1E-00207812E629) ] library CH3COMCPPSERVERLib //will produce a type library - file that describes an object in a //standardized format to show what properties are supported { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [ uuid (B5F3E300-B376-11D1-BB1E-00207812E629) ] coclass Ch3CheckingAccount // Ch3CheckingAccount Class { interface IAccount; interface IAccountInit; [default] interface ICheckingAccount; }; }; //after type library is created it’s location is registered in the system registry 25 COM client using an object 1. Identify the class of object to use. 2. Obtain the “class factory” for the object class and ask it to create an uninitialized instance of the object class, returning an interface pointer to it. 3 Initialize the newly created object by calling an initialization member function of the “initialization interface,” that is, one of a generally small set of interfaces that have such functions. 4 Make use of the object which generally includes calling QueryInterface to obtain additional working interface pointers on the object. The client must be prepared for the potential absence of a desired interface. 5 Release the object when it is no longer needed. 26 13 COM client using an object (continued) Step1: Identify the class of object to use • A Client has a CLSID (Class Identifier) of a class it needs • All CLSIDs are stored in the registry HKEY_CLASSES_ROOT CLSID {E312522E-A7B7-11D1-A52E-0000F8751BA7}="Foo Class" InprocServer32="D:\\ATL Examples\Foo\\Debug\\Foo.dll" • Client need not know nor care how this information is maintained 27 COM client using an object (continued)