Java Structure of DatabaseServer
Java Structure of DatabaseServer
DatabaseServer is the main class. It initializes the ORB and registers the DatabaseServant. It also offers useful methods to the rest of classes.
DatabaseServer is an abstract class. Subclasses have to implement the method that creates the DatabaseSessionServant (DatabaseServer::makeDatabaseSessionServant), because different servers support different kind of sessions (and different DatabaseSession servants then).
It contains an inner private class (DatabaseServant) that implements HxCorba.DatabaseOperations. It has just the openSession method, that returns a DatabaseSession object, created through the abstract method DatabaseServer::makeDatabaseSessionServant .
DatabaseSessionServant is the base class for session servants. It implements HxCorba.UpdateSessionOperations.
It's an abstract class. Subclasses have to redefine the method that connects to the Database through JDBC (DatabaseSessionServant::makeConnection).
DatabaseSessionServant can also be subclassed to implement a different kind of database session (OracleServer subclasses DatabaseSessionServant to implement a FullSession) or to implement the UpdateSession operations in a different way (like MySQLServer does).
Usually servants for a Aaa CORBA Object are implemented as classes that extend the corresponding AaaPOA class (generated by the compiler), but all the servants described above implement AaaOperations instead. Why?
This is that way to be able to implement a servant for a Bbb CORBA Object (where the interface Bbb inherits from the interface Aaa) extending the servant for Aaa (because we don't want to implement again the operations of Aaa in the servant for Bbb).
AaaServant class extends AaaPOA class, but BbbServant class can not be implemented extending both AaaServant and BbbPOA, because Java classes can only extend one class. The solution is implementing BbbServant as a class that extends AaaServant and implements BbbOperations. This BbbServant class is not yet a servant for Bbb, because BbbPOA is not in its inheritance tree. But it can be used to instantiate a BbbPOATie class, and then we have finally a servant for Bbb.
Using Tie classes to implement extensible servants
To be consistent, AaaServant could be implement AaaOperations instead of extending AaaPOA, and be used with a AaaPOATie. Then all servants are implemented the same way.
From a client point of view, the server contains a different CORBA object for each "entity" (or "entry") of the database: an object for each segmentation, an object for each segment, etc...
But the server can not keep a servant for each "entry" of the database: it would be quite expensive.
The solution is to use a single servant for all "entities" of the same type. These servants are called Default servants. We will have a default servant for segmentations (VxSegmentationServant), a default servant for segments (VxSegmentServant) and so on.
The default servant implements the functionality of multiple objects (all of the same type). These objects have different "state" (the "state" of the object is what we store about it in the database), and the result of the operations of the objects depend on their states. Then, the default servant needs to know which object is calling the client. This is done through the ObjectId.
Each CORBA Object of a server has a different ObjectId. Although objects exist in the server only in a "logical" point of view, not "physically" (because there is no a servant for each object) they still do have an ObjectId. And our servers will choose an ObjectId that will help in accessing the "state" of the objects: ObjectIds will usually be the primary keys of the tables storing the objects.
When a default servant receives a request, it will obtain the ObjectId of the object that is being called, access the "state" of the object through this ObjectId and process the request based on this "state".
Next we will see how OracleServer and MySQLServer have been built using all these classes.
1.2.12 written by Dimitri van Heesch,
© 1997-2001