2. Java IDL and CORBA

Transcription

1 2. Java IDL and CORBA This lecture was developed by Russ Tront, Instructor, School of Computing Science, Simon Fraser University Section Table of Contents 32. JAVA IDL AND CORBA POA INTRODUCTION BACKGROUND POA-BASED CORBA (WRITTEN IN JAVA) AN IDL INTERFACE A POA SERVANT/SERVER A POA CLIENT RUNNING YOUR CORBA PROGRAMS REFERENCES EXERCISES Page 1 Page 2

2 2.1 Introduction to Recent Java/CORBA Developments This module introduces you to several new distributed object technology developments, two in the Java area and one in the CORBA area. In particular, it will briefly review how CORBA is used from Java in the traditional BOA way. Then we will look at the CORBA Object Request Broker (ORB) included in Java 1.2 that uses a Naming Service separate from the ORB. This is more in line with the newer Portable Object Adapter (POA) semantics defined in more recent CORBA standards being issued by the Object Management Group (OMG). POA semantics allow servers to be written in a manner that is not ORB-brand dependent. Previously, each ORB vendor had a different way of extending the earlier simple, but insufficiently-defined Basic Object Adapter (BOA) way to export remote objects. Java IDL is the name of the Sun Microsystems technology which allows CORBA Interface Definition Language (IDL) to be translated into Java interfaces. We will also preview a Java 1.3 feature called RMI-IIOP which allows CORBA to be used from Java without knowing CORBA s IDL language and POA semantics. In fact, the idea of RMI-IIOP is to program CORBA as if you were programming Java Remote Method Invocations. 2.2 Background Java IDL is the name given to a new feature in Java 1.2. It is not a version of CORBA IDL for Java. IDL after all, is supposed to be language independent! Since CORBA 2.2 there has been a formalized and approved mapping of IDL to Java. As with all CORBA (so called) language bindings, this is a specification of how IDL is translated into Java for use in clients and servers/servants, and how stubs and skeletons in that language should be generated. It provides a specification of how the idltojava compiler would translate IDL to a Java interface (not necessarily an RMI Remote interface!). This includes translations of: IDL modules into Java packages IDL interfaces into Java interfaces IDL exceptions into Java exceptions IDL attributes into Java get and set functions. IDL basic types like long, string, void to Java basic types. - and the creation of appropriately named and featured stubs and skeletons written in the Java language. There are some incompatibilities between the IDL and Java languages, and the idltojava specification indicates how these can be overcome by the creation of additional helper and holder classes. This specification is necessary to allow someone to either: write an IDL interface and then write the server in say C++, and Page 3 Page 4

3 have some clients (maybe not all) written in Java. alternately, write the server in Java, and have some clients written in another language like say C++. or, to have both client and server written in Java, and not use RMI but instead CORBA IIOP. An Object Request Broker is just a library of functions that can be linked to a client or server. It is not a huge complex thing, and doesn t really use a lot of RAM up when linked into a program. An ORB is just a software library containing distributed object functions rather than say sine(), cosine(), and tangent(). But an ORB product often also comes with extra programs like a Naming Service (somewhat like the rmiregistry program). And it is purchased in a particular language flavor, say, Inprise/Borland VisiBroker for Java. This provides: the raw ORB library of functions in such a way that they can be linked to/called from clients and servers written in that language, and translators like idltojava for programmer defined interfaces, and often a large array of sophisticated service programs in addition to the Naming Service, some of which could possibly be language specific (though most are not). So, if you want to write a client in Java and the server in C++, you have to buy BOTH VisiBroker for Java and VisiBroker for C++, because each language requires interfaces appropriately translated from IDL, and each language requires versions of the library that are callable from that language (though possibly C and C++ could use the same library?). And the proxy/stub must be generated in Java and the skeleton in C++. Obviously, you would run idltojava, Page 5 keep the resultant stub and discard the Java skeleton. And you would run idl2cpp, keep the C++ skeleton and discard the C++ stub. Sun s Java IDL feature included with the Java 1.2 release is a free ORB product, but must be downloaded separately as discussed below. It includes a idltojava compiler, a library of ORB classes, but only a very simple transient Name Service server. It does allow you to write clients or servers/servants that communicate with their opposites written in C++ for instance. But you have to by a ORB from someone else to do the C++ portion of such a project. Nonetheless, Java IDL allows Java programmers to experiment for free with CORBA, and it provides the basic functionality of a real Java ORB product. To download the Java IDL material, go to: Follow the instructions on Getting Started there. To download the material, you have become a member of the Java Developer Connection (free registration and newsletter). Note that CORBA does not (yet) provide automatic downloading of stubs, because the destination would have to be able to dynamically link to them (and the destination language might not be dynamic-link-capable). Additionally, the stub might be written in the wrong language for the destination! So only stubs in the appropriate language can be used in the client, and the MUST be shipped to every machine along with the client software. Similarly, the skeletons are shipped (sometimes hard linked) into every copy of the server software. And when not using a CPU-brand- Page 6

