1. MSc Course in Advanced Distributed Systems Session 2.1: CORBA and CORBA Programming using JAVA http://info.comp.lancs.ac.uk/msc/ads/index.htm

2. CORBA and CORBA programming overview of lecture –context: the OMG and its OMA (which includes CORBA) –description of the CORBA architecture and its main concepts –highlights of CORBA v3.0 –practical focus on programming a simple client/ server additional reading –Very good online tutorials at http://java.sun.com/j2ee/corba/ http://java.sun.com/j2ee/corba/ –www.omg.orgwww.omg.org acknowledgements to Weihai Yu, Univ. of Tromsø

3. Part 1: An overview of the OMG’s OMA/ CORBA

4. What is the OMG? formed in 1989 to address problems of developing distributed applications for heterogeneous systems world’s largest software industry consortium –more than 800 members –IBM, Sun, HP, Iona,... works through a “Request for Proposals” (RFP) process

5. The Object Management Architecture (OMA) Object Request Broker (CORBA) object services Domain interfaces Application interfaces example domain interfaces –financial services, heath care, real- time systems,... example object services –naming service, interface repository, AV streams, transactions, persistence, events, time service,... CORBAFacilities CORBAServices

6. Goals of CORBA to simplify object-based distributed programming by automating: –object location and activation –parameter marshaling/ unmarshaling –request demultiplexing –error handling to provide a foundation for higher level services

7. The Common Object Request Broker Architecture (CORBA)

8. Main concepts in CORBA the OMG Interface Definition Language (IDL) –and its mapping to different programming languages clients, objects (servants), object references, and servers stubs and skeletons ORB core General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP) Portable Object Adapter (POA) Dynamic Invocation Interface (DII)/ Dynamic Skeleton Interface (DSI)

9. RMI vs CORBA RMI Advantages 1.native JAVA, so is cleaner and similar 2.Simple to use 3.Free, no licensing needed Disadvantages 1.just a remote procedure call system 2.Language dependent 3.Not very powerful CORBA Advantages 1.Defines a robust distributed environment 2.All features needed for distributed applications 3.language independent Disadvantages 1.CORBA is non-native, so requires lots of wrappers in JAVA 2.Advanced features are complicated to use (as you will see )

10. CORBA’s Interface Definition Language (IDL) a declarative language supporting programming language independence and platform independence object-oriented –interfaces with operations and attributes –basic and constructed types –single and multiple interface inheritance all interfaces inherit from Object –built-in exceptions mappings are defined to many languages –C++, C, Java, COBOL, LISP,...

11. An example IDL file // IDL module TimeServices { struct TimeOfDay { short hour; // 0-23 short minute; // 0-59 short second; // 0-59 }; interface Time { void set_time(in TimeOfDay t); TimeOfDay get_gmt(); string get_gmt_as_string(); } }

12. Some differences between IDL and JAVA/C++ no statements no pointers no constructors no templates no int data type constrained parameter passing modes ( in, out, inout ) oneway call semantics unions require a tag strings/ sequences are different exceptions are different etc.

13. IDL-JAVA-C++ mappings IDLJavaC++ Modulepackagenamespace Interfaceinterfaceabstract class Operationmethodmember function Attribute pair of methodspair of functions exception exception exception

14. The IDL-to-JAVA mapping basic types IDLJAVAbooleancharshort longint stringStringfloat octetbyte long longlong attributes Interface long myAttribute; the compiler generates two new methods to access the attribute… int getmyAttribute() throws omg.corba.SystemException; void setmyAttribute() throws omg.corba.SystemException; interfaces interface Test {...} class TestImpl (serv. outline) Object Implementation class Test (stub), Client side

15. Clients, objects (servants), and servers an object or servant is an implementation of an IDL interface type—it ‘incarnates’ an IDL type a server holds (potentially many) servants a client calls a (potentially remote) servant –must hold an object reference for the servant (see later) ‘client’ and ‘servant’ are actually roles; e.g. a servant can also be a ‘client’

16. Stubs and skeletons both generated by the IDL compiler stubs –act as proxies for potentially remote servants –marshal arguments to remote operations and unmarshal results skeletons –unmarshal arguments and marshal results –‘upcall’ servant –servants derive from the skeleton class

17. The ORB core implemented as a library linked into both client and server address spaces –there may be separate client and server libraries transparently mediates object requests under the hood... –connection management –request transfer (e.g., using GIOP/ IIOP) –demultiplexing of requests –threading strategies –etc.

18. GIOP/ IIOP GIOP is an ‘abstract’ protocol that enables inter- operation between heterogeneous ORBs –defines requirements on underlying transport protocol (layer 4) –defines Common Data Representation (CDR) this and IDL are the main CORBA mechanisms for the support of language and system independence –defines formats and semantics of messages (8 message types in total) IIOP is GIOP running over TCP/IP

19. The GIOP message types

