|
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
-
java -cp ... dslab.reservation.Client booklist srstx_dslab777_1
"Cook113" "G." "Baron" 23 srstx_dslab777_2 "Sing114" "A." "Abap" 5
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.
-
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.
- 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.
-
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)
- Study the implicit and explicit transaction demos in the JacORB demo directory.
- All hints of Lab 5 are still valid here.
- 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/).
- 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!
- Use rebind instead of bind when you are registering
at the name service.
- 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.
- You can obtain references to implementations of the
Terminator and Coordinator interfaces via the Control interface.
- DO NOT INCLUDE the LOCK from the bank sample in your code. This may lead
to starvation, and hence timeouts.
.
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.
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.
- If you have created this file on some other machine, copy it over
using scp (secure copy).
- In your $HOME/lab6/src directory call submit6
- 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.
- 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.
- 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
Last Modified: Die Jän 2 14:41:31 CET 2007
|
|
|