Distributed Systems

1. Distributed Systems Topic 5: CORBA, COM and Java/RMI Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University

2. Outline • CORBA • CORBA Object Model • CORBA Interface Definition Language • CORBA Architecture • COM • Common Object Model • Microsoft IDL • COM Architecture • RMI • Java (RMI) Object Model • Interface Definition in Java • RMI Architecture

3. CORBA

4. 1.1 Who is the OMG? • Non-profit organisation with HQ in the US, representatives in United Kingdom, Germany, Japan, India, and Australia. • Founded April 1989. • More than 800 members. • Dedicated to creating and popularizing object-oriented industry standards for application integration, e.g. • CORBA • ODMG-93 • UML

5. 1.1 Goal of CORBA • Support distributed and heterogeneous object request in a way transparent to users and application programmers • Facilitate the integration of new components with legacy components • Open standard that can be used free of charge • Based on wide industry consensus

6. 1.1 Object Management Architecture Application Objects Domain Interfaces CORBA facilities Object Request Broker CORBAservices

7. 1.1 Object Model and Interface Definition • Objects • Types • Modules • Attributes • Operations • Requests • Exceptions • Subtypes

8. 1.2 OMG Interface Definition Language • Language for expressing all concepts of the CORBA object model • OMG/IDL is • programming-language independent • orientated towards C++ • not computationally complete • Different programming language bindings are available • Explanation of Model and Language by Example

9. 1.2 Running Example Organization #name:string Trainer Club uses -name:string -noOfMembers:int -location:Address 1 1..* works for +train() +transfer(p:Player) 1 1..* has coaches 1..* * Player Team -name:string -Number:int plays in -name:string 1 11..16 +bookGoalies() +book()

10. 1.3 CORBA Object Model: Objects • Each object has one identifier that is unique within an ORB • Multiple references to objects • References support location transparency • Object references are persistent

11. 1.3 CORBA Object Model: Types Constructed types Atomic types Object type typedef struct _Address { string street; string postcode; string city; } Address; typedef sequence<Address> AddressList; interface Team { ... };

12. 1.3 CORBA Object Model: Modules Modules Soccer::Address People::Address module Soccer { typedef struct _Address { string street; string postcode; string city; } Address; }; module People { typedef struct _Address { string flat_number; string street; string postcode; string city; string country; } Address; };

13. 1.3 CORBA Object Model: Attributes Clients cannot change value changeable Attribute type Attribute name interface Player; typedef sequence<Player> PlayerList; interface Trainer; typedef sequence<Trainer> TrainerList; interface Team { readonly attribute string name; attribute TrainerList coached_by; attribute Club belongs_to; attribute PlayerList players; ... };

14. 1.3 CORBA Object Model: Operations Parameter list Parameter kind Return types Parameter type Parameter name Operation name used in requests interface Team { ... void bookGoalies(in Date d); string print(); };

15. 1.3 CORBA Object Model: Requests • Requests are defined by client objects • Request consist of • Reference of server object • Name of requested operation • Actual request parameters • Context information • Request is executed synchronously • Requests can be defined • statically • dynamically

16. 1.3 CORBA Object Model: Exceptions Exception data Exception name exception PlayerBooked{sequence<Date> free;}; interface Team { ... void bookGoalies(in Date d) raises(PlayerBooked); }; Operations declare exceptions they raise • Generic Exceptions (e.g. network down, invalid object reference, out of memory) • Type-specific Exceptions

17. 1.3 CORBA Object Model: Subtypes Implicit supertype: Object Inherited by Club Supertype interface Organization { readonly attribute string name; }; interface Club : Organization { exception NotInClub{}; readonly attribute short noOfMembers; readonly attribute Address location; attribute TeamList teams; attribute TrainerList trainers; void transfer(in Player p) raises NotInClub; };

18. 1.4 Architecture Object Implementation Client Implementation Skeletons Object Adapter Dynamic Invocation ORB Interface Client Stubs ORB Core One standardised interface One interface per object operation One interface per object adapter ORB-dependent interface

19. COM

20. 2.1 Goals of COM • Provide a component object model that facilitates binary encapsulation and binary compatibility • Binary encapsulation: Clients do not have to be re-compiled if server objects change • Binary compatibility: Client and server objects can be developed with different development environments and in different languages • COM is proprietary de-facto standard

21. 2.1 Object Model and Interface Definition • Interfaces • Implementations and Objects • Classes • Attributes • Operations • Requests • HRESULTS • Inheritance

