CORBA Object Model and Interoperability Architecture

1. CORBA part II Karsten Schulz Terp-Nielsen

2. Agenda • CORBA Object Model • Interoperability architecture, Language mappings, Portable Interceptors and DGC • IDL to Java mapping • Corba Communication Models • CORBA Services • CORBA Naming Service • CORBA Transaction Service • CORBA Concurrency Service

3. CORBA OverviewObject Model • The OMA Core Object Model defines some fundamental definitions of concepts which are extended, made more specific and concrete by CORBA • The class concept does not exist in CORBA as non-Object Oriented programming languages can be used as implementation language • Clients for remote objects are not necessary objects as Client implementation languages also can be non-Object Oriented

4. CORBA OverviewObject Model - remote object references • Remote Object References can be in two forms Session form and Interoperable Object Reference (IOR) form • The session form is a vendor specific format • In session form there is no information that is meaningful for the client as the ref is only interpreted at the server side • The IOR form is intended for interoperability between different ORBs • The IOR form can be stringified to enable IORs to be stored, emailed, printed, and retrieved

5. CORBA OverviewObject Model - remote object references IOR Object Reference Object Key Transport Address IIOP:host:port Repository ID POA Name Object ID Identifies Interface Type Identifies the object within POA Is in proprietary format for a given ORB Interoperability is not affected as the server is the only one looking in it Identifies a transport endpoint

6. CORBA OverviewObject Model - remote object references • Object references are opaque - application code isn’t allowed to look inside or make any assumptions about the internals • Remote Object references have a semantics very similar to class pointers in C++ - they can dangle ie pointing at a non-existing or unreachable object • If the server where the remote object lived is shutdown and started again on another host

7. CORBA OverviewObject Model - remote object references • CORBA distinguishes between transient and persistent object references (LifeSpan policy) • A transient IOR continues to work a long as the corresponding server process where the remote object remains available • Once the server process is shutdown the IOR is non-functional forever (even if the server process is started again) • IOR Host:port contains the server process information for the POA

8. CORBA OverviewObject Model - remote object references Pseudo-random number Client Server: TestHost:8888 If the server is up and running -> Ok If the server is down - > OBJECT_NOT_EXIST If the server is running but not the right adapter ID (check for pseudo-random number) -> OBJECT_NOT_EXIST If the server is running but not the right ORB (check for vendor specific tag in IOR identifying ORB) ->OBJECT-NOT_EXIST IOR Object Reference POA1 TestHost:8888 POA1,OBJID:12 OBJID:11 IDL:MyObject OBJID:12 OBJID:13

9. CORBA OverviewObject Model - remote object references • A persistent object reference survives shutdown of the server process - it still denotes the same CORBA object • This works even if the server process is started on another host:port • The persistent object reference has a life cycle independent of the life cycle of the servant • Many ORBs can transparently start server processes and shut them down again after some idle time in order to save resources

10. CORBA OverviewObject Model - remote object references • Persistent object references are implemented by usage of the Implementation Repository • IOR Host:port contains the Implementation Repository server process information • More host:port occurences allow for replicated Implementation Services • Implementation Repository acts as a level of indirection and delivers at runtime the address of the POA server process to the client

11. CORBA OverviewObject Model - remote object references Pseudo-random number Client Server: TestHost:8888 IOR Object Reference POA1 Jupiter:8080 POA1,OBJID:12 OBJID:11 IDL:MyObject OBJID:12 OBJID:13 Implementation Repository: Jupiter:8080 POA1 \bin\server\startPOA1 TestHost:8888

12. CORBA OverviewObject Model - Persistent Reference example • To make the Hello object references persistent you do the following • Create a new Policy • the LifeSpanPolicy equals persistent • the IDAssignmentPolicy equals user_id • for all others default values are used • Create new POA associated with RootManager with Policy ‘the new policy’ • Create servant and explicit activate servant • Example hello_imr

13. CORBA OverviewInteroperability Architecture • The Interoperability Architecture for CORBA contain elements like • ORB interoperability • Inter-ORB bridge support • GIOPs and IIOPs • An ORB is considered being interoperability compliant when supporting • GIOP/IIOP • IOR

