Document Number ptc/2001-10-24




Final RTF Report
of the
Portable Interceptors
Revision
Task Force
to the
Platform Technical Committee
of the
Object Management Group
October 22, 2001
Document Numbers:
ptc/2001-10-25 (CORBA 2.5 Chapter 21 with RTF revisions)




Contents




Summary of PI RTF Activities


PI RTF Formation


PI RTF Membership and Voting Record

The columns titled V1 through V2 represent Votes 1 through 2. The symbols in the columns carry the following meaning: Member Organization Status V1 V2
Ioana Pirvulescu Borland charter V V
Jonathan Biggar Floorboard Software charter V V
Jishnu Mukerji Hewlett-Packard charter V V
Tim Baldwin IBM charter V V
Matthew Newhook Iona charter V NV
Bill Beckwith OIS charter V V
Harold Carr Sun Microsystems charter V V
Polar Humenn Syracuse University charter V V


Disposition of Issues

Disposition Number of Occurrences Meaning of Disposition
Unresolved/Deferred 17 RTF did not address a resolution
Transferred 0 Transferred to another TF
Accepted (Changed and Closed) 5 Change made as requested
Rejected (Close, No Change) 7 RTF / RTF agreed NOT to do what was requested, or anything like it
Duplicate 2 Duplicate to another issue

Unresolved/Deferred

Issue 3322: Portable Interceptors: object_to_string, string_to_object
Issue 3403: PI needs the ORB to be available in IDL
Issue 3429: ORBInitInfo needs the ORB
Issue 3599: Detail lacking in when request interceptors are called
Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments'
Issue 3609: Overriding POA policies
Issue 3615: Policy Management in Portable Interceptors
Issue 3672: Portable Interceptors / register_initial_reference()
Issue 3793: no way to register value factory from ORB initializer
Issue 3947: Portable interceptors and invocation timeouts
Issue 3989: No portable way to turn IOR components into object-reference policies
Issue 4065: How does an ORB implement Object::get_policy for PI defined policies?
Issue 4169: Avoiding RSC/TSC copy on server side
Issue 4173: Clarify that each interception point executes in a distinct logical thread
Issue 4284: 21.8.1 register_initial_reference
Issue 4554: Detecting Recursion in Other Interceptors
Issue 4585: CORBA 2.5 and Portable Interceptors mismerged

Transferred

None.

Accepted

Issue 3790: exceptions in pre_init & post_init - 7Y,0N,0A,1NV
Issue 3791: pre_init & post_init synchronization - 7Y,0N,0A,1NV
Issue 3935: IOP_N - 8Y,0N,0A,0NV
Issue 4168: LocateRequest - 7Y,0N,0A,1NV
Issue 4494: ORBInitInfo.resolve_initial_references() should return Object - 8Y,0N,0A,0NV

Rejected

Issue 3677: Interceptors must provide user-level request ID - 8Y,0N,0A,0NV
Issue 3678: Interceptors must provide a retry mechanism - 8Y,0N,0A,0NV
Issue 3679: PI must provide a means for security interceptors to clean up - 8Y,0N,0A,0NV
Issue 3693: PI: Bi-endianness of Codec Factory - 7Y,0N,0A,1NV
Issue 3766: Security needs access to servant and POA - 7Y,0N,0A,1NV
Issue 3981: table 4-1, page 63 has a mistake in its list for TRANSIENT minor codes - 7Y,0N,0A,1NV
Issue 4139: GIOP 1.2 Fragmentation and Interceptors - 7Y,0N,0A,1NV

Duplicate

Issue 4174: Do the client & server side interceptors see LocateRequest messages? (dup of 4168)
Issue 4291: Interceptors and the Java "Local Optimized" stubs (dup of 3754)

Profile of Changes Made in Response to Issues


Recommendation for Remaining Issues

No one except the chairperson wrote resolutions in this RTF. Therefore, to ensure participation, it is recommende that the remaining and new Portable Interceptor issues be moved the Core RTF.




Detailed Resolution of Issues


Issue 3677: Interceptors must provide user-level request ID

Click here for this issue's archive.
Source: International Business Machines (Mr. Russel Butek, rbutek@tivoli.com)
Nature: Uncategorized Issue
Severity:
Summary:

