1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
<!DOCTYPE HTML SYSTEM
"http://www.w3.org/pub/WWW/MarkUp/Cougar/Cougar.dtd">
<!-- $Id$-->
<head>
<title>Pluggable Messaging framework</title>
</head>
<BODY text = "#000000"
link="#0000ff"
vlink="#cc0000"
bgcolor="#ffffff">
<body>
<HR>
<h1>Pluggable Messaging Framework</h1>
<HR>
<h2>Context</h2>
TAO uses GIOP message formats to exchange messages between
inter-operating ORBs. GIOP, essentially specifies formats of
messages exchanged between ORBs. It has only a few message
types but still provides full CORBA support. But, there has
been a trend to try out different message formats like <a
HREF= "http://www.w3.org/TR/WD-HTTP-NG-architecture/">
HTTP-NG </a> for inter-ORB communication. This framework
tends to take a first step in the direction to support
different protocols. The framework,though not complete in
itself, has been used for implementing GIOP and
GIOPlite. The framework would be re-factored and reworked
depending on the use cases our users come across.
<h2>Idea</h2>
We wanted to give a flexibility to the user to load the message
formatting protocol by selecting a protocol during the
bootstrapping process. So, we tried to leverage the work
that has already been done for the <a HREF =
"pluggable_protocols/index.html"> pluggable_protocols</a>.
The fundamental idea that we followed was to isolate all of
the ORB code from the message formatting details. The
framework is constrained by the type of marshalling
scheme. The framework now completely relies on CDR
formatted streams.
<h2>Implementation of GIOP</h2>
<P>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.</P>
<P>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 </P>
<P><code>dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""</code></P>
<P><code>static Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory". </code></P>
<P>At the moment the TAO Strategies library is used the
svc.conf file should contain: </P>
<P><code>dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""</code></P>
<P><code>static Advanced_Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory". </code></P>
<P>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.</P>
<P>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. </P>
<P>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.</P>
<P>The GIOP_Message_Acceptor class is a Context, which maintains
a reference to a strategy based on the incoming request.</P>
<P>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.</P>
<P> 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. </P>
<h2>Limitations</h2>
<P> Uses only CDR formats. </P>
<P> Need more ise cases to make the interface more flexible
and better. </P>
<HR>
For more details and questions,
<p>
<address><a href="mailto:bala@cs.wustl.edu">Balachandran
Natarajan</a></address>
<p>
<address><a href="mailto:fredk@cs.wustl.edu">Fred Kuhns</a></address>
</body>
</html>
</title>
</head>
<body>
<h1></h1>
<hr>
<address></address>
<!-- hhmts start -->
Last modified: Thu Mar 16 11:23:03 CST 2000
<!-- hhmts end -->
</body> </html>
|
