The Common Object Request Broker Architecture (CORBA)

1. The Common Object Request Broker Architecture (CORBA)

2. CORBA • The Common Object Request Broker Architecture (CORBA) is a standardarchitecture for a distributed objects system. • CORBA is designed to allow distributed objects to interoperate in a heterogeneous environment, where objects can be implemented in different programming languages and/or deployed on differentplatforms.

3. CORBA vs. Java RMI • CORBAdiffers from the architecture of JavaRMI in one significant aspect: • RMI is a proprietaryfacility developed by Sun MicroSystems, Inc., and supports objects written in the Java programming langugage only. • CORBAis an architecture that was developed by the Object Management Group (OMG), an industrial consortium.

4. CORBA • CORBA is not a distributed objects facility; instead, it is a set of protocolstandards. • A distributed object facility (e.g., Orbix and VisiBroker) that adheres to thesestandardprotocols is said to be CORBA-compliant, • CORBA is a very rich set of protocols. We will focus on the key concepts of CORBA related to the distributed objectsparadigm. We will also study a facility based on CORBA: the JavaIDL.

5. The BasicArchitecture

6. CORBAObjectInterface • Since CORBA is language independent, the CORBA object interface is defined using a universal language with a distinct syntax, known as the CORBAInterface Definition Language (IDL). (like WSDL--Web Services Description Language, to Web services) • A distributed object in CORBA is defined using an IDLfile similar to the remote interfacefile in JavaRMI.

7. CORBA IDL • The syntax of CORBA IDL is similar to Java and C++. • Objects defined in a CORBA IDL file can be implementedin a large numberof diverse programming languages, including C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLScript. • For each of these languages, OMG has a standardized mapping from CORBA IDL to the programming language, so that an IDLcompiler can be used to process a CORBA IDL interface file to generate the proxyfiles needed to interface with an objectimplementation in server side or an object in client sidewritten in any of the CORBA-compatible languages.

8. module HelloApp { interfaceHello { string sayHello(); oneway void shutdown(); }; }; Ref: http://java.sun.com/j2se/1.5.0/docs/guide/idl/tutorial/GSIDL.html#writing IDL Sample Code

9. Cross-language/vendor CORBA application

10. ORB Core Feature Matrix ORB Core Feature Matrix http://www.jetpen.com/~ben/corba/orbmatrix.html

11. Inter-ORBProtocols • To allow ORBs (Object Request Brokers) to beinteroperable • OMG’s General Inter-ORB Protocol (GIOP) provides a general framework for protocols to be built on top of specifictransport layers • Internet Inter-ORB Protocol (IIOP): GIOP applied to the TCP/IPtransport layer

12. InternetInter-ORBProtocols (IIOP) • Transportmanagementrequirements: specifies the connection and disconnectionrequirements, and the roles for the object client and object server in making and unmaking connections. • Definition of common data representation: a coding scheme for marshalling and unmarshallingdata of each IDL data type. • Message formats: differenttypesof message format are defined. The messages allow clients to send requests to object servers and receive replies. • A client invokes a method declared in a CORBA IDL interface for an object and receives a reply message from the server.

13. Object Bus • An IIOP-compliantORB may interoperate with any other IIOP-compliant ORBs over the Internet. • Object Bus: the Internet is seen as a bus that interconnects CORBA objects.