4 independent language (i.e. not Java), the stub and client must be appropriately built for every machine (e.g. Unix on Intel vs. Unix on Sun Workstation). For example, the IDL must be translated into stubs for Intel on the client, and into skeletons for Mac on the server. This means the skeletons generated by your translator on the Intel machine can be discarded if your server will only ever run on a Mac. This is true even if both client and server are written in the same language! This CPU awkwardness of CORBA is offset by its huge advantage of being language independent. This is particularly helpful when trying to connect to important huge old applications written in traditional languages such as C, COBOL, FORTRAN, PL/1, etc. One current trend is to try to put a modern graphical interface on the front of these applications. This GUI front end will often be running on a remote user client machine (allows fast pixel drawing), not on the back end mainframe which hosts the old application. Remember that some of these old applications could cost over a million dollars to rewrite; better to just tack a nice user front end on the existing code. And CORBA is the best way to permit this! You have probably already seen old style (Basic Object Adapterbased) CORBA. The object adapter is CORBA s term for how a server connects to an ORB and makes a distributed object available. Unfortunately, the BOA was under specified and every ORB vendor seems to implement it a different way, making server code and programmer knowledge non-portable between ORB brands. This occurred even though the procedure calls seemed similar from ORB brand to ORB brand. Page 7 For instance, Inprise/Borland s VisiBroker provided an API that included: A call to the ORB s BOA_init() function to initialize and get a reference to its BOA. Caused the servant object, because of inheritance from its Visibroker-specific _XXXImplBase parent, to automatically advertise its name to the BOA/ORB when the constructor was run. There was no distinct Name Service in old CORBA; the superclass constructor interacted directly with that brand s BOA/ORB which provided a name lookup service from within the BOA itself. The new distinct Name Service that emerged with the POA now has a sophisticated yet standard way to advertise an object (e.g. call nameservice.rebind()), and to find objects in complex, hierarchically-organized namespaces (e.g. call nameservice.resolve()). The more recent POA-compliant IDL to Java mapping creates POA compliant servants/skeletons by extending an _XXXImplBase class where XXX is the name of the interface the servant implements. The POA base and skeleton classes do not attempt to associate an advertised name with the newly created objects. This is done later with separate, standardized calls to the Name Service. Hopefully, this will allow objects on different brands of ORBs to interact, something which had proved difficult with the earlier BOA-based CORBA! The VisiBroker-specific call to BOA.obj_is_ready() was used export an object on a TCP port. In the new POA, this is replaced by a call to ORB.connect(). This export should likely now take place before registering the advertised name so that the registration can include the port information. (I m not sure how Page 8

5 this was done in the old BOA days. Perhaps the BOA.obj_is_ready() call would go fill in the blank port information already in the BOA). The next section intends to demonstrate using POA based CORBA from Java. 2.3 POA-Based CORBA (written in Java) You can write POA based CORBA in any language, and most recent versions of the commercial CORBA products support the new POA semantics. This section will show you how one commercial (but free) CORBA product, Java IDL from Sun, can access CORBA using POA function calls. The nice thing about the POA is that if you learn how to do this for Sun Java IDL: Your Java IDL clients and servants should be able to interact with objects implemented with other brands of ORBs. Your programs as a whole should (hopefully) work unchanged when recompiled for other Java ORBs such as VisiBroker for Java. You learn about the POA and thus programming to the POA API in another language such as C++ should not be hard for you to learn! And obviously, by using CORBA instead of RMI, you will be able interact with objects written in other languages! Page 9 Page 10

6 2.4 An IDL Interface //IDLDownCounter.idl //Note: For simplicity, this interface //has not been placed in a IDL 'module'. interface IDLDownCounter { ; void setcount(in long newvalue); long decrement(); If this looks familiar, it is because it is a CORBA IDL interface written to the same general specification as the Java RMI Interface in the RMI chapter of this course. In fact created this by editing the Java RMI one. Here is what I did. Just to contrast the two, this interface has a different name. I have removed the public keywords on the interface and the member functions. Interfaces are for publicity anyway so CORBA defaults to public; in fact the public keyword is not allowed. I removed the extends java.rmi.remote as CORBA interfaces don t need this. Remember, IDL interfaces are not language interfaces, they are language independent and are applicable to languages like C that don t even have inheritance! I removed the throws java.rmi.remoteexception. CORBA does throw exceptions, but the ones we are liable to encounter in this simple example are standard CORBA ones that don t need to be declared. As you likely know though, it is possible for Page 11 programmers to define their own additional exceptions in IDL. I have changed the int types to long. CORBA avoids the name int as its exact size varies in C/C++ from operating system to operating system (e.g. Win16 to Win32). long is a much more communicatively strong statement of the type of integer we actually want here. I added the parameter direction in. In CORBA IDL, all parameters have to be declared as either in, out, or inout. Interestingly, the interface needs a closing semicolon after the last brace! Run the idltojava translator. If using TextPad, you can create a new tool command by pointing to the translator binary and setting: parameters: -fno-cpp $File initial folder: $FileDir and checking save and capture. When you run the idltojava compiler on the above.idl file, you get a number of files output: 1. IDLDownCounter.java - the IDL interface translated to a Java language interface, as shown below. 2. _IDLDownCounterImplBase.java - a base class for the servant which in effect builds the skeleton functionality into the servant class via inheritance. 3. _IDLDownCounterStub.java - the stub expressed in Java. 4. IDLDownCounterHelper.java - an auxiliary class which among other things provides the narrow() member function required to cast CORBA object references of type any to a DownCounter servant reference. Page 12