22. 2.2 Microsoft IDL (MIDL) • Language for expressing all COM concepts • MIDL is • programming-language independent • evolved from OSF/RPC IDL • not computationally complete • Different programming language bindings are available • Explanation of Model and Language by same example

23. 2.3 COM Interfaces UUID Root Interface Interfaces Interface Inheritance [object, uuid(1CF2B120-547D-101B-8E65-08002B2BD118)] interface IOrganization : IUnknown { ... }; [object, uuid(1CF2B120-547D-101B-8E65-08002B2BD116)] interface IClub : IOrganization { ... };

24. 2.3 COM Interface Implementations in C++ #include "Soccer.h" class TrainerPlayer : public Itrainer, public IPlayer { private: char* name; // name is the same in Itrainer & IPlayer short Number; //for IPlayer protected: virtual ˜TrainerPlayer(void); public: TrainerPlayer(void); IMPLEMENT_UNKNOWN(TrainerPlayer) BEGIN_INTERFACE_TABLE(TrainerPlayer) IMPLEMENTS_INTERFACE(ITrainer) IMPLEMENTS_INTERFACE(IPlayer) END_INTERFACE_TABLE(TrainerPlayer) void train(); // Itrainer method void book(); // IPlayer method };

25. 2.3 COM: Objects • Instances of COM Implementations • References to COM objects are called interface pointers • Interface pointers refer to main memory locations • References support location transparency • The references are persistent • COM allows logical identifiers to clash with each other, as the physical identifiers are uniquely generated

26. 2.3 COM Classes • Named implementations • Have one or several interfaces • Are the principal mechanism to create COM objects • Can return interface pointers to specific COM objects

27. 2.3 COM Objects, Interfaces and Classes Interface implements Implementation uuid : GUID 1..* 1..* 1 1 1..* 1..* instantiates 0..* 0..* Object location : int 0..* 0..* creates&locates implements Class ClassObject instantiates clsid : GUID 1 1 1 1

28. 2.4 COM: Attributes • COM does support attributes • Attributes must be represented as set and get operations by the designer • COM has a keyword to designate this • Example: interface IOrganization : IUnknown { [propget] HRESULT Name([out] BSTR val); };

29. 2.4 COM: Operations Parameter kind Parameter list Parameter, e.g. Interface pointer Return value indicating success/failure Operation name interface IClub : IOrganization { [propget] HRESULT NoOfMembers([out] short *val); [propget] HRESULT Address([out] ADDRESS *val); [propget] HRESULT Teams([in] long cMax, [out] long *pcAct, [out,size_is(cMax),length_is(*pcAct)] ITeam *val); [propput] HRESULT Teams([in] long cElems, [in,size_is(cElems)] ITeam *val); [propget] HRESULT Trainers([out] ITrainer *val[3]); [propput] HRESULT Trainers([in] ITrainer *val[3]); HRESULT transfer([in] IPlayer *p); };

30. 2.4 COM: HRESULTS Severity Code Facility Code Information Code Reserved 31 30-29 15-0 28-16 • HRESULTS are 32-bit integers • Structured into four fields

31. 2.4 COM Operation Invocations • Invocation is defined by client objects • Invocation determines • Interface pointer of server object • Name of invoked operation • Actual parameters • Invocation is executed synchronously • Invocation can be defined • statically • dynamically • Clients have to interpret HRESULTS!

32. 2.4 Three Implementations of Requests Inter-process call with Local Object light-weight RPC Client Object in EXE Server Method call Remote call with real RPC Object on Local Object in Remote Host In-Process DLL

33. 2.5 Architecture Server COM Class Client Application Implementation Layer Object COM Object COM Presentation Interface Interface Library Library Proxy stub Layer proxy stub SCM SCM Session Layer Registry Registry OXID Object Microsoft RPCs OXID OXID Resolver Resolver

34. Java/RMI

35. 3.1 Goals of RMI • In Java 1.0 object communication confined to objects in one Virtual Machine • Remote Method Invocation (RMI) supports communication between different VMs, potentially across the network • Provide tight integration with Java • Minimize changes to Java language/VM • Work in homogeneous environment

36. 3.2 Java Object Model • Interfaces and Remote Objects • Classes • Attributes • Operations • Exceptions • Inheritance

37. 3.3 Java Interfaces and Remote Objects • Java already includes the concept of interfaces • RMI does not have a separate interface definition language • Pre-defined interface Remote • Remote interfaces extend Remote • Remote classes implement remote interfaces • Remote objects are instances of remote classes

