The common interface that has been defined is the class Pluggable_Messaging_Interface forms the core class for the implementation of a concrete messaging protocol. We have been able to implement the GIOP & GIOPlite succesfully using this minimal interface. The different versions of GIOP have been managed succesfully within this implementation.
When the user loads protocols like IIOP he/she in turn is loading the TCP/IP mapping of GIOP formatted message. The same argument can be used for UIOP, SHMIOP too. So, using this fundamental understanding, we load the GIOP protocol for the user behind the scene. If an user wants to use GIOPlite mapped on to TCP/IP he would load IIOP_Lite using the svc.conf file. The format is given below
dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""
static Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory".
At the moment the TAO Strategies library is used the svc.conf file should contain:
dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""
static Advanced_Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory".
Please see the documentation of the pluggable protocol framework for exact meaning of the above syntax. The same applies to GIOPlite mapping on UIOP too.
The class GIOP_Message_Base derives from the Pluggable_Messaging_Interface. This class holds most of the common code needed for the GIOP classes. GIOP places a restriction on the client and server roles, in terms of initiating and receiving messages. This concept has been mapped on to the framework by two sets implementation classes, namely GIOP_Message_Connectors and GIOP_Message_Acceptors.
The GIOP_Message_Connector and the derived classes implements the different types of messages that can originate from the client. In GIOP 1.2, with the specification of Bi-Directional GIOP, this disticntion between the client and server would decrease. But, this would be applicable only for GIOP 1.2. The present inheritance model, allows us to implement some of the roles defined for the server in the 1.0 and 1.1 versions of GIOP, on the client side. This needs to be done only for 1.2.
The GIOP_Message_Acceptor class is a Context, which maintains a reference to a strategy based on the incoming request.
The GIOP specification specifies that if a server supports GIOP-1.2, it should also offer support for GIOP-1.1 and GIOP-1.0. This would mean that clients that can communicate in any of the three protocols can connect to a server that supports 1.2. The server should also reply based on the same revision.
The strategisation on the server side is based on the different version numbers of GIOP. The reference that would be maintained by the context, GIOP_Message_Acceptor, would be based on the version number of the incoming request. The reply is also sent using the same reference. This makes it possible to send compatible replies to the client.
Uses only CDR formats.
Need more ise cases to make the interface more flexible and better.
Balachandran Natarajan
Fred Kuhns