CORBA, DCOM and Java

1. CORBA, DCOM and Java V. “Juggy” Jagannathan CareFlow|Net, Inc.

2. CORBA Distributed Object Infrastructure

3. References • Robert Orfali, Dan Harkey, “Client/Server Programming with Java and CORBA, Second Edition.” John Wiley and Sons, 1998. • Andreas Vogel and Keith Duddy, “Java Programming with CORBA, Second Edition, Advanced Techniques for Building Distributed Applications,” John Wiles and Sons, 1998. • John Siegal (written and edited by), “CORBA Fundamentals and Programming,” John Wiley and Sons, 1996.

4. Outline • Overview • CORBA 1.1, 2.0, 3.0 • IDL and Interface Repository • CORBA services

5. Background* • Not-for-profit company based in United States, with representation in Italy, United Kingdom, Germany, Japan, Australia & India. • Founded April 1989. • Small staff (35 full time); no internal development. • Almost all technical work done by engineers in member companies • Almost 800 members (4/98) * Viewfoil courtesy OMG: http://www.omg.org/library/diego.ppt

6. Worldwide Scope * Andersen APM Alta AITECH AT&T BaaN Bull British Telecom Bankers Trust Sun Microsystems Sybase Thomson CSF Telecom Italia Telefonica Telia AB TRW Unisys Valtech……. ICL Informix Intel IBM IONA Tech. Microsoft MITRE Netscape Nortel Novell OHRA Insurances Oracle Open Group POSC Sodalia Siemens Nixdorf Software AG Data Access Eurocontrol EDS Ericsson FinSiel Fujitsu Genesis HP Harlequin * Viewfoil courtesy OMG: http://www.omg.org/library/diego.ppt

7. Adoption Process * • RFI (Request for Information) to establish range of commercially available software. • RFP (Request for Proposals) to gather explicit descriptions of available software; Architecture Board approves. • Letters of Intent to establish corporate direction. • Task Force evaluation & recommendation; simultaneous evaluation by Business Committee. • Architecture Board consideration for consistency. • Board decision based on recommendations from the appropriate Technology Committee & Business Committee. • Fast Track Process. * Viewfoil courtesy OMG: http://www.omg.org/library/diego.ppt

8. Integration Technology - CORBA • The Common Object Request Broker Architecture is the standard adopted by OMG as a framework to provide common ORB services and interfaces to support portable clients and services. • The Object Request Broker (ORB) provides the mechanisms by which clients transparently make requests and receive responses.

9. CORBA (continued) • Advantages offered by CORBA: • architecture independence • language independence • location independence • The standard specifies the Interface Definition Language (IDL) - language used to describe the interfaces that client objects call and object implementations provide.

10. De-facto Standards and products available* - Manufacturing: - Electronic Commerce: - Healthcare: -Telecommunications: - Finance -Transportation - ….. - Architecture guide and roadmap - Working on Internet facilities. CORBAdomains CORBAfacilities CORBA applications CORBA 2 (IIOP) - Naming - Security (...ICL) - Transactions (..Bull) - Query Service - Persistence - Lifecycle - ORBIX - IONA - Obj Broker BEA - VisiBroker Borland - Omni Orb Olivetti - Component Broker IBM CORBAservices * Viewfoil courtesy OMG: http://www.omg.org/library/diego.ppt

11. The Evolution of CORBA* • CORBA 1.1 (1992) • Basic ORB, IR, BOA, C Bindings, Naming, Events, Lifecycle etc. • CORBA 2.0 (1995) • IIOP, Federated IR, C++ Bindings, Transactions, Concurrency, Externalization, Relationships, Query, Licensing, Trader, Security, Collections, Time etc. • CORBA 3.0 (1999) • Messaging (MOM), Server Portability (POA), Business Objects (JavaBeans), Java Bindings, Objects-by-value, CORBA/DCOM, IIOP Firewall, Workflow, Domain-level Frameworks, Mobile Agents etc. * Adapted from Orafali and Harkey’s Book

12. ORB services • Multiple language bindings - C, C++, Java, Smalltalk, Ada, Cobol • Interface Repository stores the interface specifications of all services • Transparency of object location