14. CORBA OverviewLanguage Mappings • The following language specific OMG IDL compilers are contained in specifications Phyton Phyton ADA ADA C++ C++ Client Server Java Java Smalltalk Smalltalk COBOL COBOL LISP LISP C C CORBA Script CORBA Script

15. CORBA OverviewLanguage Mappings - cross language example • To show CORBA is language independent use the IDL2CPP (idl) compiler on hello.idl to generate a interface and a stub • idl --no-skeletons hello.idl • Make a client.cpp implementation and link it to a client.exe • Start the Java ORB based hello server and start the C++ ORB based hello client

16. J2SE 1.4 support for CORBA

17. J2SE 1.4 support for CORBACORBA compliance • JDK 1.4 contains a Java ORB implementation supporting a part of CORBA specification 2.3.1 • http://java.sun.com/j2se/1.4/docs/api/org/omg/CORBA/doc-files/compliance.html • JDK 1.4 contains the following CORBA tools • IDL-to-Java compiler (idlj) • Implementation Repository (orbd) • transient Naming Service (orbd) • persistent Naming Service (orbd) • servertool (cmd line interface tool) • tnamesrv (backward compability)

18. J2SE 1.4 support for CORBACORBA features • GIOP 1.2 (IIOP) • POA • Portable interceptors • provides hooks, or interception points, through which ORB services can intercept the normal flow of execution of the ORB • three types • IORInterceptor • ClientRequestInterceptor • ServerRequestInterceptor

19. J2SE 1.4 support for CORBACORBA features • The class ORBInitializer facilitates interceptor registration and ORB initialization • done through properties org.omg.PortableInterceptor.ORBInitializerClass.<Service> • where <Service> is the string name of a class which implements org.omg.PortableInterceptor.ORBInitializer • Interoperable Naming Service • can use corba urls

20. J2SE 1.4 support for CORBACORBA example • Example of using persistent object references and the implementation repository in J2SE 1.4 (javacorba\exservertool) • start the orbd (startorbd) • start the server tool (startservertool) • register HelloServer and start it up • start the client (startclient) • every 6 seconds the client class the sayHello() on the remote object and shutdown the server • watch in Taskmanager how the server is automatically started up when its shutdown by the client

21. Java Language MappingGenerated Server files User written IDL file Hello Extends HelloOperations Hello Generated interfaces Implements HelloPOA Implements Extends Generated java classes HelloPOATie Extends Delegates User written java classes Your HelloTieImpl Your HelloImpl Tie Approach Inheritance Approach

22. Java Language MappingGenerated Client files Hello User written IDL file HelloOperations Generated Java interfaces Extends Hello Implements Generated Java class _HelloStub

23. Java Language MappingGenerated Holder Objects (xxxxxHolder.java) • Generation of Holder objects for each Interface and Exception declared in the IDL for a remote object • Holder objects aren’t generated for a C++ ORB/IDL2Cpp compiler • Why for Java? • CORBA defines three different parameter-passing modes (indicated by in,out,inout) • in: pass-by-value -> value supplied by client and are left unchanged during invocation

24. Java Language MappingGenerated Holder Objects (xxxxxHolder.java) • out: pass-by-result -> value supplied by server available after invocation • inout: combined semantic • Java only defines pass-by-value parameter-passing mode • Check example: Parameter.java TestHolder.java • To map out and inout parameters additional mechanisms are needed Holder objects

25. Java Language MappingGenerated Holder Objects (xxxxxHolder.java) • Check example: Parameter.java, ParameterHolder.java, TestHolder.java • Check stub code example: eksempler/holder/ shape2.idl, _Shape2Stub.java STUB KODE IDL public String get(edge _ob_a0,edgeHolder _ob_ah1) ... out = _request("get", true); edgeHelper.write(out, _ob_a0); in = _invoke(out); String _ob_r = in.read_string(); _ob_ah1.value = edgeHelper.read(in); return _ob_r; …. module test2 { struct edge {short s;}; interface shape2 { string get (in edge e, out edge o); }; };

26. Java Language MappingExceptions Java.lang.Object Exception hierarchy Show example of this by commenting out exception handling in client kode in servertool example java.lang.Throwable org.omg.CORBA.portable.IDLEntity java.lang.Exception java.lang.RuntimeException org.omg.CORBA.UserException org.omg.CORBA.SystemException IDL-defined Exceptions Pre-defined System Exceptions