14. ORB products There are a large number of proprietary as well as experimental ORBs available: (See CORBA Product Profiles, http://www.puder.org/corba/matrix/) • Orbix from IONA • VisiBroker from Borland • PrismTech’s OpenFusion • Web Logic Enterprise from BEA • Ada Broker from ENST • Free ORBs

15. ServerObjects and Clients • As in Java RMI, a CORBA distributed object is exported/registered by a server, similar to the server in RMI. • Aclientlooks up a reference to a distributedobject (serverobject) from a naming or directory service, and invokes the methods of the distributed object.

16. CORBAObject References • As in Java RMI, a CORBA distributed object is located using an object reference. • CORBA is language-independent, a CORBAobject reference is an abstract entity mapped to a language/vendor-specific object reference. • For interoperability, OMG specifies a protocol for the abstract CORBA object reference, known as the Interoperable Object Reference(IOR) protocol.

17. Interoperable Object Reference (IOR) • An ORB compatible with the IOR protocol will allow an object reference to be registered with and retrieved from any IOR-compliant directory service. • An CORBA object reference represented in this protocol is called Interoperable Object Reference (IOR).

18. Interoperable Object Reference (IOR) An IOR is a string that contains encoding for the following information: • The type of an object. • The host where the object can be found. • The portnumber of the server for that object. • An object key, a string of bytes identifying the object. The object key is used by an object server to locate the object.

19. Interoperable Object Reference (IOR) The following is an example of the string representation of an IOR: IOR:000000210000001f49444c3a4e53505343697263756974496e666f496e71756972793a332e33000100000002000000000000006b0001005c000000156e6f726d657430392e6d63696c696e6b2e636f6d00722b83000000473a5c6e6f726d657430392e6d63696c696e6b2e636f6d3a43697263756974496e666f496e71756972793a303a3a49523a4e53505343697263756974496e666f496e7175697279000000000001000000180001005c0000000100000000000000080000000049545f30 The representation consists of the character prefix “IOR:” or “IOR2:” followed by a series of hexadecimal numeric characters, each character representing 4 bits of binary data in the IOR.

20. Generating An IOR File // serverside (in C++) NSPSCircuitInfoInquiry_imp* CirInfoImp = new NSPSCircuitInfoInquiry_imp(argc,argv); try { FILE *fp = fopen("./NSPS_ckt_info.ior","w"); if(fp) { char *iorPtr = CORBA::Orbix.object_to_string( (CORBA::Object_ptr) CirInfoImp ); fputs(iorPtr, fp); fputs("\n", fp); fclose(fp); } } // end of try // client side: file—inIOR, is from server side CORBA::Object_ptr ref = WLEInterface::string_to_object(inIOR); lecOrder = EEInt::LecOrderServer::_narrow(ref); lecOrder->setLecResponseForLecOrder(…);

21. CORBANaming Service - 1 • TheCORBANaming Serviceserves as a directory for CORBA objects • The CORBANaming service is platform independent and programming language independent. • The Naming Service permits ORB-based clients to obtain references to objects they wish to use. It allows namesto be associated with object references. • Clients may query a naming serviceusing a predeterminedname (e.g. SWE622_HW5) to obtain the associated object reference.

22. CORBANaming Service - 2 • To export a distributed object, a CORBA object server contacts a Naming Service to binda symbolicname to the object • The Naming Service maintains a database of names and the objects associated with them. • To obtain a reference to an object, an object client requests the Naming Service to look upthe object associated with the name--resolving the object name • The Naming ServiceAPI is specified in interfaces defined in Naming Service IDLfile • servers to bind names to objects—registration • clients to resolve names—look-up

23. CORBA Naming ServiceIDL file #pragma prefix "omg.org“ // preprocessor directive moduleCosNaming { …. void bind (in Name n, in Object obj) raises (NotFound, CannotProceed, InvalidName, AlreadyBound); void rebind (in Name n, in Object obj) raises (NotFound, CannotProceed, InvalidName); Object resolve (in Name n) raises (NotFound, CannotProceed, InvalidName); void unbind (in Name n) raises (NotFound, CannotProceed, InvalidName); void destroy () raises (NotEmpty); …. }; Ref: http://www.omg.org/docs/formal/04-10-07.txt

24. CORBANaming Service • A standardnaming hierarchy is defined in a manner similar to the naming hierarchy in a file directory.

25. A Naming Context • A naming context corresponds to a folder or directory in a file hierarchy, while object names corresponds to a file. • The full name of an object, including all theassociated naming contexts, is known as a compoundname. • <naming_context>.….<naming_context>.<object name> • Naming contexts and name bindings are created using methods provided in the Naming Service interface.

26. Example of a Naming Hierarchy • An object representing the men’s clothing department is named store.clothing.men where the store and clothing are namingcontexts, and men is an objectname.

27. InteroperableNaming Service • The Interoperable Naming Service (INS) is a URL-basedNaming System based on the CORBA Naming Service. • INS is an extension totheCORBA CosNaming service--a tree-like directory for object references. • URL Formats for CORBA Object References • corbaloc:iiop:1.2@ise.gmu.edu:2050/swe622 • corbaname::ise.gmu.edu:2050#Personal/schedule (to get the root naming context, and to resolve the name Personal/Schedule) Ref: http://java.sun.com/j2se/1.5.0/docs/guide/idl/jidlNaming.html

28. CORBA Object Services • CORBAServicesdefined in a standard IDL file • Naming Service • Concurrency Service: • Event Service: for event synchronization; • Logging Service: for event logging; • Scheduling Service: for event scheduling; • Security Service: for security management; • Trading Service: for locating a service by the type (instead of by name); • Time Service: a service for time-related events; • Notification Service: for events notification; • Object Transaction Service: for transactional processing.

29. Object Adapters • In the basic architecture of CORBA, a distributed object interfaces with the skeleton to interact with the stub on the object client side. • As the architecture evolved, a software component in addition to the skeleton is needed on the server side: an object adapter.

30. Object Adapters • An object adaptersimplifies the responsibilities of an ORB by assisting an ORB in deliveringa client request to an object implementation. • When an ORB receives a client’s request, it locates the object adapter associated with the object and forwards the client’s request to the adapter. • The adapterinteracts with the object implementation’sskeleton, which performsdatamarshalling and invoke the appropriate method in the servantobject.

31. Portable Object Adapter Object Adapter Interface

32. Portable Object Adapter • There are different typesofCORBA object adapters, such as real-time object adapters (in TAO) and portable object adapters. • The Portable Object Adapter (POA) is a particular type of object adapter that is defined by the CORBA standard specification. • A POAobject adapter allows an object implementation to function with otherdifferentORBs.

33. CORBAServer • CORBA Server consists of: • A Servantclass • implementsmethods defined an IDL interface • A Serverclass • containsmain() method • instantiates a servant object • binds/registers the servant object to an objectname

34. CORBAServantClass public class HelloServant extends HelloPOA { private ORB orb; public HelloServant( ORB orb ) { this.orb = orb; } public String sayHello( ) { return "Hello From CORBA Server..."; } public void shutdown( ) { orb.shutdown( false ); } }

35. CORBAServerClass - 1 • Create and initializes anORB instance • ORB orb = ORB.init(args, null); • Getareference to the root POA and activates thePOAManager • POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); • rootpoa.the_POAManager().activate(); • Create a servant instance • org.omg.CORBA.Object ref = • rootpoa.servant_to_reference(helloImpl); • Hellohref = HelloHelper.narrow(ref);

