Distributed Systems Lab/06


Lab 6 / CORBA Transaction Service Aware Seminar Reservation System

Introduction

In the previous lab you did some practical exercises with a CORBA ORB. In this lab, you will "extend" your code by using the CORBA transaction service. You already used the CORBA name service to register your server in a repository in order to lookup a server object by user-readable names instead of opaque Interoperable Object References (IORs).

This time, you will use the CORBA transaction service to let multiple object servers work together in a distributed transaction. You shall use this transaction service to realize an all or nothing policy: either all requests succeed or none.

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 coverage of services. 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, notification and security services.

Detailed Description

Your task in this lab assignment is to enhance the reservation system of the last lab by two new CORBA servers. You have to define both IDL interfaces on your own in a new IDL file. One of these interfaces shall be called TxSeminar that extends the Seminar interface. The prefix Tx shall denote the interface as transaction service aware. However, the CORBA ORB ignores naming conventions, hence you also have to extend CosTransactions::Resource and the CosTransactions::TransactionalObject interfaces. You can reuse all code you have written in Lab 5. If you have not done Lab 5 you need only write code appropriate for Lab 6. At every place where in Lab 5 the Seminar interface has been required you should now use the transaction aware interface TxSeminar. You have to use implicit(!) transactions for accomplishing this tasks. Consider also looking at the JacORB implicit transaction demo.

Introduce also a new IDL interface for a transaction aware seminar reservation system that extends from the corresponding interface of Lab 5. You will probably need additional methods but you should consider yourself which ones are appropriate.

The interface must be named SeminarReservationSystem_dslabXXX where XXX denotes your account number. The file where this definition resides has to be named reservationprivate.idl. Put a #include "reservation.idl" statement at the top of your file to include the old reservation.idl file. For importing the transaction interfaces (CosTransaction) you must also include an #include <CosTransactions.idl>.

Transaction aware seminar Client Functionality

As in Lab 5, you have to implement a "non-interactive" client (i.e., your client only accepts one command and then terminates). Unless not explicitly specified below, no client output is required. You shall support the same 3 commands as in Lab 5. In addition, two further commands shall be supported: booklist and cancellist. The syntax of these commands is similar to the corresponding commands of Lab 5 but now can take a list of seminars to book or cancel. The number of elements in the list can be calculated based on the total number. We will not test these commands with an invalid number of arguments!