27. Java Language MappingExceptions • Checked Exceptions • must either be caught • by an Exception handler • or declared in the • methods throws clause • public void aMethod(..) • throws MyException • Checked Exceptions are • checked by the Java • compiler and the JVM to • make sure that this rule • is obeyed • Unchecked Exceptions need • not be handled in any way

28. Java Language MappingTypes • Type mapping when executing the IDL2Java compiler • basic types (string, short etc.) quite logical • sequences -> Java array • struct -> public final Java class with public members • pre-defined, user-defined types -> Holder,Helper Java classes • Any type -> Special predefined Java Class org.omg.CORBA.Any which contains methods for inserting and extracting arbitrary IDL types

29. Java Language MappingTypes • ValueTypes -> Abstract Java Class for the valuetype + Factory interface for creation of concrete Java Class for the valuetype The developer must supply an concrete implementation of the valuetype by inheriting from the generated abstract Java class The developer must supply an implementation of the generated factory interface - the implementation must be registrered in the ORB when the server/client is started • Interfaces -> Java interfaces Java RMI: All serializable classes are passed by value

30. Java Language MappingTypes • Semantic of parameter passing of types in a remote invocation of a CORBA object • All types specified as an IDL Interface is ’passed by reference’ (remote object reference) • All primitive and constructed types are ’passed by value’ • All IDL valuetypes are ’passed by value’

