Distributed Systems Lab/06


Lab 5 / CORBA Seminar Reservation System

Introduction

In the last two labs, you learned RMI, a distributed object technology. This lab assignment gives you hands-on experience with another distributed object technology: CORBA (Common Object Request Broker Architecture). While RMI can solely be used in Java environments, CORBA is platform and language-independent. In DSLab, we do neither require nor support the implementation of applications in programming languages other than Java. However, CORBA provides support for a wide range of programming languages such as Java, C, C++, Ada and Eiffel and is an important technology to be familiar with when working as a software engineer or designer. The primary difference of CORBA to other distributed object systems such as RMI or .NET Remoting is the mandatory use of an Interface Definition Language (IDL) to define the interfaces of distributed objects. The use of such a definition language provides the multi-language feature of CORBA.

CORBA Objects are hosted by server applications that provide one or more object instances to clients. The communication of both the client and the server is done with so called ORBs (Object Request Brokers) that deal with marshaling (encoding arguments in a platform independent-format) and unmarshaling (decoding platform-independent data type representations into platform specific formats) and invocation of CORBA operations. One primary advantage of CORBA compared to other technologies such as RMI, .NET Remoting, or Web services is its completeness. That is, CORBA supports the full set of additional services that are required in most distributed system environments such as naming and trading, transaction and synchronization, and security services.

Detailed Description

Your task in this lab assignment is to implement a (simplified - of course) seminar reservation system with CORBA that supports the creation, booking and canceling of seminars for customers. The CORBA implementation we will use and support in this lab is JacORB. You have to implement a CORBA server that implements the functionality required for a seminar reservation system and you have to implement a client that accesses it. Each CORBA server registers itself in a name server that can be accessed by your client application and the client applications built by other students. Don't be put off by this "long" task description. After reading the CORBA tutorials, you will see that the task is not as complicated as it sounds.

IDL files (see as example: SeminarReservationSystem) are used as input for a so-called IDL compiler. These IDL files include CORBA type definitions in an platform independent format. With a so-called IDL compiler platform dependent code is generated. In DSLab the IDL compiler generates Java code that supports access to CORBA objects from Java code. Other ORBs ship with other IDL compilers and may generate access code for other languages and platforms.

Your client shall have the capability to access all features of your own server via CORBA interfaces. The client shall also have the capability to access servers that implement the SeminarReservationSystem and Seminar CORBA interface provided by us. This includes the server you build yourself and potentially also servers built by other students as well as our own servers.

Your server has to implement the SeminarReservationSystem CORBA interface that is provided by us. The server shall create one instance of this CORBA object and registers it at the standard CORBA name server with the name provided as first command line argument. The implementation of the SeminarReservationSystem contains methods for creating and listing seminars. These methods return CORBA objects that implement the BaseSeminar interface. In Lab 5 the sole implementation for this interface is in form of the Seminar interface. This interface extends the BaseSeminar interface by several methods/attributes. In Lab 6 the example will be extended further by another interface that extends BaseSeminar. In addition to the implementation of the SeminarReservationSystem CORBA interface you need also an implementation of the Seminar CORBA interface. However, the implementation of this interface is quite simple and contains primarily methods for accessing the data required for defining seminars.

Seminar Client Functionality

In this lab, you implement a "non-interactive" client (i.e., your client only accepts one command and then terminates). Unless not specified below, no client output is required. The client has to implement a command-line front-end for following methods of the SeminarReservationSystem interface: create,book,cancelBooking. The arguments that your static main method of your client has to support are specified as follows:

  1. The first argument is always the name of your seminar reservation system. Please use your account name for testing purposes.
  2. The second argument is a String that is either create, book, or cancelBooking. Depending on this String argument the respective command shall be invoked.
  3. The following arguments depend on the command determined by the second argument. For the create command these arguments are just Strings that correspond to the same arguments of the create operation of the SeminarReservationSystem.
  4. For the book and cancelBooking commands the third argument denotes an identifier of a seminar. You have to query all seminars and look up the right seminar. The next two arguments are the first name and the last name of a customer - in this order! The sixth argument is a numeric argument that specifies the places that shall be booked or removed from an existing booking.

After each command has been invoked the client process should terminate with exit code 0. In the error case an error message shall be printed to System.err, and the client process should terminate with exit code 1.

If the client is started with none or an invalid operation String (as first argument) the client should respond with the error message:

Unsupported command! The same error message shall be reported if an invalid argument has been provided - regardless for which argument. Most arguments are just Strings and it is not required to do any argument checks.

The client class that is started by the grading robot has to be called "dslab.reservation.Client".

Examples

  1. java -cp ... dslab.reservation.Client srs_dslab777 create "Cook113" "Cooking for Computer Scientists" "Jamie Oliver" 120
  2. java -cp ... dslab.reservation.Client srs_dslab777 book "Cook113" "G." "Baron" 23

Seminar Reservation System Server Functionality

In order to complete the server part of this lab you need to implement the CORBA server and the two implementations of the two interfaces SeminarReservationSystem and Seminar.

