Understanding CORBA: Integration Technology for Distributed Objects

1. 7. CORBA7.1. Basics What is CORBA? CORBA (Common Object Request Broker Architecture) - is an integration technology, that makes calls between objects written in different languages possible; - is a specification for creating and using distributed objects and that vendors follow to make CORBA-compliant products, i.e. product that can talk to each other following the CORBA integration technology. - it is not a programming language. What is it good for? - integrating legacy code, e.g. legacy data stores; - using services at remote locations, independent of implementation language of the server. Who developed it? OMG (Object Management Group) (http://www.omg.org ), that specified the Object Management Architecture or OMA MET CS 667: 7. CORBA

2. 7.2. Object Management Architecture - OMA Two major components: Core Object Model states the basic concepts of - object, - interface, - operation, - etc. OMA Reference Architecture defines services and mechanisms to allow objects to interoperate; it includes - Object Request Broker or ORB: this is a kind of universal translator for inter-object CORBA communication; it must be installed on the server as well as on the client side. Note: different vendors have different ORB implementation, but all CORBA 2.0 and higher compliant ORBs communicate through the Internet Inter-ORB Protocol(IIOP). MET CS 667: 7. CORBA

3. - Object Services, also called CORBA services: services needed by almost all objects; they areaccessed through the ORB and include naming service: supports search of objects by name; startup service: starts a process. life cycle service: supports creating, copying, moving or destroying objects; event service: supports notification of events to interested objects; provides asynchronous communication between cooperating remote objects; persistent object service: provides common interface for managing object persistence in a data-store independent manner. concurrency control service for mediating simultaneous access by more than one client, ensuring that object remains consistent and coherent. - Object Facilities: provides functionality at the application level, that include horizontal facilities: user interface, information management, systems and task management; vertical or domain facilities: provide facilities for specific domain, e.g. telecommunication, e-commerce, health care, OMA (continued) MET CS 667: 7. CORBA

4. Interface Definition Language - IDL References: (HoCo 2002, Ch.5) As previously discussed, in a distributed system the object requesting the service (client) needs to know the names and signatures of methods the server object exposes. Problem: If the goal is to allow objects implemented in different languages to communicate with each other, one needs a language independent way for specifying data types, attributes, operations, interfaces, etc. CORBA's answer to this problem is IDL – a language for describing the attributes, methods, interfaces used by client and server. The interface is typically written on the server side and then distributed to clients. At the client side it is compiled by an IDL-to-SomeLanguage compiler that generates a source file and several helper files for argument marshaling and remote calls. MET CS 667: 7. CORBA

5. CORBA IDL Java C++ Module Package Namespace Interface Interface Pure abstract class Method Method Member function / Method IDL Overview IDL supports inheritance and has C++/Java like syntax The rules for translating IDL into another language are referred to as IDL language bindings or mappings. OMG has standardized the language bindings thus requiring all vendors to use the same rules for mapping IDL constructs to the constructs of a particular language. Languages with IDL mappings include C, C++, Java, Smalltalk, Lisp, Python MET CS 667: 7. CORBA

6. Client Object Implementation IDL IDL ORB IDL for Client Requests • Notes: • Client as well as Server are isolated from the ORB through the IDL interface; • All requests are managed by the ORB, i. e. every single invocation, (whether remote or local) of a CORBA object is handled by the ORB. The difference between the remote and local invocation is only that it is passed from the ORB of the client to the ORB of the server. • Client and Server side can be at different locations and use different ORBs. MET CS 667: 7. CORBA

7. Client Object Implementation Dynamic Invocation Static IDL Stubs ORB Interface Static IDL skeletons Dynamic skeletons Object Adaptor ORB CORE CORBA 2.0 ORB Structure • DII Dynamic Interface Invocation: client obtains instance of CORBA object at run time and dynamically constructs requests. DII uses the interface repository (IR) to validate and retrieve signature of requested operation. • DSI Dynamic Skeleton Interface server side analog of DII, allows server to be written without skeleton or compile time knowledge (since CORBA 2.0) • Interface Repository (IR) allows client to locate object that was unknown at compile time, find info about its interface and build request • Object Adapters (OA) primary way of object implementation to access ORB services. MET CS 667: 7. CORBA

8. Write IDL interface, that specifies what object does. • Compile interface with IDL compiler for target language(s) and generate required stubs and helper classes. • Write server objects in language of your choice. Compile server object code. • Write server that creates and registers the server objects. The CORBA naming service offers a convenient registration method. (Similar to RMI registry) • Write client that locates server objects and invokes services on them. • Start naming service, server program and client program. • Important Differences to RMI: • Client and Server can be implemented in any language with CORBA binding; • Interfaces are specified in IDL 7.3. Implementing CORBA Objects MET CS 667: 7. CORBA

9. interface Env { string getenv (in string name); }; interface Env { String getenv (String name); } file Env.idl file Env.java Example "Env": Java client asks value of an environmental variable, C++ server obliges (HoCo 2000, Ch.5) Note lowercase IDL-to-Java Compiler, e.g. idltojava or idlj (Sun's JavaIDL 1.2 and 1.3 respectively) Note semicolon after interface definition Three helper classes EnvStub.java Stub class MET CS 667: 7. CORBA

10. Parameter Passing: the direction parameters are passed can be defined in the method definition by declaring a parameter as • in from client to server as input (same as in Java) • out from server to client as output (no analog in Java); • method stores value in each out parameter before returning; • caller can retrieve values stored in out parameters • inout in both directions • Example: find method looks for some product and stores product object • interface Warehouse{ • boolean locate(in string description, out Product p); • }; • For an out only parameter methods do not expect initialization. • For an inout parameter caller must supply a value and the method can change that value. IDL Basics – method parameters MET CS 667: 7. CORBA

11. interface Warehouse{ boolean locate(in string description, out Product p); }; idltojava interface Warehouse{ boolean locate(String description, ProductHolder p); … }; In Java, out and inout parameters are simulated with holder classes. Holder classes are automatically generated by the IDL compiler with a Holder suffix added to the class name. In order to retrieve changes to the parameters, every holder class has a public member value that is of the type of the IDL parameter from which it was generated. IDL Basics – Holder classes Change of method signature MET CS 667: 7. CORBA

12. In general: <method>(out <OutputType> firstOut, inout <MsgType> ourMessages) <method>(<OutputType>Holder firstOut, <MsgType> Holder ourMessages) Each holder class has a value public instance variable that stores changes and is of the type of the original in or inout parameter. Thus firstOut.value of type <OutputType> and ourMessages.value of type <MsgType> There are predefined holder classes for the fundamental types, e.g. IntHolder, DoubleHolder, etc.. Holder classes(continued) MET CS 667: 7. CORBA

13. Calling Methods with Holder classes When calling a method with a holder class one needs to pass a holder object Warehouse w = ...; String description = ...; Product p; ProductHolder pHolder = new ProductHolder( ); if ( w.locate ( description , pHolder ) ) p = pHolder.value ; Creating holder object Passing holder object as parameter object of Product type retrieved: The changed value of the Holder class is retrieved through the public variable value MET CS 667: 7. CORBA

14. Types are C/C++ like • basic: char, short, long, float, double, boolean • constructed: struct, union, enum • typedefinition:typedef <UserType> <Name> • fixed size arrays as in C, e.g. short points[10]; • sequences: template type, used to define arrays of varying size, e.g. • sequence < double> eField; • sequence < double, 15> • typedef sequence<Product> ProductSeq; • interface Warehouse{ • ProductSeq find (in Customer c); • … • }; • Translated in Java to • Product [] find (Customer c); IDL Types Unbounded sequence with double elements Bounded sequence with double elements Dynamic array of Product elements ProductSeq type; can be used in method definition MET CS 667: 7. CORBA

15. IDL – Raising an Exception • Throwing an exception: exception type must be first defined, then a raises declaration used: interface Warehouse{ exception BadCustomer { string reason; } ; ProductSeq find (in Customer c) raises BadCustomer; ... }; IDL compiler translates the exception type into a class: final public class BadCustomer extends org.omg.CORBA.UserException{ public BadCustomer() {}; public BadCustomer(String _reason) {reason = _reason; }; public String reason; } MET CS 667: 7. CORBA

16. IDL - constants, attributes • Interfaces can contain constants • Interfaces can contain attributes • The Java translation is a pair of methods both with the attribute name: interface Warehouse{ const int SOLD_OUT=555; ... }; interface Book{ attribute string isbn; ... }; String isbn( ); //accessor void isbn(String _isbn); //mutator // no mutator is generated if attribute is declared readonly MET CS 667: 7. CORBA

17. Interface inheritance is declared by colon ( : ), as in C++ • multiple interfaces can be inherited • 7. Definitions of interfaces, types, constants, exceptions can be grouped into modules IDL - inheritance interface Book : Product {...}; Book inherits from Product module Supplier { interface Book{…}; interface Product {...}; interface Warehouse {...}; .. }; Translated in Java through package Note: Variables cannot be specified in CORBA interfaces. IDL does not address implementation, and the data representation for objects is an implementation decision MET CS 667: 7. CORBA

18. interface Env { string getenv (in string name); }; file Env.idl Example "Env": Classes generated by the IDL Compiler IDL-to-Java IDL-to-C++ • Env.java - the interface definition; • EnvHolder.java – holder class for • out and inout parameters; • EnvHelper.java • _EnvImplBase.java – superclass • for implementation class • _EnvStub.java – stub class to • communicate with ORB • Env.hh – header file defines classes Env, • EnvHelper, • _sk_Env – base class for server • implementation classs ; • EnvSK.cpp – C++ source code for • above classes MET CS 667: 7. CORBA

19. Example "Env": C++ interface implementation (treat as legacy code) class EnvImpl : public virtual _sk_Env{ public: virtual char* getenv(const char *name){ char* value = :: getenv(name); //call getenv of the standard C library return CORBA::string_dup(value); } }; MET CS 667: 7. CORBA

20. Example "Env": Server and Client actions • Server program (in C++ - treat as legacy code) • Start ORB; • Create object of EnvImpl class and register it with the ORB; • Bind object to a name using the name server; • Wait for invocation from client • Client program needs to • Initialize ORB; • Locate naming service by retrieving the initial reference to "NameService" and narrowing it to a NamingContext reference; • Locate the object whose methods you want to call by assembling its name and calling the resolve method of the NamingContext; • Narrow the returned object to the correct type and invoke desired method. MET CS 667: 7. CORBA

21. Example "Env": Client – initialization, listing services • Initialize ORB; • Locate a naming service that allows locating other objects. The CORBA naming service is just another CORBA object. In CORBA 2 the call • lists the names of some standard services the ORB provides. (The ORB of the Java 2 platform lists only the naming service itself, other ORBs have additional initial services). ORB orb = ORB.init(args, null); String [] services = orb.list_initial_services(); MET CS 667: 7. CORBA

22. The Naming service associates names with server objects – a process known as stringifying the reference. It performs object-to string and string-to-object mapping • The naming service supports • creating an object-to string mapping, referred as binding an object; • removing anobject-to string mapping, referred as unbinding an object; • obtaining an object reference by passing a string, is referred to as resolving the name • The Naming Service runs as a separate process and both server and client can consult and manipulate it. • The naming service has the standard name NameService. To obtain an object reference to this service the resolve_initial_references method must be called: Example "Env": Client – Using the Naming Service org.omg.CORBA.Object namingContextObj = orb.resolve_initial_references ( "NameService"); returns generic CORBA object: instance of class org.omg.CORBA.Object MET CS 667: 7. CORBA

23. // ERROR!!!! NamingContext namingContext = (NamingContext) namingContextObj; Example "Env": Client – Narrowing the NamingContext • In order to use the methods of the NamingContext interface, however, we need a NamingContext reference, not just a generic CORBA object. • CORBA does not allow simple cast of references. • In order to obtain a NamingContext type, one must use the narrow method of the helper class of the target interface NamingContext namingContext = NamingContextHelper.narrow(namingContextObj); MET CS 667: 7. CORBA

24. Locate the object whose methods you want to call by assembling its name and calling the resolve method of the NamingContext; • Names are nested sequences of name components. • Name hierarchies can be built similarly to the directories of the file system. • A name component consists of an • id - name of component that is unique among all names with the same parent component, e.g. corejava, Env, and a • kind - some indication of the type; not standardized. As an example "Context" is used for name components that have nested names, and "Object" for object names • In the "Env" example the server program has given the EnvImpl object the name • (id = "corejava", kind = "Context"), (id = "Env", kind = "Object") • In order to find the object its name is built through an array of name componenets Example "Env": Client - Locating Objects NameComponent[] path = { new NameComponent ( "corejava", "Context"), new NameComponent("Env", "Object") }; MET CS 667: 7. CORBA

25. Example "Env": Resolving the name and Using the Object • Resolve the resulting name to obtain an Env object • Narrow the returned object to the correct type and invoke desired method • Call method (finally!!). org.omg.CORBA.Object envObj = namingContext . resolve(path); Env env = EnvHelper . narrow ( envObj ) ; System.out.println ( env . getenv ( " PATH " ) ); MET CS 667: 7. CORBA

26. Example "Env": Client Code import org.omg.CosNaming.*; import org.omg.CORBA.*; public class EnvClient { public static void main(String args[]) { try { ORB orb = ORB.init(args, null); org.omg.CORBA.Object namingContextObj = orb.resolve_initial_references ( " NameService ") ; NamingContext namingContext = NamingContextHelper.narrow ( namingContextObj ) ; MET CS 667: 7. CORBA

27. Example "Env": Client Code (continued) NameComponent[] path = { new NameComponent("corejava", "Context"), new NameComponent("Env", "Object") }; org.omg.CORBA.Object envObj = namingContext . resolve(path); Env env = EnvHelper . narrow ( envObj ) ; System.out.println ( env.getenv ( " PATH " ) ); } catch(Exception e) { System.out.println("Error: " + e); e.printStackTrace(System.out); } } } MET CS 667: 7. CORBA

28. CORBA vs. RMI • RPC between objects written in any languages; • BUT: CORBA has done this for you • RMI allows RPC between Java objects; • BUT: RMI can call services on remote, non-Java code as follows: write a wrapper Java object around the non-Java code on the server side. • Wrapper connects externally to Java clients via RMI and internally to the non-Java code code using Java Native Interface (JNI) or J/Direct • Yes, but now I do not need a 3d party ORB MET CS 667: 7. CORBA