CORBA (Common Object Request Broker Architecture) 7. CORBA 7.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 Fall 2003 MET CS 667: 7. CORBA

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). Fall 2003 MET CS 667: 7. CORBA

naming service: supports search of objects by name; OMA (continued) - Object Services, also called CORBA services: services needed by almost all objects; they are accessed 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, Fall 2003 MET CS 667: 7. CORBA

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. Fall 2003 MET CS 667: 7. CORBA

IDL supports inheritance and has C++/Java like syntax IDL Overview IDL supports inheritance and has C++/Java like syntax CORBA IDL Java C++ Module Package Namespace Interface Interface Pure abstract class Method Method Member function / Method 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 Fall 2003 MET CS 667: 7. CORBA

IDL for Client Requests Object Implementation IDL ORB 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. Fall 2003 MET CS 667: 7. CORBA

Object Implementation CORBA 2.0 ORB Structure Client Object Implementation ORB CORE ORB Interface Static IDL skeletons Stubs Dynamic Invocation Object Adaptor 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. Fall 2003 MET CS 667: 7. CORBA

7.3. Implementing CORBA Objects 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 Fall 2003 MET CS 667: 7. CORBA

string getenv (in string name); }; file Env.idl Example "Env": Java client asks value of an environmental variable, C++ server obliges (HoCo 2000, Ch.5) interface Env { string getenv (in string name); }; file Env.idl 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 interface Env { String getenv (String name); } file Env.java EnvStub.java Stub class Fall 2003 MET CS 667: 7. CORBA

IDL Basics – method parameters 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. Fall 2003 MET CS 667: 7. CORBA

IDL Basics – Holder classes 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. idltojava interface Warehouse{ boolean locate(in string description, out Product p); }; boolean locate(String description, ProductHolder p); … Change of method signature Fall 2003 MET CS 667: 7. CORBA

Holder classes (continued) 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.. Fall 2003 MET CS 667: 7. CORBA

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 Fall 2003 MET CS 667: 7. CORBA

basic: char, short, long, float, double, boolean IDL Types 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); Unbounded sequence with double elements Bounded sequence with double elements Dynamic array of Product elements ProductSeq type; can be used in method definition Fall 2003 MET CS 667: 7. CORBA

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; } Fall 2003 MET CS 667: 7. CORBA

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 Fall 2003 MET CS 667: 7. CORBA

Interface inheritance is declared by colon ( : ), as in C++ IDL - inheritance 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 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 Fall 2003 MET CS 667: 7. CORBA

Example "Env": Classes generated by the IDL Compiler interface Env { string getenv (in string name); }; file Env.idl 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 Fall 2003 MET CS 667: 7. CORBA

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); } }; Fall 2003 MET CS 667: 7. CORBA

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. Fall 2003 MET CS 667: 7. CORBA

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(); Fall 2003 MET CS 667: 7. CORBA

Example "Env": Client – Using the Naming Service 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 an object-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: org.omg.CORBA.Object namingContextObj = orb.resolve_initial_references ( "NameService"); returns generic CORBA object: instance of class org.omg.CORBA.Object Fall 2003 MET CS 667: 7. CORBA

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 = (NamingContext) namingContextObj; // ERROR!!!! NamingContext namingContext = NamingContextHelper.narrow(namingContextObj); Fall 2003 MET CS 667: 7. CORBA

Example "Env": Client - Locating Objects 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 NameComponent[] path = { new NameComponent ( "corejava", "Context"), new NameComponent("Env", "Object") }; Fall 2003 MET CS 667: 7. CORBA

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 " ) ); Fall 2003 MET CS 667: 7. CORBA

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 ) ; Fall 2003 MET CS 667: 7. CORBA

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); Fall 2003 MET CS 667: 7. CORBA

RPC between objects written in any languages; 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 Fall 2003 MET CS 667: 7. CORBA