Examples

  1. java -cp ... dslab.reservation.Client booklist srstx_dslab777_1 "Cook113" "G." "Baron" 23 srstx_dslab777_2 "Sing114" "A." "Abap" 5
  2. The above example executes bookings at two different (!) seminar reservation systems. However, both bookings must run in a transaction and hence in case of a failure no data shall be modified.

    The same conventions for printing error messages and exit codes that are valid in Lab 5 are also valid for this lab.

    Transaction aware seminar Server Functionality

    To enhance the server you have to build a new interface that extends the Seminar interface of Lab 5 ,the CosTransaction::Resource and the CosTransaction::TransactionalObject interfaces. The CosTransaction::TransactionalObject is just a markup interface and hence has no operations at all (primary a historic relict from previous CORBA standards). However, you have to implement the 5 operations of the Resource interface. You can skip implementing the forget operation and implement the commit_one_phase operation as in the JacORB sample.

    The prepare method shall return one of the three values Vote.VoteCommit, Vote.VoteRollback, Vote.VoteReadOnly depending if the changes shall be commited, or rolled back. Vote.VoteReadOnly shall be used if there were no changes at all. It is allowed that you stick totally on using exceptions and you simply return Vote.VoteCommit. However, this depends on your implementation decisions.

    The commit method makes any changes to a seminar complete. The rollback method undoes these changes.

    Transaction Handling

    Following steps have to be used to use the transaction server within client or server.
    1. When using explicit transactions a reference to a transaction Control interface has to be propagated in object calls.

      In this Lab we want to use implicit transactions. This means that transaction contexts storing the current state of a transaction are not directly visible in Client or Server code but is automatically added by so-called interceptors - in CORBA interceptors hook in requests and may modify the transmitted data such as arguments or may add service contexts such as in our case.

      To inform an ORB that it shall use the already predefined interceptor for implicit transactions the ORB init method takes also a java.util.Properties argument that takes a property with value org.jacorb.transaction.TransactionInitializer. This is a class that registers an object of type org.omg.CosTransactions.Current as an initial reference named TransactionCurrent. This variable can then retrieved with orb.resolve_initial_references. The key of the property may be arbitrary but must start with org.omg.PortableInterceptor.ORBInitializerClass.<. You may use the same property keys as in the JacORB demo.

    2. The operations of the org.omg.CosTransactions.Current interface may be used to initiate a transaction from clients (aware that a transaction client might also be another CORBA server). The timeout shall be set to a value of 40. This has to be set before you begin a transaction. After a transaction has begun you can call whatever transaction aware functionality of CORBA objects you want. The transaction context is transmitted implicitly. For rolling back a transaction you have to call the rollback function (surprisingly). Committing the transaction is done via the commit operation (use true as argument). Never kill a server (regardless how) that has started a transaction before the timeout has passed. When you do manual tests you can set the timeout to a smaller value.
    3. From transaction aware objects you have to use the org.omg.CosTransactions.Current interface, too. However, this time you shall receive the org.omg.CosTransactions.Control interface via the Current's get_control operation. Control supports two different functionalities: returning a Coordinator (with get_coordinator) and returning a Terminator. In transaction aware operations you have to register the transaction aware CORBA object with the coordinator's register_resource operation. The Resource's operations (prepare,rollback,commit) are then used automatically when the client calls commit or rollback. In case of any TransactionServer related exception (example: Inactive) throw the runtime exception org.omg.CORBA.TRANSACTION_ROLLEDBACK. To get the exact syntax of the transaction server related operations take a look at the CosTransactions.idl.

    Very Useful Hints for Solving the Lab (Read Them)

    1. Study the implicit and explicit transaction demos in the JacORB demo directory.
    2. All hints of Lab 5 are still valid here.
    3. For compiling IDL files that contain a <CosTransactions.idl> include statement the path to the directory where this file resides has to be provided with the -I option (eg. -I/opt/JacORB/idl/omg/).
    4. The server and clients MUST provide a property list during ORB initialization that contains following key-value pair Key:org.omg.PortableInterceptor.ORBInitializerClass.TSClientInit or org.omg.PortableInterceptor.ORBInitializerClass.TSServerInit with the value org.jacorb.transaction.TransactionInitializer. This setting is required for creating transactions implicitly. Without this setting you will only get exceptions!
    5. Use rebind instead of bind when you are registering at the name service.
    6. If you work at home, you have to start the JacORB transaction service. It is located in the JacORB/bin directory and can be started with the ts script. However, it is absolutely necessary that a nameserver is started before, and that this nameserver's IOR is accessible via a path a configuration file points to. You have to provide this configuration file either in a standard directory, or provide the -Djacorb.config.dir parameter to the transaction service.
    7. You can obtain references to implementations of the Terminator and Coordinator interfaces via the Control interface.
    8. DO NOT INCLUDE the LOCK from the bank sample in your code. This may lead to starvation, and hence timeouts.
    9. .

    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. 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.
    2. If you have created this file on some other machine, copy it over using scp (secure copy).
    3. In your $HOME/lab6/src directory call submit6
    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. Transaction Service SpecificationThis is the original OMG Specification. In general, it is not necessary to read all of this. However, in Section 2 all involved CORBA interfaces are explained (as Resource, Control, Coordinator, Terminator).
      The JacORB bank demo shows how to work with (implicit) transactions and is a good reference for this Lab.
    1. CosTransactions.idl contains the IDL declarations for the CORBA transaction service. Although not documented there the interfaces alone show some useful insights. In the Lab it is located in the /opt/JacORB/idl/omg directory.

    Deadline

    You need to submit your solution until January the 25nd.

    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