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
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
|
<HTML>
<TITLE>Portable Interceptors</TITLE>
<BODY>
<hr><P>
<H3>Portable Interceptors</H3>
<BODY text = "#000000"
link="#000fff"
vlink="#ff0f0f"
bgcolor="#ffffff">
<p>We have revised TAO's interceptor implementation so that it
conforms to the
<a href="ftp://ftp.omg.org/pub/docs/orbos/99-12-02.pdf">Portable
Interceptor</A> specification. The purpose of this document is to
provide a transition guide for those who have used our old
interceptors. The old interceptors will no longer be supported now
that we have the new mechanism in place. A paper that describes TAO's
portable interceptors and <A HREF="Smart_Proxies.html">smart
proxies</A> is available <A
HREF="http://www.cs.wustl.edu/~schmidt/PDF/smart_proxies.pdf">online</A>.</p>
<hr><P>
<h3><a name="toc">Table of Contents</a></h3>
<ul>
<li><a href="#context">Context</a>
<li><a href="#implement">TAO's Implementation</a>
<li><a href="#api">Transition</a>
<li><a href="#status">Current Status</a>
<li><a href="#future">Future Work</a>
<li><a href="#issues">Known Issues</a>
<li><a href="#ref">References</a>
</ul>
<hr><P>
<h2><a name="context">Context</a></h2>
<p>Interceptors allow you to interpose other CORBA services to the ORB
and extend the ORB's functionalities. They are most commonly used in,
but not limited to, Security Service, Transaction Service. They are
also for doing accounting and debugging distributed application.</p>
<p>Although both CORBA 2.2 and 2.3 define an interceptor interface,
the definitions are pretty much useless because it does not define how
the interceptor should interact with an ORB. Therefore, OMG is
currently trying to define a "<a
href="http://www.omg.org/techprocess/meetings/schedule/Portable_Interceptors_RFP.html">
Portable Interceptor</a>" specification which will remedy the problems
and allow application users to use interceptos from different venders
with their ORBs. </p>
<hr><P>
<h3><a name="implement">TAO's Implementation of "Portable
Interceptors"</a></h3>
<p>TAO's portable interceptor implementation was developped before
even a joint submission was available. There were several proposed
standards which defined very different interfaces and capabilities.
The old interceptor implementation provides a minimum subset of
functionalities proposed in the initial submissions. This approach
has allowed TAO users to explore various use cases of interceptors and
prevented users from adding code that depended on the interceptor
features which would not be supported when the spec gets
finalized.</p>
<p>We have modifed TAO's interceptor interface to conform with the
proposed spec. The current version of interceptors consists of support
for the <CODE>Dynamic</CODE> module as well as the canonical
interception points including (1) <CODE>send_request</CODE>,
(2) <CODE>receive_request</CODE>, (3) <CODE>send_reply</CODE>,
(4) <CODE>receive_reply</CODE>, (5) <CODE>send_exception</CODE>,
(6) <CODE>receive_exception</CODE>, and
(7) <CODE>establish_components</CODE> (specific to
<CODE>IORInterceptor</CODE>s. Each request interception point is
passed a <CODE>RequestInfo</CODE> object which encapsulates the
details of the operation like arguments, etc. The IOR interception
point is passed an <CODE>IORInfo</CODE> object that encapsulates
operations for adding tagged components to profiles in an IOR.
Registration of all three types of interceptors (client and server
request interceptors, and IOR interceptors) is now done using the
interface provided by the standard <CODE>ORBInitInfo</CODE>
object.</p>
<p>
Details of this implementation along with benchmarking is available in
the paper on <a
href="http://www.cs.wustl.edu/~schmidt/PDF/COOTS-00.pdf">Meta-programming
mechanisms.</a>
</p>
<p> Examples on this new version of Portable Interceptors is available
at <CODE>$TAO_ROOT/tests/Portable_Interceptors</CODE>.</p>
<hr><P>
<h3><a name="api">Transitting from TAO's Old "Portable"
Interceptor APIs to the Standard Portable Interceptor APIs</a></h3>
<p>Please refer to the working draft for details on the proposed
Portable Interceptor interfaces. Below is the old but now obsolete
interceptor version in TAO.</p>
<pre>
// -*- IDL -*- $Id$
// This file contains the interface definitions for "Portable"
// Interceptor support.
// **********************************************************
// Notice that the Portable Interceptor specification
// is still under discussion in OMG and both the IDL
// and the implementation details in TAO will eventually
// change to conform with the PI spec in the future.
//
// @@ Now that a working draft of the Portable Interceptors
// is available, we will provide a compliant implementation
// shortly.
//
// Please see the annotation marked with "@@" in this file
// for hints on transitting from the temporary
// implementation to new APIs.
//
// See $TAO_ROOT/docs/interceptors.html for more info.
// **********************************************************
// Author (currently): Nanbor Wang <nanbor@cs.wustl.edu>
// @@ I will no longer be the author of this IDL file. ;-)
#include <corba.pidl>
#include <IOP.pidl>
#pragma prefix "TAO"
// The prefix should be changed to "omg.org" once the spec. gets
// finallized.
// @@ The prefix will be changed to "omg.org".
module PortableInterceptor
{
interface Cookie
{
// Cookie's are used to pass information among interceptors
// within a invocation or an upcall.
//
// @@ Cookie will no longer be available.
string myname ();
};
typedef sequence<Cookie> Cookies;
// Collections of Cookie's become Cookies'es.
//
// @@ Cookies will no longer be available.
interface Interceptor
{
// Base interface for Interceptors.
//
// @@ This interface will not change.
readonly attribute string name;
};
interface ServerRequestInterceptor : Interceptor
{
// Server side request interceptor definition.
//
// @@ The name of the interface will not change.
void preinvoke (in unsigned long request_id,
in boolean response_expected,
in CORBA::Object objref,
in string operation_name,
inout IOP::ServiceContextList sc,
inout NVList arguments,
inout Cookies ck);
// Interception pointer before invoking the servant method.
// Currently, we don't pass NVList into the interceptor because
// I haven't figured out how to best optimize this stuff.
// In the future, NVList will contain all in and inout arguments
// of the operation.
//
// @@ This operation will map to either
// <receive_request_service_contexts> or <receive_request> of
// the standard APIs. If you are not sure, use
// <receive_request>.
//
// void receive_request_service_contexts (in ServerRequestInfo ri) raises (ForwardRequest);
// void receive_request (in ServerRequestInfo ri) raises (ForwardRequest);
//
// @@ Note that all arguments will be accessed thru
// <PortableInterceptor::ServerRequestInfo> interface.
void postinvoke (in unsigned long request_id,
in boolean response_expected,
in CORBA::Object objref,
in string operation_name,
inout IOP::ServiceContextList sc,
inout NVList arguments,
inout Cookies ck);
// Interception pointer after invoking the servant method.
// Currently, we don't pass NVList into the interceptor because
// I haven't figured out how to best optimize this stuff.
// In the future, NVList will contain all out, inout arguments
// and the return value of the operation.
//
// @@ This operation will map to <send_reply>.
// It is not clear whether oneway call will invoke <send_other>
// operation or not.
//
// void send_reply (in ServerRequestInfo ri);
// void send_other (in ServerRequestInfo ri) raises (ForwardRequest);
//
// @@ Note that all arguments will be accessed thru
// <PortableInterceptor::ServerRequestInfo> interface.
void exception_occurred (in unsigned long request_id,
in boolean response_expected,
in CORBA::Object objref,
in string operation_name,
inout Cookies ck);
// Exception interception point.
//
// @@ This method will map to <send_exception> method.
//
// void send_exception (in ServerRequestInfo ri) raises (ForwardRequest);
//
// @@ Note that all arguments will be accessed thru
// <PortableInterceptor::ServerRequestInfo> interface.
};
interface ClientRequestInterceptor : Interceptor
{
// Client side interceptor.
//
// @@ The name of the interface will not change.
void preinvoke (in unsigned long request_id,
in boolean response_expected,
in CORBA::Object objref,
in string operation_name,
inout IOP::ServiceContextList sc,
inout NVList arguments,
inout Cookies ck);
// Before remote invocation.
// Currently, we don't pass NVList into the interceptor because
// I haven't figured out how to best optimize this stuff.
// In the future, NVList will contain all in and inout arguments
// of the operation.
//
// @@ This operation will map to <send_request> of the standard
// APIs.
//
// void send_request (in ClientRequestInfo) raises (ForwardRequest);
//
// @@ Note that all arguments will be accessed thru
// <PortableInterceptor::ClientRequestInfo> interface.
void postinvoke (in unsigned long request_id,
in boolean response_expected,
in CORBA::Object objref,
in string operation_name,
inout IOP::ServiceContextList sc,
inout NVList arguments,
inout Cookies ck);
// After returned from remote invocation.
// Currently, we don't pass NVList into the interceptor because
// I haven't figured out how to best optimize this stuff.
// In the future, NVList will contain all out, inout arguments
// and the return value of the operation.
//
// @@ This operation will map to either <receive_reply> or
// <receive_other> in the standard APIs depending on whether the
// operation is oneway or not.
//
// void receive_reply (in ClientRequestInfo ri);
// void receive_other (in ClientRequestInfo ri);
//
// @@ Note that all arguments will be accessed thru
// <PortableInterceptor::ClientRequestInfo> interface.
void exception_occurred (in unsigned long request_id,
in boolean response_expected,
in CORBA::Object objref,
in string operation_name,
inout Cookies ck);
// Exception occurred.
//
// @@ This method will map to <receive_exception> method as:
//
// void receive_exception (in ClientRequestInfo ri) raises (ForwardRequest);
//
// @@ Note that all arguments will be accessed thru
// <PortableInterceptor::ClientRequestInfo> interface.
};
};
#pragma prefix ""
</pre>
<hr><P>
<h3><a name="status">Current Status</a></h3>
<ul>
<li>The basic infrastructure is in place as well as the canonical
interception points: <CODE>send_request</CODE>,
<CODE>receive_request</CODE>, <CODE>send_exception</CODE>,
<CODE>receive_exception</CODE>, <CODE>send_reply</CODE>, and
<CODE>receive_reply</CODE>. The other interception points are
mostly for specific applications like AMI, FT, etc. which will
be implemented as and when needed.
<li><CODE>ORBInitializer</CODE> registration has been implemented,
as per the spec.
<li>Registration of interceptors is now conformant to the spec
through the <CODE>ORBInitInfo</CODE> class. Multiple
interceptors may now be registered.
<li>IOR interceptors have been implemented. They allow an external
service, for example, to add tagged components to profiles
within IORs as they are being generated.
<li>Policy factory registration, i.e.
<CODE>ORBInitInfo::register_policy_factory</CODE>, has been
implemented. Corresponding policies can then be created using
the <CODE>ORB::create_policy</CODE> method.
<li>Initial reference registration, i.e.
<CODE>ORBInitInfo::register_initial_reference</CODE>, has been
implemented. This particularly useful for registering local
objects with the ORB's <CODE>resolve_initial_references</CODE>
since they can't be stringified and registered via -ORBInitRef.
<li>Basically, all <CODE>ORBInitInfo</CODE> methods have been
implemented except <CODE>allocate_slot_id</CODE> and
<CODE>codec_factory</CODE>.
</ul>
<hr><P>
<h2><a name="future">Future Work</a></h2>
<ol>
<li>Add support for the interceptor chain to <CODE>ThruPOA</CODE>
collocation optimization; the <CODE>direct</CODE> collocation
optimization will not go through the interceptor chain.
<li>Implement the <CODE>PortableInterceptor::Current</CODE>
interface. Useful for passing data between interceptors.
<li>Implement the <CODE>CodecFactory</CODE> interface, and an
accompanying CDR encapsulation <CODE>Codec</CODE>.
Implementations of each are almost ready and should be available
soon. The CDR encapsulation <CODE>Codec</CODE> is useful for
embedding data in an <CODE>octet</CODE> sequence that conforms
to the CDR encapsulation rules. For example, it could be used
to create the <CODE>octet</CODE> sequence that is part of an
<CODE>IOP::TaggedComponent</CODE>. This means that it could
compliment the IOR interceptor support.
</ol>
<hr><p>
<h3><a name="issues">Known Issues</a></h3>
<ul>
<li>The current implementation does not go through the interceptor chain
when using collocation optimizations such as <CODE>direct</CODE> or
<CODE>ThruPOA</CODE>.
<li>While multiple interceptors have been implemented, their
compliance with the <em>General Flow Rules</em> must be improved.
</ul>
<hr><P>
<H3><a name="ref">References</a></H3>
<UL>
<LI><p><a href="ftp://ftp.omg.org/pub/docs/orbos/99-12-02.pdf">
99-12-02</a> Portable Interceptors -- Joint Revised
Submission.</p>
<LI><p><a href="ftp://ftp.omg.org/pub/docs/orbos/99-12-14.zip">
99-12-14</a> Portable Interceptors related IDL files (in zip
format.) </p>
</UL>
<hr>
</BODY>
|
