TAO/docs/pluggable_messaging.html

   1 <!DOCTYPE HTML SYSTEM
   2 "http://www.w3.org/pub/WWW/MarkUp/Cougar/Cougar.dtd">
   3   <!-- -->
   4   <head>
   5     <title>Pluggable Messaging framework</title>
   6   </head>
   7
   8   <BODY text = "#000000"
   9     link="#0000ff"
  10     vlink="#cc0000"
  11     bgcolor="#ffffff">
  12
  13     <body>
  14       <HR>
  15             <h1>Pluggable Messaging Framework</h1>
  16   <HR>
  17     <h2>Context</h2>
  18           TAO uses GIOP message formats to exchange messages between
  19           inter-operating ORBs. GIOP, essentially specifies formats of
  20           messages exchanged between ORBs. It has only a few message
  21           types but still provides full CORBA support. But, there has
  22           been a trend to try out different message formats like <a
  23           HREF= "http://www.w3.org/TR/WD-HTTP-NG-architecture/">
  24           HTTP-NG </a> for inter-ORB communication. This framework
  25           tends to take a first step in the direction to support
  26           different protocols. The framework,though not complete in
  27           itself, has been used for implementing GIOP and
  28           GIOPlite. The framework would be re-factored and reworked
  29           depending on the use cases our users come across.
  30
  31     <h2>Idea</h2>
  32           We wanted to give a flexibility to the user to load the message
  33           formatting protocol by selecting a protocol during the
  34           bootstrapping process. So, we tried to leverage the work
  35           that has already been done for the <a HREF =
  36           "pluggable_protocols/index.html"> pluggable_protocols</a>.
  37
  38           The fundamental idea that we followed was to isolate all of
  39           the ORB code from the message formatting details. The
  40           framework is constrained by the type of marshalling
  41           scheme. The framework now completely relies on CDR
  42           formatted streams.
  43
  44
  45           <h2>Implementation of GIOP</h2>
  46
  47           <P>The common interface that has  been defined is the class
  48           Pluggable_Messaging_Interface forms the core class for the
  49           implementation of a concrete messaging protocol. We have
  50           been able to implement the GIOP & GIOPlite successfully using
  51           this minimal interface. The different versions of GIOP have
  52           been managed successfully within this implementation.</P>
  53
  54           <P>When the user loads protocols like IIOP he/she in turn is
  55           loading the TCP/IP mapping of GIOP formatted message. The
  56           same argument can be used for UIOP, SHMIOP too. So, using
  57           this fundamental understanding, we load the GIOP protocol for
  58           the user behind the scene. If an user wants to use GIOPlite
  59           mapped on to TCP/IP he would load IIOP_Lite using the
  60           svc.conf file. The format is given below </P>
  61
  62           <P><code>dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""</code></P>
  63           <P><code>static Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory". </code></P>
  64
  65           <P>At the moment the TAO Strategies library is used the
  66           svc.conf file should contain: </P>
  67
  68           <P><code>dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""</code></P>
  69           <P><code>static Advanced_Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory". </code></P>
  70
  71           <P>Please see the documentation of the pluggable protocol
  72           framework for exact meaning of the above syntax. The same
  73           applies to GIOPlite mapping on UIOP too.</P>
  74
  75           <P>The class GIOP_Message_Base derives from the
  76           Pluggable_Messaging_Interface. This class holds most of the
  77           common code needed for the GIOP classes. GIOP places a
  78           restriction on the client and server roles, in terms of
  79           initiating and receiving messages. This concept has been
  80           mapped on to the framework by two sets implementation
  81           classes, namely GIOP_Message_Connectors and
  82           GIOP_Message_Acceptors. </P>
  83
  84           <P>The GIOP_Message_Connector and the derived classes
  85           implements the different types of messages that can
  86           originate from the client. In GIOP 1.2, with the
  87           specification of Bi-Directional GIOP, this distinction
  88           between the client and server would decrease. But, this
  89           would be applicable only for GIOP 1.2. The present
  90           inheritance model, allows us to implement some of the roles
  91           defined for the server in the 1.0 and 1.1 versions of GIOP, on
  92           the client side. This needs to be done only for 1.2.</P>
  93
  94           <P>The GIOP_Message_Acceptor class is a Context, which maintains
  95           a reference to a strategy based on the incoming request.</P>
  96
  97           <P>The GIOP specification specifies that if a server supports
  98           GIOP-1.2, it should also offer support for GIOP-1.1 and
  99           GIOP-1.0. This would mean that clients that can communicate
 100           in any of the three protocols can connect to a server that
 101           supports 1.2. The server should also reply based on the same
 102           revision.</P>
 103
 104           <P> The strategisation on the server side is based on the
 105           different version numbers of GIOP. The reference that would
 106           be maintained by the context, GIOP_Message_Acceptor, would
 107           be based on the version number of the incoming request. The
 108           reply is also sent using the same reference. This makes it
 109           possible to send compatible replies to the client. </P>
 110
 111           <h2>Limitations</h2>
 112           <P> Uses only CDR formats. </P>
 113           <P> Need more ise cases to make the interface more flexible
 114           and better. </P>
 115
 116
 117     <HR>
 118       For more details and questions,
 119       <p>
 120
 121         <address><a href="mailto:bala@cs.wustl.edu">Balachandran
 122         Natarajan</a></address>
 123         <p>
 124     <address><a href="mailto:fredk@cs.wustl.edu">Fred Kuhns</a></address>
 125     </body>
 126 </html>
 127
 128 </title>
 129 </head>
 130
 131 <body>
 132 <h1></h1>
 133
 134 <hr>
 135 <address></address>
 136 </body> </html>