This interceptor requirement comes from the work in CSIv2. Interceptors are only concerned with transport-level requests, whereas security needs to carry information around based on the user-level request which, given retries, could span multiple transport-level requests. To support this requirement, they need an ID for the user-level request. They would be happy if we simply added the following to ClientRequestInfo: readonly attribute unsigned long user_request_id;

Resolution:  Close issue with no change.

This is no longer a CSIv2 requirement.

Revised Text:

Actions taken:  Close issue, no change.
June 18, 2000: received issue


Issue 3678: Interceptors must provide a retry mechanism

Click here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, rbutek@tivoli.com)
Nature: Uncategorized Issue
Severity:
Summary:

This interceptor requirement comes from the work in CSIv2. Interceptors are only concerned with transport-level requests, whereas security needs to carry information around based on the user-level request which, given retries, could span multiple transport-level requests. To support this requirement, they need a retry mechanism. The interceptors already have a mechanism that could be used to implement retries - the LocateRequest exception. But is this appropriate? Should some other mechanism be create to distinguish retries on the same IOR from forwards to different IORs? If the retries are done often, then something other than exception should be used. Perhaps we could supply a retry method. This method would indicate to the ORB that successive interceptors' receive_other interception points should be called and that, once this transport-level request is complete, a new request should be initiated with the same user-level parameters.

Resolution:  Close issue with no change.

This is no longer a CSIv2 requirement.

Revised Text:

Actions taken:  Close issue, no change.
June18, 2000: received issue


Issue 3679: PI must provide a means for security interceptors to clean up

Click here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, rbutek@tivoli.com)
Nature: Uncategorized Issue
Severity:
Summary:

This interceptor requirement comes from the work in CSIv2. Interceptors are only concerned with transport-level requests, whereas security needs to carry information around based on the user-level request which, given retries, could span multiple transport-level requests. Security could use a user_request_id (discussed in another issue) to index into their private 'cookie jar' to transfer data that resides on a user-level request from one transport-level request to the next. However, this data needs to be cleaned up. If a security interceptor indicates that a retry should occur (and stores the appropriate data), it does not know whether that retry actually does occur. A successive interceptor may raise an exception, for example. What security could use is a new interception point: request_done. This interception point deviates from the existing client-side interception points in that it is relative to the user-level request, not the transport-level request like the existing interception points. Therefore it would be reasonable to place this interception point in its own interface that implementors could mix in to their implementation if they need it. For example: local interface UserRequestInterceptor : Interceptor { void request_done (); }; This interception point is not allowed to raise exceptions. If it raises System Exceptions, the ORB must ignore them.

Resolution:  Close issue with no change

This is no longer a CSIv2 requirement.

Revised Text:

Actions taken:  Close issue, no change.
June 18, 2000: received issue


Issue 3693: PI: Bi-endianness of Codec Factory

Click here for this issue's archive.
Source: Humboldt-Universitaet (Mr. Harald Boehme, boehme@informatik.hu-berlin.de)
Nature: Uncategorized Issue
Severity:
Summary:

For better usability of the coding and symmetry of encoding and decoding it is nessesary to extend the information for the Codec selection. The byte order should be selectable in the request for a Codec. Rationale: To allow generation of identical encoding values for the same parameters, it must be possible to select the endianness. Proposed Resolution: Extend "struct Encoding" in section 13.7 of ptc/00-03-03 with an additional field "boolean byte_order".

Resolution:  Close issue with no change.

This needs a reasonable use case. That was requested but not given. Please see the issue's archive.

Revised Text:

Actions taken:  Close issue, no change.
June 9, 2000: received issue


Issue 3766: Security needs access to servant and POA