31. Java Language MappingMultiple inheritance • OMG IDL allow multiple inheritance while Java only allow multiple inheritance for its interfaces (not for its classes) • Interfaces are just mapped straight • But how does stubs and skeletons look? Skeletons: abstract public DerivedPOA extends ..... implements DerivedOperations Base Stubs: public class _DerivedStub extends _LeftStub implements Derived { public right _Right; public void rightOp() { this._Right.rightOp(); ..... Left Right Just like Tie approach Derived

32. Java Language MappingStubs/Skeletons • Portable Stubs and Portable Skeletons are implemented in Java with either usage of Portable Streams or DII/DSI Client Servant Portable Stub Portable Skeleton Stream Interface DII Stream Interface DSI

33. Portable InterceptorsOverview • CORBA implementations have long had proprietary mechnisms that allowd users to insert their own code into the ORBS’s flow of execution • Filters, Transafomers and Interceptors • Modify request arguments, redirect requests to different target objects, encrypt and decrypt message buffers before/after transport • As we will see later Transaction Service typically uses filter mechanisms to implicit propagate contexts and when using proprietary mechanisms applications are tied to particular ORB implementations • Implementation Repsoitory can use Portable Interceptors to redirect the request with a new ref pointing at the actual object and not the Implementation Repository

34. Portable InterceptorsOverview • Portable Interceptors are intended to solve that problem by defining a standard interface to register og and execute application-independent code that among other things takes care of passing service contexts • Portable Interceptors specification defines two classes of Interceptors • Request Interceptors (called during request mediation) • Client and Server • IOR Interceptors (called when new refs are created)

35. Portable InterceptorsOverview ClientRequestInterceptor ServerRequestInterceptor Client Server Receive_ Request Receive_ Request_ Service_ context Receive_other Receive_exceptions Receive_reply Send_poll Send_request Send_other Send_exceptions Send_reply Establish_ components

36. Distributed Garbage Collection • CORBA does not attempt to make general-purpose distributed garbage collection as not all programming languages support garbage collection • CORBA does however define methods on the Object (from which all CORBA Objects inherit) to help the developer doing garbage collection • org.omg.CORBA.Object.duplicate() • org.omg.CORBA.Object.release() Used in programming languages where programmers do explicit memory management -> ensure correct management of copies of an remote object reference

37. CORBA Cummunication modelsOverview • CORBA basically supports three communication models (as of CORBA 2.3) • Synchronous two-way (request/reply) • ASynchronous one-way (request) • Deferred Synchronous • (Event/Messages) • Synchronous two-way calls have a’at-most-once’ call semantic • Asynchronous one-way calls have ’maybe’call semantic

38. CORBA Communication modelsOverview • ASynchronous one-way calls isn’t always non-blocking in many implementations as it has to be implemented in the TCP/IP protocol which provides reliable delivery and end-to-end flow control • At the TCP/IP level client one-way calls can be blocked due to full TCP buffers at the server • So the only way to be sure for non-blocking calls are to use the Messaging Service

39. CORBA Services • A set of interface specifications provides fundamental services that application developers may need in order to • Find objects • Manage objects • Coordinate the execution of complex operations • CORBA Services are the building blocks for other components in the OMA including applications

40. CORBA Services • The following services exist: Licensing Query Properties Security Time Collection Trading Naming Notification (event) Life cycle Persistent state Relationships Externalization Transaction Concurrency control -Some of the above are simply framework interfaces that will be inherited by the application or other objects (Ex. Life cycle service) -Others represent low-level components on which higher-level components can be build (Ex. Transaction service) -Others provide basic services used at all levels of applications (Ex. Naming and Trading service)

41. CORBA Naming ServiceCORBA Naming Service • Until now we used the file system and object_to_string to communicate the IOR to the client • Instead we can use a Corba Naming Service to register og obtain remote references to CORBA objects in a more elegant way • The CORBA Naming service is an example of a concrete Naming Service implementation/standard

42. CORBA Naming ServiceCORBA Naming Service • The CORBA Naming Service is hierarchically structured in Naming Contexts • Naming Contexts are similar to directories in file systems Root InitialContext for a given ORB Context2 Context3 Context4 Context5

43. CORBA Naming ServiceCORBA Naming Service • Naming Contexts can contain • Name Bindings • Sub Naming Contexts Root Context2 Context3 Sub Naming Context Context4 Context5 Car Hello Name Binding IOR of car IOR of Hello

44. CORBA Naming ServiceCORBA Naming Service • Clients and Servers operates with the CORBA Naming Service in terms of Names • A Name is a sequence of NameComponents which either can be Naming Contexts or Objects • Naming Contexts and Objects are identified through a string Example: Name for an Account CORBA object Name= context2 context5 Hello

45. CORBA Naming ServiceCORBA Naming Service - Basic functionality • struct NameComponent{ string id; string kind; }; • typedef sequence <NameComponent> Name; • interface NamingContext { • void bind (in Name n, in Object obj); • binds the given name and remote object reference in my context. • void unbind (in Name n); • removes an existing binding with the given name. • void bind_new_context(in Name n); • creates a new naming context and binds it to a given name in my context. • Object resolve (in Name n); • looks up the name in my context and returns its remote object reference. • void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi); • returns the names in the bindings in my context. • };

46. CORBA Naming ServiceCORBA Naming Service • Name Resolution in CORBA Naming Service happens relative to a InitialContext • resolves operation resolves the first component of the Name,n, to an object reference • If there are no remaining Name Components, it returns this object reference to the caller • Otherwise it narrows the object reference to a Naming Context and passes the remainder of the Name to the resolves() operation • The above algorithm will probably be optimized concrete implementations

47. CORBA Naming ServiceCORBA Naming Service • An application uses the Naming service this way: • A CORBA Server bind IORs to a unique Name in the Naming Server • The Client resolve to get a particular IOR by supplying a Name to the resolve method of a initial Naming Context • which you get by ORB.resolve_inital_references(“NameService”) • The Client narrow the IOR to a given interface type and start using it

48. CORBA Naming ServiceCORBA Naming Service –Interoperable Naming Service • The Interoperable Naming Service (INS) provides the following features: • Capability to resolve using stringified names (e.g., a/b.c/d) • URLs for CORBA object references (corbaloc: and corbaname: formats) • Corbaloc -> locate CORBA services • Corbaname -> stringified resolvement • Standard APIs in NamingContextExt for converting between CosNames, URLs, and Strings • ORB arguments for bootstrapping (ORBInitRef and ORBDefaultInitRef)

49. CORBA Naming ServiceCORBA Naming Service • Example: eksempler\hello_naming • Server.java registers a hello remote object reference in the root Naming Context of a running Naming Service • Client.java retrieves the remote object reference through the Naming Service by issuing a Name • the Name just consists of the name of the object as the remote reference is registered in the root Naming Context • A console can be used for maintaining the Naming Contexts

50. CORBA Naming ServiceCORBA Naming Service So if I have to model a CORBA Order object in a CORBA server - will I then have to register all incarnations of orders in the Naming service?