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.
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:
- The first argument is always the name of your seminar reservation system. Please use your account name for
testing purposes.
- The second argument is a String that is either create, book, or cancelBooking. Depending on this String
argument the respective command shall be invoked.
- 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
.
- 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
-
java -cp ... dslab.reservation.Client srs_dslab777 create "Cook113" "Cooking for Computer Scientists" "Jamie Oliver" 120
-
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)
- 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!
- 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. -
If you want to work at home and prefer to install JacORB on your own machine you need to do following steps:
- Download a jacorb (source) distribution.
- Untar the jacorb distribution file into any directory you like.
- 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.
- 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!
- 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.
- 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.
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.
- 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:
- 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.
- If you have created this file on some other machine, copy it over
using scp (secure copy).
- In your $HOME/lab5/src directory call submit5
- Read any error or success messages
- 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.
- JacORB Programming Guide (from the JacORB Team) Especially Chapters 4 and 5 are relevant for this lab.
- 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.
- 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
Last Modified: Die Jän 2 14:41:31 CET 2007