The server always takes one mandatory command-line argument that denotes the name/identifier of its implemented seminar reservation system (only one reservation system is hosted by one running CORBA server which is the default setting for most ORB implementations!). The reason for using this argument is that we (and you, too) can register different implementations at one and the same name server. java -classpath ... SeminarReservationSystemServer SRS_dslab733

This invocation starts the server and registers the Seminar reservation system in the name server with the name SRS_dslab733.

If an invalid number of arguments has been provided, the server process should terminate with exit code 1 and display the message:

Invalid number of arguments!

In the case of any CORBA related error the server (example: no contact to the name server is possible) shall respond

Internal CORBA error!

on System.out and terminate the process with an exit code 3.

After analyzing the command-line arguments, the server has to register itself at a naming server with its name (consider to use the org.omg.CosNaming.NamingContext and NamingContextExt interfaces). This name is then used by all client(s) to find the appropriate seminar reservation system. Important: Just use the name that is provided as the argument, you don't need to consider any hierarchical naming scheme. If a seminar reservation system is already registered in the naming service with an identical name, it should be removed and replaced by the new service. Please, note that the grading robot uses a two-part name component for accessing your server. The first part is the name from the command-line argument, the second part is just the string "server". Consider also Hint 8.
When the service is stopped normally (not killed abruptly) or abnormally, you don't need to remove the registration within the naming service (unbinding). Usually, this is done automatically by the JacORB naming service.

Implement the SeminarReservationSystem interface first. Consider that you implement the methods of the interface as specified in this file. You must only throw the exceptions declared in the IDL file.

The create and listSeminars methods create new seminars or return an sequence (= array) of existing seminars in the one seminar reservation system. Seminars are returned by listSeminars in the same order as they are created. The create method creates new instances of seminars. The implementation class of such a seminar has to implement the appropriate CORBA interfaces. Instance creation in CORBA is similar to the creation of Java instances with one difference: you have to create a CORBA object from a Java object via the servant_to_reference method provided by the POA. The seminar reservation system has to administrate all created seminars for returning a list of seminars.

The book, cancelBooking, and rebook methods create or remove seminar reservations for customers. The information shall be stored in the implementations of the seminars. You should use the appropriate methods of the Seminar interface: book and cancel to modify this information. Rebooking of seminars is only allowed if they have the same name (there may be more seminars for one seminar name. The seminars are distinguished by their IDs).

The customer information is stored in an IDL type Customer. This is a so-called (CORBA) value type. When you transfer a (normal) CORBA object across the wire only a reference (Interoperable Object Reference = IOR) is transfered between ORBs, ie only enough information is transfered to access that CORBA object regardless where it is hosted and executed. In contrary to this, value types are completely serialiezd (=marshaled=converting the contents of the object to a portable format) across the wire and are de-marshaled (converting to the in-memory representation) at the called object. Although the IDL compiler creates a base class for Customer that contains the required data fields (eg. lastName and firstName for Customer) this base class is abstract and has no appropriate constructors. You need to create your own non-abstract implementation class that extends this base class and includes an appropriate constructor (you shall decide yourself which constructor(s) you need).

At the server side the ORB needs information which implementation class shall be instantiated for such a value type. Although JacORB supports automatic creation of value types based on some class naming conventions you shall implement a so-called value factory which sole task is the creation of instances of value types. This value factory has to implement the org.omg.CORBA.portable.ValueFactory interface and requires a default constructor (constructor without arguments). The single method of the value factory read_value shall use the Customer class's read_value method to fill an instance. An instance of the value factory has to be registered at your server startup code to the ORB with the method register_value_factory. The IDL identification string required as first argument to this method shall be "IDL:dslab/reservation/gen/Customer:1.0".

The main thread of the server blocks when you invoke the run method of your ORB instance. This is intended! The methods of your CORBA object can still be invoked. The usual way to come around this limited behaviour is to implement another interface that includes a stop operator that calls the ORB's shutdown method. This year we do not require that you implement this.

