CORBA problems

The purpose of these sample programs is to illustrate the inner workings of Java IDL with CORBA using some very simple examples. The sample programs were tested using the JDK 1.2. The downloable files contain java sources and some remarks in Winzipped format.

1. ASYNCHRON SERVICE CALLING [download]

The purpose of this example is to demonstrate the asynchronous service request.

Problem: Client wants to start a - long running - method on server side without waiting for the result (fork). When client finishes its activity, it waits for the result (join).

2. BATTLESHIP GAME SKELETON [download]

The purpose of this example is to demonstrate a structure in which the client and the server are identical, consequently there is only ONE program which is playing both the server and client role.

Problem: Let a battleship game skeleton. A player defines a battlefield. He can receive a shot from a player and answer it. He is also able to shot the field of an other player. The source of the incoming cannonballs and the target field's owner can be different players.

The battlefield is an 8*8 boolean array which is filled randomly. A player sends a message (a coordinate-pair) to its partner as a shot. A boolean returns, the value of the partner's battlefield array indexed by the coordinates.

No synchronisation and scheduling.

3. ADVANCED CALLBACK DEMONSTRATION [download]

The purpose of this example is to demonstrate the callback facility of CORBA for solving a publisher-subscriber problem.

Problem: There is a central accumulator, implemented by the servant. Clients can register themself (subscribe). Registered clients have the right to add numbers to the accumulator, and they are notified if change has been occured in the accumulator. Clients can give up (finishes) the subscription.

4. FACTORY ON THE SERVER SIDE [download]

The purpose of this example is to demonstrate the usage of run-time generated server objects.

Problem: There is an object factory on the server side who generates Nbr (simple wrapped int) objects. We want to use these generated objects from the client.

5. PARAMETER PASSING 1. [download]

The purpose of this example is to demonstrate the parameter passing scheme of CORBA using Holder classes.

Problem: The client program passes 3 parameters to the server.

6. PARAMETER PASSING 2. [download]

The purpose of this example is to demonstrate the parameter passing scheme of CORBA. The passed parameters are a user definied object and an array of it.

Problem: The client program passes 2 parameters to the server.

7. PARAMETER PASSING 3. [download]

The purpose of this example is to demonstrate the parameter passing scheme of CORBA taking into consideration the inheritance. The passed parameters are a user definied object and a sequence of it.

Problem: Let an abstract object (MyNbr) be. It has two methods:

This object has two descendants: MyInteger and MyFract. Fractured number is represented in MyFract as a pair of int (num and denom). Both objects define set method. The client passes an object of MyNbr and an array of MyNbr as a sequence.

8. ANY AND OBJECT SERIALIZATION. [download]

The purpose of this example is to demonstrate the usage of the Any parameter and the object serialization

Problem: Passing two parameters: an Any and a Java Stack. Any is only for demo purpose, it is actually a short. It is a good point to show the usage of the TC and TCKind. Passing a Java class is a bit difficult, because in the IDL we are not able to define a standard Java class, eg. Stack. The only way is the object serialization.

9. DYNAMIC INVOCATION INTERFACE AND DYNAMIC SKELETON INTERFACE. [download]

The purpose of this example is to demonstrate the usage of dynamic connection between remote objects

Problem: Let a servant be for getting two string parameters and returning also a string. Realize this servant using the objects generated by the idltojava compiler (static service) and managing the invocation by an own skeleton (dynamic service, DSI). Let a client be for calling the servant defined above. Realize the client by static service provided by idltojava compiler and dynamical (DII).

10. SIMPLE THREE-TIER ARCHITECTURE. [download]

The purpose of this example is to demonstrate the usage of a simple three-tier architecture.

Problem: There is a database, which is accessed via JDBC from a simple business layer. The business layer is displayed by a simple applet. On the applet one can insert a query, the query is run by the business layer, and the database's answer is displayed by the applet.

11. THREE-TIER WITH ADVANCED BUSINESS MODEL [download]

The purpose of this example is to demonstrate the usage of an advanced three-tier architecture.

Problem: There is a database, which is accessed via JDBC from a business layer. The database has two tables, one for cat owners with their name and department, and the other for the cats, with their owner's name, the cat's name, and a picture of the cat. An owner can have more than one cat. The business layer is displayed by a simple applet. The applet has two lists and a picture. The first list lists all owners with their name. If one clicks on an owner's name, in the second list the selected owner's cats are shown. And if one selects a cat from the second list, the cat's picture is shown.

12. MOBILE AGENT PROTOTYPE USING CORBA. [download]

This prototype system implements the mobile agent concept using CORBA. All such object can be an Agent, which implements the Migrateable and Serializable interface.

public interface Migrateable { public String execute(String ss) throws Exception; }

Agent can contain embedded objects too.

The Agent - constructed in the client - visits all the server listed in th Itinerary in order. In all server the Agent executes its execute( ) method. The agent system automatically passes the name of the server as input parameter. The return string - preceded with the name of the server - will be send to the client automatically. The server process also send message to the client if exceptions occure. While the Agent moves from one server to the next it saves its current state. When there is no more entry in the Itinerary the process stops. The client must catch the results and messages from the Agent.