20. The Portable Object Adapter ‘life support environment’ for servants facilitates server-side portability demultiplexes incoming requests to target servant activates servant objects if necessary manages object references and object IDs –acts as a local object name (ID) space –POAs can be nested to represent local hierarchical namespaces supports various policies –persistent or transient servants –thread pools and priorities –application or POA supplied object IDs –transactional semantics –etc.

21. Dynamic Invocation Interface (DII)/ Dynamic Skeleton Interface (DSI) a slower, less convenient, but more general alternative to static stubs/ skeletons DII –enables calling of servants for which we don’t have pre-compiled stubs get IDL details from Interface Repository CORBAService laboriously build the request by ‘pushing’ args onto a ‘request stack’ DSI –enables request-handling by servants for which we don’t have pre- compiled skeletons used by ‘generic’ applications like bridges, debuggers and database browsers –these must be able to deal with IDL types unforeseen at compile time supports an asynchronous-invocation-with-polling invocation mode

22. A brief overview of CORBA v3 quite recently released as a coherent package (although many parts have been individually available since 2.x) improved ‘internet integration’ –XML mapping/ DOM; valuetypes; interoperable name service; better interoperability with Java; firewall support quality of service support –asynchronous messaging (AMI), including QoS directives –minimum-, fault-tolerant- and real-time-CORBA specifications distributed component support –development of the CORBA component model (CCM) and associated CORBA Scripting Language

23. Part 2: An introduction to programming in CORBA v2.x with the JAVA mapping

24. CORBA programming example Consider a time service accessible to remote clients... // JAVA client code; outline only int main(void) { Time timeRef = TimeHelper.narrow(obj); // call the Time server object and print results TimeOfDay tod = timeRef.get_gmt(); Print(tod); }

25. The IDL specification // IDL module TimeServices { struct TimeOfDay { short hour; // 0-23 short minute; // 0-59 short second; // 0-59 }; interface Time { TimeOfDay get_gmt(); }; };

26. IDL-to-JAVA mappings module TimeServices –maps to a similarly named JAVA package struct TimeOfDay –maps to a similarly named JAVA class (plus constructor) in TimOfDay folder interface Time –Maps to a abstract class called _TimeImplBase which has to be inherited and completed by the programmer –...which inherits from a generic class (invisible to the programmer) called org.omg.CORBA.portable.ObjectImpl which encapsulates server skeleton functionality –also _ TimeStub (client stub), and Timehelper, TimeHolder and TimeOperations which are JAVA functionality wrappers

27. The servant class class TimeServant extends __TimeImplBase { public String get_gmt() { return s; }

28. The server main program //JAVA implemented by the user public class server { public static void main(String args[]) { try{// boilerplate initialisation... // create and initialize the ORB ORB orb = ORB.init(args, null); // START THE SERVANT HERE...(see next slide) // create servant and register it with the ORB TimeServant timeRef = new TimeServant(); orb.connect(timeRef); // block waiting for invocations from clients java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); } } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out);} }

29. Starting the servant // JAVA IOR method implemented by the user. There are many other possible ways, e.g. via the naming service. //... // create servant and register it with the ORB TimeServant timeRef = new TimeServant(); orb.connect(timeRef); // stringify the TimeRef and dump it in a file String str = orb.object_to_string(timeRef); String filename = System.getProperty("user.home")+ System.getProperty("file.separator")+"EchoIOR"; FileOutputStream fos = new FileOutputStream(filename); PrintStream ps = new PrintStream(fos); ps.print(str); ps.close(); //...

30. Bringing the server together

31. Now the client side: the client main program // JAVA implemented by the user import java.io.*; import org.omg.CORBA.*; public class client { public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // GET OBJECT REFERENCE HERE TimeOfDay tod = tm.get_gmt(); System.out.println(“Time in Greenwich is” + tod); } catch (Exception e) { System.out.println("ERROR : " + e) ; e.printStackTrace(System.out); }

32. Getting the object reference // JAVA implemented by the user. There are many other possible ways, e.g. via the naming service. //... // Get the stringified object reference and destringify it. String filename = System.getProperty("user.home")+ System.getProperty("file.separator")+"echoIOR"; BufferedReader br = new BufferedReader(new FileReader(filename)); String ior = br.readLine(); org.omg.CORBA.Object obj = orb.string_to_object(ior); Echo echoRef = EchoHelper.narrow(obj); // call the Echo server object and print results String echo = echoRef.echo("Hello, World"); System.out.println(echo); //...

33. Bringing it all together (again)

34. Running the application (under windows/dos) C:\ java server server.ior –run server in the background and direct to a file the stringified reference that it prints C:\ java client server.ior –pass the result of cat’ing the stringified reference file to the client as argv[1]

35. Expected learning outcomes you should be able to place the OMG’s OMA and CORBA in the overall context of middleware systems you should appreciate the role of the OMG in the middleware standardisation arena you should understand basic CORBA concepts in concrete programmatic terms you should be able to write simple CORBA programs (post today’s PM session at least!) you should appreciate the main additional features in CORBA v3.0 –you’ll learn more about the CCM later...