13. ORB services - Contd • Object-oriented - provides for encapsulation, polymorphism and inheritance • Can provide security for content and context-sensitive transactions

14. Common Object Service Specification 1(COSS1) • Life cycle service - for instantiating, copying, moving and deleting objects • Persistence service - interface for storing objects - relational and OODBMS backends - Deprecated. • Naming service - to locate using OSF DCE, Sun NIS or X.500 naming conventions. Can work with Internet standards such as LDAP. • Event Service - dynamically register interest in events - using a global object called event channel

15. COSS2 • Concurrecny control service - to provide for locking • Transaction service - to provide for two-phase commit coordination • Relationship service - to connect and group multiple objects • Externalization service - to export and interchange data

16. COSS3 • Security • Time management

17. CORBA Architecture C++ Java Ada C other C++ Java Ada C other Client Requests IDL-based Servers Server Clients Service IDL-based ORB

18. COSS4 • Query service - it is a superset of SQL based on the Object Database Management Group (ODMG) • Licensing service - to support metering and support for payment for use of components • Properties service - to associate dynamic properties with components

19. COSS5 • Trader • Collections • Change management

20. CORBA 2.0 • Adds multivendor ORB interoperability to CORBA 1.1 specifications adopted in 1991 • An ORB mediates requests for services from client applications and service providers

21. Client/Server Request Using the ORB 2.0 Object Implementations Client Implementation Repository Static Skeletons Dynamic Skeletons Client IDL Stubs ORB Inter- face Dyamic Invoc- ation Interface Repository Object Adapter Object Request Broker

22. Client IDL Stubs • Provides local proxies for remote services • Provides for marshaling of parameters into standard formats

23. Dynamic Invocation Interface • Late binding of method calls • Run time discovery of service IDL interface

24. Interface Repository • Runtime database of interfaces of all registered objects • Supports the query of, registration of, and update of interfaces of objects mediated by the ORB • Repository IDs - uniquely and globally identify interface repository across multivendor ORBs

25. ORB Interface • Provides for API that provide a number of utilities: • Object-to-string : converts object reference to a string • String-to-object : converts a string reference to object • get-interface : to find the location of interface repository for a given object • get-implementation: to find the reference to implementation repository of an object

26. Server IDL Stubs • Also called skeletons • provide static interfaces to each service provided • both client side and server side stubs are generated using IDL compilers

27. Dynamic Skeleton Interface (DSI) • to implement dynamic services or dynamically changing services • run-time binding of new services using scripting languages and interpreters • to redirect messages to objects for which a compiled idl-interface is not known

28. Object Adapter • responsible for managing a collection of server objects • instantiates server objects when needed and provides them with object IDs called object references • registers the classes and instances in the Implementation Repository • All CORBA implementations must support a Basic Object Adapter

29. Implementation Repository • Keeps track of classes and run-time instances of server objects supported by the ORB • Allows for mechanisms to support audit trails, trace information and security related infrastructure

30. Using the Static interface • Definition of object services using IDL • Precompiler generates server and client stubs • Implementation code added to the server stubs • Compilation: client stubs, server stubs, code that implements server classes and code to describe the classes to Interface Repository • Register with Interface Repository • Instantiate server objects • Register run time instances with Implementation Repository

31. Using the Dynamic interface • Lookup service name and get its interface specification from Interface Repository • Put together a request made up of object reference, method name and argument list • Invoke the method call on the desired object

32. Basic Object Adapter • Must provide for the following functionality: • An implementation repository • Manage instantiation and destruction of objects • Manage object references and invoking methods • Mechanism to authenticate clients

33. BOA Object Activation Alternatives • Shared Server: First time call to any object causes the server process to startup. Future requests are handled by the server directly. BOA notified with impl_is_ready and deactivate_impl. • Unshared Server: A new server process is started to support each object requests. • Server-per-method: A new server process is started for each request made (method call). • Persistent server: Servers are persistent and started independently.

34. CORBA 2.0 Interoperability Standard • CORBA 1.1 allowed for portability • CORBA 2.0 specifies the Internet Inter-ORB Protocol (IIOP) • Public domain IIOPs are now available (from Sun for instance) • Every CORBA-compliant ORB must implement IIOP or provide a half bridge to it

