Sept. 10th, 1999: SEC Study Group: CORBA -- Part II -- Java IDL

• Moderator: liuj
• Scribe: liuj

• started: 2:10PM
  
• ended: 3:20PM

• Study materials
• Notes
• Related issues
• Concluding notes

Study materials

• Jie: "Hello World" of CORBA, the developing process of CORBA programs.
  
  • JDK documents on Java IDL Concepts and Programming Guides
    
  • Java tutorial on IDL

• Ben: CORBA performance survey.
  
  • CORBA success stories
  • A good CORBA FAQ
  • CORBA performance study web pages:
    • D. Schemit at WUSTL
    • A. Buble at Charles University, Czech
  • CORBA performance study papers:
    • Ghokale and Schmidt, "The Performance of the CORBA Dynamic Invocation Interface and Dynamic Skeleton Interface over High-Speed ATM Networks." In Proc. IEEE GLOBECOM '96 conference, November 18-22nd, London, England

• John Koo: Of-the-shelf products and users.

  Some useful links:
  

  • Object Management Group
  • ObjectTime - Embedded Software Solutions
  • IONA Rechnologies - Orbix

• Xiaojun: Status of the Real-time CORBA and Minimum CORBA communities.

  Discussion leaders may put the handouts on the web or bring them to the meeting.

Notes

Some discussions are highlighted here:

• Technologies for distributing computational components

  People seems agree with the concept that distributed components should base on objects. There are technologies from various communities and companies, includes:
  

  • COM/DCOM from Microsoft.
  • CORBA from OMG.
  • JavaRMI from Sun.
  • JINI from Sun.
  Each of them has pros and cons. Among them, CORBA is a community standard, (so it is "big"). But it is also the only one that supports platform transparency and programming language transparency.

• CORBA is a specification that takes no care about Quality of Services

  This has its historical reason since at the time that CORBA was defined (early 1990s), QoS is hardly a critical issue in general network applications, and few people had thought that CORBA would be used in embedded systems. The CORBA specification largely leaves the QoS issues to individual implementations. TAO as one of the pioneers of real-time CORBA, provides one solution to add QoS specification and real-time scheduling features to CORBA. We will look at it more carefully next week. Today, there is a real-time community in OMG. As Xiaojun pointed out, it is still in progress.

  There are some possible solutions to our problem -- use the flexibility of CORBA in real-time control systems, with sufficient QoS guarantee --
  

  • Use/reconfigure TAO
  • Use a proper commercial ORB product and improve it.
  • Build "SEC ORB"

  We pulled out presentation slides from Georgia Tech (May 19-20, 1999) to see what systems we may deal with.

• CORBA architecture review.

  I think it is necessary to put the CORBA architecture diagram here.

  
  Figure from http://www.cs.wustl.edu/~schmidt/corba-overview.html

• What will the verification tasks fit in?

  Tom raised this question (or something similar?). CORBA says nothing about the logical correctness of an application. Eventually, we will need some concurrency models built atop CORBA, for example, event channels or CPS. On that level, verification is certainly an issue.

• Performance issues.

  We didn't have enough time to go to the detail of this. I think the links above by Ben are excellent. And we realized that the performance study on the-Internet-based applications might not be the same as the performance study that we want.

• Off-the-shelf ORB products.

  We didn't have enough time to talk about this either. John mentioned Orbix from IONA, which support some real-time operating systems, like QNX.

• The development process of a CORBA-based program.

  We have a somewhat extended example than the HelloWorld given in Java Tutorial. But we follow the basic development step described there:

  1. Writing the IDL Interface
     • Declaring the CORBA IDL Module
     • Declaring the Interfaces and Exceptions
     • Declaring the Operations
     Here is the SimpleHelloWorld.idl we have.

  2. Compiling the IDL Interface

     idltojava -fno-cpp SimpleHelloWorld.java

     where -fno-cpp simply indicates that there is no c++ preprocessor.

     Compile the IDL code will generate the source code for your programming language, say Java. Java's idltojava compiler generates a subdirectory with the name of your IDL module (in our case, SimpleHelloWorld).
     Although you may do this step later, I usually do it before I write any client or server codes. The reason is that I would know which class to extend.
     Usually you don't have to know what's inside the generated files other than know which is which. Here is a list of the files:
     On the server side:
     

     • _GoodDayImplBase.java. The skeleton. The servant code extends it.
     Note that the idl compiler assumes that the Exception is defined locally at the server side. So the Exception defined in IDL is solely for the clients.

     On the client side:
     

     • GoodDay.java. The Java inferface for the GoodDay interface defined in the IDL.
     • GoodDayHelper.java.This final class provides auxiliary functionality, notably the narrow() method required to cast CORBA object references to their proper types.
     • GoodDayHolder.java.This final class holds a public instance member of type GoodDay. It provides operations for out and inout arguments, which CORBA has but which do not map easily to Java's semantics. It does so in case some (other) code has SimpleHelloWorld as its out arguments.
     • _GoodDayStub.java. This is the stub code that the client may call. It implements the GoodDay.java interface.
     • The exceptions are generated so that the client side can use it easily.
       • DontCallMeException.java
       • DontCallMeExceptionHelper.java
       • DontCallMeExceptionHolder.java

  3. Developing the Servant
     Servant is a concrete class that implement the IDL interface. You can think of it as the "server" in the client-server concept, but server is usually something else in CORBA. Our servant code ExampleGoodDayImpl.java is here. Notice that there is nothing about "network programming" in this code, other than that you should know which class the ExampleGoodDayImpl should extend.

  4. Developing the Server
     • Creating an ORB Object
     • Instantiating the Servant Object
     • Obtaining the Initial Naming Context
     • Narrowing the Object Reference
     • Registering the Servant with the Name Server
     • Waiting for Invocation
     Here is the SimpleHelloWorldServer.java code.

  5. Developing a Client Application
     • Creating an ORB Object
     • Finding the SimpleHelloWorldServer by looking up the name
     • Invoking the Remote Operation
     Here is the SimpleHelloWorldClient.java code.

  6. Compiling the package

     javac *.java

  7. Executing
     • Start JDK transient name server with a proper port, say on machine "foo"

       tnameserv -ORBInitialPort 1050

     • Start the server, give the host and port of the name server.

       java SimpleHelloWorldServer -ORBInitialHost foo -ORBInitialPort 1050

     • Start the client, give the host and port of the name server.

       java SimpleHelloWorldClient -ORBInitialHost foo -ORBInitialPort 1050

Related issues

1. We need to put the links of ORB products on the SEC web.
2. The SEC effort at Gatech can be found at http://uav.ae.gatech.edu/sec.

Concluding notes