Click here for this issue's archive.
Source: Syracuse University (Mr. Polar Humenn, polar@adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

Here are the scenarios needed for interceptor to have access to the servant. 1. We want to provide security to "security unaware" applications. 2. We also want to provide security based on "security aware" applications. (You'll see what I mean later). We need to derive information from a particular object about the security attributes of that object WITHOUT regard to the lifetime or persistence of the object. (IMHO, the security specification made this extreme blunder with the RequiredRights object, I don't want that to happen again) We could use several things about a servant in an interceptor: security attributes "about the servant" owner attributes "about the owner of the servant" (new concept) domain name "domain of the servant" (domain management). Now, the easy thing would say, Set up a domain name and owner data base and just associate it with an object. However, in a generic sense, there isn't an object. If the object is persistent, what happens to this data when the object goes to sleep? What happens if the object is destroyed? Consitency problems all over the place. What we need to do is "derive" the needed information, in a generic sense, from the implementation of a servant. It might be that you have a POA, or a series of POAs, that create references to bank account objects. Depending on the security policy implemented we need to classify the servants (the objects the servant is implementing) into groups. That is, return different owner or domain names derived from information available to the servant. It works very cleanly this way, since all security relevant data is the responsibility of the servant, that is if its transient transient or even in persistent cases, we don't care. We need not make any requirements about persistent or transient servants. The current approach we want to take (for the POA case anyway) is to have a POA policy associated with the creation of a POA or an interceptor. This POA policy has intimate knowledge of the implementations of the servant. Let me illustrate by finding a domain name for a particular servant. We have a policy that has intimate knowledge of the groups of servants underneath it (possibly a POA). interface DomainNamePOAPolicy : CORBA::Policy { DomainNameList get_domain_names( in PortableServer::Servant serv ) raises ( IllegalServant ); }; As a security interceptor, we might like to do the following: RequestInfo ri; // from Interceptor POARequestInfo pri = POARequestInfo.narrow(ri); // for use with a POA POA poa = pri.the_poa(); // POArequestInfo specific attributes Servant serv = pri.the_servant(); // Get the Domain Name finding policy object DomainNamePOAPolicy dnp = DomainNamePOAPolicy.narrow( ri.get_server_policy(DomainNamePOAPolicyType)); DomainName[] dname = dnp.get_domain_name(serv); .. do access control based on domain names Fear and Loathing in ORB land: (I fear the call to get_domain_names() might be orb mediated, and subjected to interception?) Anyway, please excuse the concrete implementation below, but it is just an illustration. Say we want the DomainNamePOAPolicy to base the domain name on some significant part of the servant. Such as grouping all the bank accounts by the salesman under which the bank account is in his jurisdiction. (This IS what policy is all about, of course). class DomainNamePOAPolicy extends _DomainNamePOAPolicyImplBase { DomainName[] get_domain_names(org.omg.PortableServer.Servant serv) { if (serv instanceof BankAccount) { BankAccount ba = (BankAccount) serv; String salesman = ba.salesman(); DomainName[] names = new DomainName[1]; names[0] = convert_salesman_to_domain(salesman); return names; } throw new IllegalServant(); } } We want to derive security information from the attributes in the implementation of the servant, and not store security information about a particular object the servants represent in separate places. The latter approach causes all kinds of consitentcy and lifecycle issues for transient and persistent matters. Using the policy approach as I have outlined solves most of those issues and it is simply mandated that the policy implemented must have intimate knowledge of the servant implementation. We don't care much about the implementation, just the interface of it. This situation is okay, because a security implementer would supply the correct policies to the POA or that would provide the correct information to a security interceptor (i.e. one that had to know about domains) without affecting the implementation of the servant. It's all "plug-and-play". Does this reasoning suffice for the need to gain direct access to the servant?

Resolution:  Close issue with no change.


Revised Text:

Actions taken:  Close issue, no change.
March 24, 2000: received issue


Issue 3790: exceptions in pre_init & post_init

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

Are exceptions permitted from pre_init() and post_init() calls? I seem to remember that we discussed making this illegal -- however, I don't notice any verbage in the spec. The problem is if it's illegal to raise exceptions in pre_init and post_init there is no sensible way for an ORB service to indicate to the application that initialization failed. The best that can be done is to call exit() or log an error message.

Resolution:  Incorporate change and close issue.

Note: the Java mapping section states that exceptions are ignored. This change just moves that statement into a more general location so it applies to all mappings.

Revised Text:

In ptc/01-03-04:

change the the last two sentences of the second paragraph of 21.7.3 from:


This instantiating ORB_init call calls each registered
ORBInitializer.  The returned ORB will contain any Interceptors that
the given service requires.
to


This instantiating ORB_init call calls pre_init and post_init on each
registered ORBInitializer.  If any of the ORBInitializer pre_init or
post_init operations raise an exception, the ORB shall ignore them and
proceed. The returned ORB will contain any Interceptors that the given
service requires.
and remove:


If there are any exceptions, the ORB shall ignore them and proceed.
from Java/New Property Set paragraph in section 21.7.3
Actions taken:  Incorporate change and close issue.
August 25, 2000: received issue


Issue 3791: pre_init & post_init synchronization

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

Are there any synchronization guarantees of pre_init and post_init calls? It would be useful for many applications if the implementation of the ORBInitializer can hold state between pre_init & post_init
calls -- but currently this isn't easily possible because there are no synchronization guarantees on the interface hence concurrent calls to pre_init and post_init can occur. I'd actually like a fairly strong guarantee such that calls to both pre_init and post_init are guaranteed to be atomic. That is something like the following (I don't know how to say this sensibly in English ;) global_mutex.lock(); initializer -> pre_init() initializer -> post_init() global_mutex.unlock();

Resolution:  Incorporate change and close issue.

Note that the additional text is written to allow an ORB implementation to run pre_init operations in parallel followed by post_init operations in parallel. It just states that you cannot start executing post_init until all pre_init calls have completed.

Revised Text:

In ptc/01-03-04:

Add the following paragraph to section 21.7.3, just before section 21.7.3.1:

. 

When ORBInitializers are executed from within the ORB_init call the
pre_init operation on all registered ORBInitializers shall complete
before executing the post_init operation on all registered
ORBInitializers.
Actions taken:  Incorporate change and close issue.
August 25, 2000: received issue


Issue 3935: IOP_N

Click here for this issue's archive.
Source: Sun Microsystems (Dr. Harold Carr, Ph.D., harold.carr@sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

All pages of ptc/00-08-06 reference Codec and CodecFactory as being in module IOP - EXCEPT section 21.10 (the consolidated IDL). There is says IOP_N. At one time IOP_N was a placeholder until the exact version of module IOP was determined. Was a determination made that IOP was the proper module/version?

Resolution:  Incorporate change and close issue.


Revised Text: Replace IOP_N with IOP in ptc/01-03-04 section 21.10.

Actions taken:  Incorporate change and close issue.
October 4, 2000: received issue


Issue 3981: table 4-1, page 63 has a mistake in its list for TRANSIENT minor codes

Click here for this issue's archive.
Source: Sun Microsystems (Dr. Harold Carr, Ph.D., harold.carr@sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

ptc/00-08-06 table 4-1, page 63 has a mistake in its list for TRANSIENT minor codes. It lists the number 2 for both "No usable profile in IOR" and "Request cancelled". The value for Request cancelled should be 3 (see same doc section 21.3.7.2 page 211 second paragraph ). Also, "Request cancelled" is misspelled.

Resolution:  Close issue with no change.

Note, ptc/01-03-04, which was the basis for CORBA 2.5, does not contain this error. It was fixed editorially. Therefore no further change is necessary.

Revised Text:

Actions taken:  Close issue, no change.
October 23, 2000: received issue
October 24, 2000: moved to Interceptors RTF


Issue 4139: GIOP 1.2 Fragmentation and Interceptors

Click here for this issue's archive.
Source: International Business Machines (Mr. Tim Baldwin, tim_baldwin@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

We have been looking at sending fragmented request and reply messages and fragmented replies in particular seem to have some interaction with the interceptors. There would seem to be several performance and/or space benefits in being able to send each fragment of a message as it is created rather than having to build the complete message and chopping it up only as it is sent across the wire. However the send_reply/send_exception interceptor seems to prevent this. Since the interceptor is able to alter service contexts (which appear right at the start of a message) and since we cannot drive the send_reply/send_exception interceptor until the entire reply message has been marsalled (as only then can we know for sure whether we have an exception or not) this seems to rule out sending any fragments until the entire reply has been built.

Resolution:  Close issue with no change.

Several ORB vendors have implemented PI and GIOP 1.2 fragmentation successfully without having the problem noted in this issue.

Revised Text:

Actions taken:  Close issue, no change.
January 8, 2001: received issue


Issue 4168: LocateRequest

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

Do the client & server side interceptors see LocateRequest messages? I think they should not. The reason why this is an interesting issue is that although I think that the client & server side interceptors should not see locate request messages, servant managers do see them. (although I'm not sure if this is spelled out in the spec -- another issue?). That means that there are requests which user-code sees which interceptors do not.

Resolution:  Incorporate change and close issue.


Revised Text:

In ptc/01-03-04:

In Section 21.3.7.2 after the last paragraph of that section add:


ClientRequestInterceptor points are not executed when a GIOP
LocateRequest is sent nor when a GIOP LocateReply message is
received.
In Section 21.3.10.2 after the paragraph that reads:

"Asynchronous requests, from the server's point of view, are just normal synchronous requests. Normal interception point flows are followed."

before the paragraph that starts:

"If a POA and a servant locator are present,..."

add:


ServerRequestInterceptor points are not executed when a GIOP
LocateRequest is received nor when a GIOP LocateReply message is
sent.
Actions taken:  Incorporate change and close issue.
January 22, 2001: received issue
January 22, 2001: moved from core to the Interceptor RTF


Issue 4174: Do the client & server side interceptors see LocateRequest messages?

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, matthew.newhook@iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

I think they should not. Any other opinions? I sent this message to early: The reason why this is an interesting issue is that although I think that the client & server side interceptors should not see locate request messages, servant managers do see them. (although I'm not sure if this is spelled out in the spec -- another issue?). That means that there are requests which user-code sees which interceptors do not.

Resolution:  Close issue, no change.

Note: this is a duplicate of Issue 4168:

Revised Text:

Actions taken:  Close issue, no change.
January 22, 2001: received issue


Issue 4291: Interceptors and the Java "Local Optimized" stubs

Click here for this issue's archive.
Source: International Business Machines (Mr. Tim Baldwin, tim_baldwin@uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

What should happen with Interceptors when Java stubs take the "local optimized" path? This can happen when the client and server both share the same ORB and, if so, the client can make a direct method call to a servant object. The stubs contain code like this: public int ExampleMethod(int i) { if ( !this._is_local() ) { ... // Non-local case ... else { org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("ExampleMethod",_opsClass); if (so == null) ... // Non-local after all ... try { ((ExampleOperations)_so.servant).ExampleMethod(i); return; } finally ( _servant_postinvoke(_so); } } } Should interceptors be driven when this local route is taken? It is an ORB-mediated invocation so the answer ought to be yes, but I'm not sure it really makes a lot of sense. Since client and servant are running in the same thread interceptors would not be needed to transfer thread-context around. And since there is no actual GIOP request/repsonse flow, there is no request_id or service_contexts or many of the other things interceptors normally deal with. This could all be simulated but then the "local optimized" path would become a lot less optimized, and where should the interception points be driven? The _servant_preinvoke() would probably drive send_request, receive_request_service_contexts and receive_request, but the return set (send_reply/send_exception and receive_reply/receive_exception) look harder; _preinvoke is too early and _postinvoke is really too late. Of course a simple solution from an implementation point of view is just to make the _is_local() test always return false if we have request interceptors registered. But this seems to be avoiding the issue.

Resolution:  Close issue no change.

This is a duplicate of java2idl-rtf issue 3754 .


Revised Text:

Actions taken:  Close issue, no change.
May 1, 2001: received issue


Issue 4494: ORBInitInfo.resolve_initial_references() should return Object

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Currently, ORBInitInfo.resolve_initial_references() returns void. This is incorrect. Since its semantics is meant to be same as orb->resolve_initial_references(), it should return Object instead.

Resolution:  Incorporate change and close issue.


Revised Text: In ptc/01-03-04, Section 21.7.2, and 21.10:
Change: 


void resolve_initial_references(in ObjecId id) raises (InvalidName);
to 


Object resolve_initial_references(in ObjecId id) raises (InvalidName);
Actions taken:  Incorporate change and close issue.
August 14, 2001: received issue