35. General Inter-ORB Protocol (GIOP) • Common Data Representations (CDR) used in communications • CDR maps data types defined using IDL into a flat representation for use in network layer • CDR takes care of inter-platform issues such as byte ordering • Specifies Interoperable Object References for use in multi-vendor ORB environments

36. Internet Inter-ORB Protocol (IIOP) • Standardizes the way GIOP messages can be exchanged using TCP/IP • Mandatory for CORBA 2.0 compliance

37. Environment-Specific Inter-ORB Protocols (ESIOPs) • Example is DCE/ESIOP • GIOP CDR-based messages defined using OMG IDL are transported using DCE RPC using DCE native Network Data Representation (NDR)

38. ORB-to-ORB Bridging Server Client DII DSI ORB From Vendor A ORB From Vendor B

39. IDL and Interface Repository • Interface Definition Language (IDL): fundamental mechanism supported by all ORBs to separate interfaces and implementations • Interface Repository is a queriable and updateable runtime information store of interface specification generated from IDL

40. IDL users • Client programmers who want to access the services provided by an object - they need the IDL to determine how to call the services • Server programmers who want to extend the service provided - they need the IDL to subclass and provide additional capabilities

41. IDL Structure • Module: groups a collection of class definitions (interfaces) • Interface: defines a class; attributes and exceptions • Operation: defines a method; the arguments; argument types; in, out or in-out; exceptions; optional context description • Data types: basic (short , float, char...) and constructed

42. IDL Example : type codes • typedef string Date_T; • typedef string PersonID_T; • typedef string Address_T; • typedef char MaritalStatus_T; • typedef char Sex_T; • typedef long PolicyID_T;

43. IDL Example: Interfaces • interface FamilyMember; • interface Employer; • interface InsurancePolicy; • interface InsuranceCompany;

44. IDL Example: Interface definition • interface Demographics: PRObject • { • readonly attribute PersonID_T personID; • attribute string lastName; • attribute string firstName; • attribute long SSN; • attribute Date_T DOB; • attribute string birthPlace; • attribute MaritalStatus_T maritalStatus; • readonly attribute sequence<InsurancePolicy> insurancePolicies; • readonly attribute sequence<FamilyMember> familyMembers; • readonly attribute sequence<Employer> employers; • };

45. IDL Example: Interface definition • interface InsurancePolicy: PRObject • { • readonly attribute PolicyID_T policyID; • attribute string insuranceType; • attribute string carrierProgram; • attribute long groupNo; • attribute long payorNo; • attribute long controlNo; • attribute string relationshipToPolicyHolder; • readonly attribute Demographics policyHolder; • readonly attribute InsuranceCompany insuranceCompany; • };

46. Type Codes • represent IDL-defined data types • provide for self-describing data • Used by: DII, IIOP, Interface Repositories and any data type

47. Interface Repository - where used • Run-time type checking on method invocation parameters • Connecting multi-vendor ORBs • Support dynamic discovery of object interfaces and support for DII • Provide for self-describing objects

48. Trader Service POA Workflow Business Objects Facility CORBA Component Model CORBA Scripting Language IIOP over firewall Java to IDL mapping Real-time CORBA Asynchronous Messaging Domain-specific frameworks Manufacturing, Transportation, Finance, Healthcare, Telecom, Electronic Commerce and more! CORBA 3.0 See: http://www.omg.org/news/pr98/9_9.htm for a press release on CORBA 3.0 by major vendors for an early 1999 commercial availability.

49. Trader Service ORB ORB ORB Client “Importer” • Naming Service is like white pages • Trader is like yellow pages Trader Server “Exporter” Export Service Import Service Invoke Service

50. Portable Object Adapter (POA) • To quote Orafali & Harkey: “The POA is simply the BOA done right.” • Similar to BOA, POA supports management of: • separate process for each method • separate process for each object • shared process for multiple objects • In addition, POA supports the notions of: • servants and servant managers (instance managers) • transient and persistent servants and instances • Essentially addresses scalability and flexibility in server implementations