36. CORBAServerClass - 2 • Obtain theInitial Object Reference • org.omg.CORBA.Object objRef = • orb.resolve_initial_references("NameService"); // persistent NS • // orb.resolve_initial_references("TNameService "); // transient NS • // Java IDL Transient Naming Service • Narrow the Naming Context • NamingContextExt ncRef = • NamingContextExtHelper.narrow(objRef); • Register the new objectin the naming context • NameComponent path[] = ncRef.to_name( “swe622” ); • ncRef.rebind(path, href); • Wait for invocationsof the object from a client • orb.run();

37. CORBAClient • Create an ORB Object • ORB orb = ORB.init(args, null); • Obtain the Initial Object Reference • org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); • Narrow the Object Reference to get Naming Context • NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef); • Resolve the Object Reference in Naming • helloImpl = HelloHelper.narrow(ncRef.resolve-str(“swe622”)); • Invoking the method • helloImpl.sayHello();

38. The Java IDL (Java 1.5 version)

39. Java IDL – J2SE CORBA Facility • Java IDLis part of the Java 2 Platform, Standard Edition (J2SE). • The Java IDLfacility includes • a CORBA Object Request Broker (ORB), • an IDL-to-Javacompiler, and • a subset of CORBA standardservices. • In addition to the Java IDL, J2SE provides a number of CORBA-compliant facilities, including RMI over IIOP, which allows a CORBA application to be written using the RMI syntax and semantics.

40. KeyJava IDLPackages • package org.omg.CORBA – contains interfaces and classes which provides the mapping of the OMG CORBA APIs to the Java programming language • package org.omg.CosNaming - contains interfaces and classes which provides the naming service for Java IDL • class org.omg.CORBA.ORB - provides APIsfor the Object Request Broker.

41. Java IDL Tools Java IDLprovides a set of tools needed for developing a CORBA application: • idlj - the IDL-to-Java compiler (called idl2java in Java 1.2 and before) • orbd - a server process which provides Naming Services and other services • servertool – provides a command-line interface for application programmers to register/unregister a server (appl), and startup/shutdown a server. • tnameserv – an oldTransientJava IDLNamingService

42. IDL Keywords