7 5. IDLDownCounterHolder.java - holds an instance of the DownCounter class that can be passed using inout or out mode. These IDL modes do not map well to Java and this class helps get around that problem. Note these classes are in Java, and eventually need to be compiled into.class files either manually or (as Java sometimes does) automatically. Here is interface in Java: You might wonder why this interface does not declare that any exceptions are thrown. Even though the IDL interface does not throw any programmer defined exceptions, Java insists that you declare the exceptions your interface throws. Well, not quite. Java does not need exception throws declared if they are a subclass of java.lang.runtimeexception which the Java IDL org.corba.systemexceptions happen to be! (Note that in the RMI part of the course, we HAD to declare that java.rmi.remoteexception was thrown because this class of exception is NOT a subclass of java.lang.runtimeexception.) /* * File:./IDLDOWNCOUNTER.JAVA * From: D:\TEST\IDLDOWNCOUNTER.IDL * Date: Mon Aug 30 11:46: * By: D:\jdk1.2.2\bin\idltojava.exe Java IDL 1.2 * Aug :25:34 */ public interface IDLDownCounter extends org.omg.corba.object, org.omg.corba.portable.idlentity { ; ; void setcount(int newvalue) int decrement() Note that the long type has been translated to the equivalent Java int type. And obviously this interface inherits from others in the Java IDL product. Page 13 Page 14

8 2.5 A POA Servant/Server //IDLDownCounterServer.java // - chose to put servant in a separate class // which is also contained herein. // will need the naming service package. import org.omg.cosnaming.*; // and this package containing special exceptions // thrown by the name service. import org.omg.cosnaming.namingcontextpackage.*; // All CORBA Java applications need these classes. import org.omg.corba.*; //====First, the separate servant class========== class IDLDownCounterServant extends _IDLDownCounterImplBase { private int thecount; // //Constructor is NOT necessary in CORBA //(c.f. RMI) unless you //explicitly need it to do something. public IDLDownCounterServant() { super(); //optional; will be called anyway. thecount = 10; //default initial count. // public void setcount(int newvalue) { thecount = newvalue; Page 15 // public int decrement() { thecount--; return thecount; //========the main server program class======== public class IDLDownCounterServer { public static void main(string args[]) { try{ // Create and initialize the ORB ORB orb = ORB.init(args, null); System.out.println("ORB.init called."); // Create the servant and // register it with the ORB. IDLDownCounterServant reftocounter = new IDLDownCounterServant(); System.out.println("Servant instantiated."); orb.connect(reftocounter); System.out.println( "Servant connected to/available on ORB."); // Get the start-up/root Name Service. org.omg.corba.object objref = orb.resolve_initial_references ("NameService"); NamingContext ncref = NamingContextHelper.narrow(objRef); Page 16

9 // Create an advertised servant name. NameComponent nc = new NameComponent( "AdvertisedIDLDownCounterName", ""); // Note that name could be a path in a // hierarchical name space. Specify path // step names in a vector. NameComponent path[] = {nc; ncref.rebind(path, reftocounter); System.out.println( "Servant advertised to name service."); Also note how our main method of the server program class: 1. gets the ORB going, 2. creates a servant, 3. has the ORB put the servant on a port, 4. creates in our case a simple (non-hierarchical) advertised name and makes it known to the Name Service, 5. then waits for calling clients. // Wait for invocations from clients. // In CORBA, we cannot rely on garbage // collection delay to keep server alive. java.lang.object waitobj = new java.lang.object(); synchronized(waitobj){ waitobj.wait(); // An equally kludgy way to wait would be: //Thread.currentThread().join(); catch(exception e) { System.err.println("ERROR: " + e); e.printstacktrace(system.out); //end main method. Notice how the servant class inherits from the idltojava generated _IDLDownCounterImplBase abstract class, which in turn declares that its concrete subclasses must implement the IDLDownCounter.java interface. Page 17 Page 18

10 2.6 A POA Client //IDLDownCounterClient.java // We ll use the naming service. import org.omg.cosnaming.*; // CORBA applications need these classes. import org.omg.corba.*; /============================================ public class IDLDownCounterClient { public static void main(string args[]) { try{ // Create and initialize the ORB ORB orb = ORB.init(args, null); // Get the root naming context org.omg.corba.object nameserviceref = orb.resolve_initial_references( "NameService"); NamingContext nameservice = NamingContextHelper.narrow( nameserviceref); //(hierarchical) path of the servant. //Get back the servant as type ANY. //Must convert/cast it to the interface //type using the helper class's narrow(). IDLDownCounter remotecounter = IDLDownCounterHelper.narrow( nameservice.resolve(path)); System.out.println( "DownCounter instance found in registry."); System.out.println( "Beginning remote decrement invocations."); for (int i = 0 ; i < 5; i++ ) { System.out.println("Returned value = " + remotecounter.decrement()); catch(exception e) { System.out.println("ERROR : " + e); e.printstacktrace(system.out); //end of main. // Resolve the object reference // using COS Naming Service. NameComponent nc = new NameComponent( "AdvertisedIDLDownCounterName", ""); // Give the namespace path array one value. NameComponent path[] = {nc; //Below we pass to the naming service //the simple advertised COS namespace Page 19 Page 20

11 2.7 Running Your CORBA Programs As usual, we will start the name service, then the server, then the client. Java 1.2 seems to come with a CORBA transient Name Service in the jdk/bin directory (it is not part of the extra idltojava download stuff). To start the name server, bring up a DOS/NT Command window and assuming your classpath includes jdk/bin, type: C:\>tnameserv Initial Naming Context: IOR: c3a6f6d672e6f72672f436f 734e616d696e672f4e616d696e67436f6e a312e e616 d e e afabcaf e cb40541b TransientNameServer: setting port for initial object references to: 900 There are added parameters you can use on the command to set the Name Service listening port to other than 900. You might need this if you do not have administrator privilege your machine. E.g. C:>tnameserv -ORBInitialPort 1050 To start the server, use the following: D:\test>java IDLDownCounterServer ORB.init called. Servant instantiated. Servant connected to/available on ORB. Servant advertised to name service. Notice all but the command are outputs programmed by the server programmer. Again, if you want the server to go looking for the local name server on other than port 900, you will have add a parameter to the above command. To start the client, use the following if the client is on the same machine as the server: D:\test>java IDLDownCounterClient DownCounter instance found in registry. Beginning remote decrement invocations. Returned value = 9 Returned value = 8 Returned value = 7 Returned value = 6 Returned value = 5 D:\test>java IDLDownCounterClient DownCounter instance found in registry. Beginning remote decrement invocations. Returned value = 4 Returned value = 3 Returned value = 2 Returned value = 1 Returned value = 0 Page 21 D:\test> Page 22

12 Note I ran the client twice, to see if the servant stays alive and retains the count value between calls from clients. (Question: Is this servant thread safe?) If the server name service is on a different host from the client, and the port for it is non-standard you will need to start the client with these command line parameters: -ORBInitialHost other.machine.com -ORBInitialPort References [Orfali98] Client Server Programming with Java and CORBA, 2 nd edition by Robert Orfali and Dan Harkey, Wiley, This is a stunningly broad book on object-object oriented distributed computing. Also includes comparative performance for various ways of doing programming, including HTML/CGI (100 times slower than RMI or CORBA or Sockets), servlets (10 times slower), and Microsoft s DCOM. [Sun99] Sun s web site for Java is stunning in its content. For a peak ahead to how RMI will work over IIOP (look Ma, no IDL!), see for instance: Page 23 Page 24

13 2.9 Exercises Your instructor will likely make the code from the above examples available. Good exercises are: 1. Try running the code as is. 2. Try running the client on one machine and the server/servant on another. Do you have to give the client a hint as to where to find the Name Service provider? 3. Add code to the servant so that it calls a remote method exported from the client (!) to inform the client that the count has reached zero. Instead of having the client advertise this method in a name server, it would be better for the client to pass a remote reference to itself (i.e. a reference to a callback instance) in an initial call to the server. 4. Add code to move the call to rebind from the server main into the servant class constructor. The server can then create several/many servant instances without having to handle the rebind of each. Since each instance should have a different advertised name, perhaps the servant class will append a digit to the advertised name of each successive instance, or maybe you will add a non-default constructor which accepts the advertised name of the instance to be constructed in that constructor s parameter. 5. Study up on CORBA exceptions. Add code to the servant so that it throws a programmer-defined CORBA exception when the count falls to zero. Of course the client should have a custom try/catch block added to handle this (remote!) event gracefully. Page 25