38. 3.3 Java Remote Interface Example Declare it as remote Package name Interface name Remote operations package soccer; Import java.rmi.*; interface Team extends Remote { public: String name() throws RemoteException; Trainer[] coached_by() throws RemoteException; Club belongs_to() throws RemoteException; Players[] players() throws RemoteException; void bookGoalies(Date d) throws RemoteException; void print() throws RemoteException; };

39. 3.4 Attributes Attribute get operations • RMI does not define attributes • Attributes must be represented as set and get operations by the designer • Example: interface Club extends Organization, Remote { public: int noOfMembers() throws RemoteException; Address location() throws RemoteException; Team[] teams() throws RemoteException; Trainer[] trainers() throws RemoteException; ... };

40. 3.4 Combining Classes and Remote Interfaces Club can return an address object Club makes name() remotely accessible interface Organization { public: String name() throws RemoteException; }; class Address { public: String street; String postcode; String city; }; interface Club extends Organization, Remote { public: int noOfMembers() throws RemoteException; Address location() throws RemoteException; Team[] teams() throws RemoteException; Trainer[] trainers() throws RemoteException; void transfer(Player p) throws RemoteException; };

41. 3.4 Parameter Passing Parameter-passing of a non-remote object: returns a copy of the Address! (call by value) • Atomic types are passed by value • Remote objects are passed by reference • Non-Remote objects are passed by value class Address { public: String street; String postcode; String city; }; interface Club extends Organization, Remote { public: Address location() throws RemoteException; ... };

42. 3.4 Exception Type-specific Exception Operation declares that it may raise it • Pre-Defined Exception RemoteException • Type-Specific Exceptions • Example: class PlayerBooked extends Exception {}; interface Team extends Remote { public: ... void bookGoalies(Date d) throws RemoteException, PlayerBooked; ... };

43. 3.5 Architecture Client Server Registry Activation Stub Skeleton Interfaces Interfaces RMI Runtime ( rmic , rmiregistry )

44. 3.5 Activation in Java Java VM Stub Java VM 2 1 2: create object Faulting in VM Reference Live Activa- 3: pass ref tion ID object ref AG AG 1 2 Activator 1: activate Activation Descriptors: ActGroup ClassName URL Init AG Team www.bvb.de/… 1 AG Player www.bvb.de/… 2 AG Player www.bvb.de/… 2 4: update AG Player www.bvb.de/… 2 live ref Client Host Host www.bvb.de

45. 4. Key Points • CORBA, COM and RMI • enable objects to request operation execution from server objects on remote hosts • identify server objects by object references • distinguish between interface and implementation • treat attributes as operations • provide mechanisms to deal with failures • have statically typed object models • compile stubs from their IDLs • support on-demand activation

46. 5. Summary • CORBA • COM • Java/RMI • Key points • Appendix (.NET)

47. A.1 XML Web Service and .NET • XML Web Service is a new solution towards distributed component interoperability. • SOAP • WSDL • UDDI • The Microsoft .NET framework is a new platform environment integrated with Windows OS. This is Microsoft’s platform for enabling XML Web Services.

48. A.2 SOAP • Simple Object Access Protocol • Web services communicate using W3C standard SOAP messages. • SOAP formalize the use of XML as a way to pass data (therefore can be Objects) from one process to another. • SOAP can be encapsulated in HTTP <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <ns:Order xmlns:ns="urn:cse.cuhk.edu.hk:Students"> <item>Bill</item> <item>Bob</item> <item>Tony</item> </ns:Students> </env:Body> </env:Envelope>

49. A.3 WSDL • Web Services Description Language (WSDL often pronounced whiz-dull) is also a W3C standard. • WSDL is an XML file for describing the web services provided. C# Implementation Example: public class MathService : WebService { [WebMethod] public float Add(float a, float b) { return a + b; } }

50. WSDL <?xml version="1.0" encoding="utf-8" ?> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/"> <s:element name="Add"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="A" type="s:float" /> <s:element minOccurs="1" maxOccurs="1" name="B" type="s:float" /> </s:sequence> </s:complexType> </s:element> <s:element name="AddResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="AddResult" type="s:float" /> </s:sequence> </s:complexType> </s:element> </types> <message name="AddSoapIn"> <part name="parameters" element="s0:Add" /> </message> <message name="AddSoapOut"> <part name="parameters" element="s0:AddResponse" /> </message> ...