43. An IDL File modulePersistent { interfaceHello { enumNotFoundReason { missing_node, not_context, not_object}; exceptionNotFound { NotFoundReason why; string name; }; string sayHello( ); void shutdown() raises (NotFound); // oneway void shutdown() raises (NotFound); }; };

44. Dynamic Invocation Interface (DII) - 1 • The stub serves as a proxy to access a remote object. Stubs are generated at compile-timeand are static. • But what ifthe interface type of an object is not known at compile time? • CORBA's Dynamic Invocation Interface (DII) offers the possibility of invoking operation calls whose signature is not knownat compile time. Ref: http://www.puder.org/corba/cg/

45. Dynamic Invocation Interface (DII) - 2 • DII uses an object of classorg.omg.CORBA.Request to hold everything required to a method invocation: • the object reference • the name of the operation • its parameters • space for the result. • The client builds a Requestobject describing an operation, then calls the request's invoke method. • The key to dynamic invocation is the ability of requests to hold self-describing data. This facility enables a Request object to represent any invocation of any operation, regardless of its parameters. • Ref: http://java.sun.com/j2se/1.5.0/docs/guide/idl/jidlClients.html

46. Dynamic Skeleton Interface (DSI) • A server uses the dynamic skeleton interface (DSI) to receive operations or attribute invocations on an object whose IDL interface is unknown to it atcompile-time. • The server defines a function that determines the identity of the requested object; the name of the operation and the types and values of each argument. Clients are unaware that a server is implemented with the DSI. • The DSI is designed to help writing gateways that accept operation or attribute invocations on any specified set of interfaces and pass them toanother system. • A gateway can be written to interface between CORBA and some non-CORBA system (such as Microsoft’s COM), if a non-CORBA system does not support IIOP. • Ref: http://www.iona.com/support/docs/orbix2000/2.0/pguide_cpp/html/DynInterfaces3.html

47. Dynamic Skeleton Interface in Java - 1 • Declare the servantclass to extend • org.omg.CORBA.DynamicImplementation. • Implement the invoke(ServerRequest request) method to: • - Extract the operation name via a call on op_name(). • - Build an NVList of the operation parameters • - Extract the parameter values via a call on params() • - Perform the operation, assigning new values to out/inout parameters • - Call either result() and/or except() • Implement the _ids() method. This method is inherited from org.omg.CORBA.portable.ObjectImpl, the superclass of DynamicImplementation. It returns the repository IDs of the interfaces implemented by this dynamic server. • Ref: http://java.sun.com/j2se/1.5.0/docs/guide/idl/jidlDSI.html

48. Dynamic Skeleton Interface in Java - 2 • The Server Class: • Create an instance of the DSI Servant object using new(). (at the run time) • Register it with the ORB via a call to org.omg.CORBA.ORB.connect() • Wait for requests from clients Ref: http://java.sun.com/j2se/1.5.0/docs/guide/idl/jidlDSI.html

49. Repository ID • Each CORBA interface has a unique “Repository ID“. • OMG formats of a Repository ID: • IDL style: IDL:Prefix/ModuleName/InterfaceName:VersionNumber ( e.g., IDL:JavaIDL/DSIInterface:1.0 ) • RMI style: RMI:ClassName:HashCode[:SUID] • DCE-style: DCE:UUID • Local: defined by the local Object Request Broker (ORB). • Ref: http://www.bayour.com/openldap/schemas/corba.schema

50. Dynamic Skeleton Interface in C++ • The CORBA::ServerRequest class, which is a pseudo-object that is the server-side equivalent to the client-side CORBA::Request. When the POA dispatches a request to a DSI servant, it passes an instance of ServerRequest to communicate all information about the request needed to allow the servant to fulfill it. • The PortableServer::DynamicImplementation servant base class, from which concrete DSI servant classes inherit. This base class provides the following pure virtual methods that DSI servant classes are expected to override: • - void invoke (ServerRequest_ptr server_request), which is upcalled by the POA to allow the servant to handle requests. The POA passes the ServerRequest representing the request being processed to this method. • RepositoryId _primary_interface (const ObjectId& id, POA_ptr poa), which is called by the ORB/POA run time when it needs the repository ID string identifying the most-derived interface of the object that the servant is incarnating. • The _primary_interface method is called when the application calls POA methods, such as servant_to_reference and id_to_reference, so that the run time can create object references containing the appropriate repository ID.