Very Useful Hints for Solving the Lab (Read Them)

  1. Study the JacORB programmer's guide, in particular chapter 4 - Getting Started - explains how to program a CORBA server and a CORBA client with JacORB. Chapter 5 explains how to access the name service. Chapter 4 contains everything you need to implement your server and client. You must not use any Java threads in your code!
  2. Although there are other ways to configure JacORB, the preferable way is via the jacorb.properties file that is located in the /opt/JacORB-2.2.4/etc directory (stored under the name jacorb_properties.template). On startup of your client and server you have to provide -Djacorb.config.dir=/home/uebungen/dslab/dslabXXX/lab5 (or wherever you have put your configuration files - the previous setting requires that you have created an etc directory under the lab5 directory and have copied the jacorb.properties file to this directory. You have to replace XXX with your account number). You may also copy the jacorb.properties file to the directory from which you start client and server. Then you may omit this start parameter. The configuration file is necessary to locate the naming service.
  3. If you want to work at home and prefer to install JacORB on your own machine you need to do following steps:
    1. Download a jacorb (source) distribution.
    2. Untar the jacorb distribution file into any directory you like.
    3. Execute ant (bye the way you need ant for the installation) in the JacORB directory, it adapts some of the provided scripts to your directory structure (and compiles the whole JacORB package including the IDL compiler).
    If you have installed everything you need to start the name server either with the bin/ns or bin/ns.bat scripts in the JacORB directory. The preferable way is to provide the -Djacorb.naming.ior filename=filename parameter. The location of this filename has to be writable for the user that starts JacORB. In this location an IOR (Interoperable Object Reference) for the name service is stored. IOR's contain contact information for CORBA objects. Finally, you have to provide a jacorb.properties file where you have to put the location of this IOR file to the ORBInitRef.NameService= key. Example: /home/jacorb/config.1/etc/my_ns.txt. You can copy this file from the lab environment or from the JacORB etc directory. Important: you don't need to start the name server in the lab environment.
  4. As a starting point, compile the IDL file we have provided. This is a two-step process. First, you have to use the IDL compiler that ships with JacORB. Subsequently, the Java source files generated by the IDL compiler have to be compiled with the Java compiler too. The IDL compiler is located in /opt/JacORB-2.2.4/bin. There are a couple of command-line parameters that can be used (see the help with the -h option). Usually, none is required, since our idl files already contain some module information that automatically stores the files in appropriate packages. Remark: Different Java constructs are generated from IDL constructs. These generated Java files will reside in the dslab.reservation.gen package. Study these files. You will have to use some of them. The implementation class of your server will have to extend an appropriate POA class generated by the IDL compiler!
  5. If you prefer you can also use ant for compiling your sources. We provide you a stub ant build.xml file that may act as a starting point.
  6. In order to use JacORB instead of the built-in (and incomplete) ORB of SUN that is provided with Java, you have to provide two arguments to the VM with -D:

    -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
    -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton

    You also have to include the jacorb.jar, the logkit-1.2jar, and the avalon-framework-4.1.5.jar files in the CLASSPATH (The first contains the JacORB implementation, the other jar files contain utility classes used by JacORB). Instead of manually applying these settings, you can also use the jaco shell script that is located in the /opt/JacORB-2.2.4/bin directory. This script invokes java with the appropriate VM arguments and classpath settings. Note that you still have to provide the name of the Java class you would like to start. You still have to provide the -Djacorb.config.dir parameter if you don't have a jacorb.properties in your local directory.
  7. The name server on which you have to register your server tasks is automatically found by JacORB when the correct path of the file with the name server's IOR reference is set (an IOR reference is stringenized reference of the address of a CORBA process, it contains sufficient information to contact the appropriate host) in the jacorb.properties file under the ORBInitRef.NameService key.

    There are a couple of settings responsible for logging issues (when you correctly start JacORB from your class you get some information you probably never will need) where you can try out a lower log level.

  8. When you register your reservation system at a naming server ALWAYS register your server with a name that is prefixed with your account. Example: srs_dslab765. This is not a problem of our lab environment but it is rather easy to remove another student's server from the naming service if you use the same identifier. And then debugging gets funny!
    As the second part of the component name please use just the String "server" (second argument to NameComponent).

Deliverables

To submit your solution to us, you need to follow these steps:

  1. Develop your solution in Java (version 1.5), writing the code for starting the client into the Client class in a file called Client.java and the code for starting the server into the Server class in a file called Server.java. Put all your files in the all your files in the $HOME/lab5/src/ folder and use the provided package names. The only constraint is that all your classes (and potentially interfaces) use the package name dslab.reservation. The java files that are created by the idl compiler should be created into the dslab.reservation.gen package. Make sure that your Java program compiles and runs in the lab environment. You can implement and use as much classes as you need. Put also the IDL file into the src folder. The grading robot needs this file.
  2. If you have created this file on some other machine, copy it over using scp (secure copy).
  3. In your $HOME/lab5/src directory call submit5
  4. Read any error or success messages
  5. It might take up to an hour for our grading robot to check your program. Don't forget to read your e-mail to check the results of the automatic grading robot. If you have errors, correct them and try again!

Reading Suggestions

The following reading suggestions should help you in developing your solution.

  1. JacORB Programming Guide (from the JacORB Team) Especially Chapters 4 and 5 are relevant for this lab.
  2. JacORB Demo Samples. In the JacORB distribution there are many examples that are useful for solving Lab 5 (and also Lab6). These samples are located in JacORB's demo directory. On the Lab servers you can find the JacORB distribution in the /opt/JacORB-2.2.4 path.
  3. Java CORBA Tutorial (from Sun Microsystems Inc) Be careful: this document does not focus on JacORB

Deadline

You need to submit your solution until January the 18th.

Closing words

Have fun ;-)


Last Modified: Die Jän 2 14:41:31 CET 2007


Distributed Systems Group, Technical University of Vienna, Argentinierstrasse 8 / 184-1, 1040 Vienna, Austria, www.infosys.tuwien.ac.at