From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA20820; Sun, 18 Jun 2000 15:43:36 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id PAA65236; Sun, 18 Jun 2000 15:53:24 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256902.006D3DD3 ; Sun, 18 Jun 2000 15:53:12 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, issues@omg.org cc: csi_submitters@concept5.com Message-ID: <85256902.006D3BCE.00@d54mta02.raleigh.ibm.com> Date: Sun, 18 Jun 2000 21:40:03 +0100 Subject: Portable Interceptors must provide a means for security interceptors to clean up Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: @\Ce9f%I!!OFW!!!,+e9 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. (Just a side comment. If we do take this approach, would it make more sense to have both a request_start and a request_done interception point? It would certainly be more balanced. Security doesn't require a user-level request initialization step in its design, but perhaps other services might?) Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: , , Cc: Subject: RE: Portable Interceptors must provide a means for security interceptors to clean up Date: Tue, 20 Jun 2000 09:04:20 +0100 Message-ID: <005901bfda8e$239dab50$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <85256902.006D3BCE.00@d54mta02.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: I")e95X%!!`-)!!n')!! Russell, > (Just a side comment. If we do take this approach, would it make more > sense to have both a request_start and a request_done interception point? > It would certainly be more balanced. Security doesn't require a user-level > request initialization step in its design, but perhaps other services > might?) > > Russell Butek > butek@us.ibm.com > Yes, I think the symmetric request_start() point makes sense. I suspect its presence would help CSIv2 implementers too - it provides a distinguished place to create their per-invocation data that otherwise would need a "have I seen this user-level request id before?" test in the send_request method. They might just have been too polite to ask for anything beyond the bare minimum! Regards Nick Date: Fri, 21 Jul 2000 17:00:36 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: interceptors-ftf@omg.org CC: ots-rtf@omg.org Subject: Issue 3677, 3679: these are needed by OTS Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f~'!!["0e9,!E!!8:U!! Hi, OTS implementations need to know when an invocation starts and ends. There is no way to tell definitely the end of a request in the current PI spec. However, the proposed solution for issues 3677, 3679 meet these needs. Ram Date: Fri, 21 Jul 2000 22:48:41 -0230 From: Matthew Newhook To: Ram Jeyaraman Cc: interceptors-ftf@omg.org, ots-rtf@omg.org Subject: Re: Issue 3677, 3679: these are needed by OTS Message-ID: <20000721224841.A10278@ooc.com> References: <3978E424.B3743FB1@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3978E424.B3743FB1@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: mlPe9->5!!$^$!!CbT!! Hi, On Fri, Jul 21, 2000 at 05:00:36PM -0700, Ram Jeyaraman wrote: > Hi, > > OTS implementations need to know when an invocation starts and ends. > There is no way to tell definitely the end of a request in the current > PI spec. > > However, the proposed solution for issues 3677, 3679 meet these needs. In what way does the current spec not meet OTS requirements? How do the current interceptors not know when an invocation begins and ends? How is your requirement different from what the current spec offers. Why do you need to know this? What in particular does OTS need to know, and why? > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Mon, 24 Jul 2000 13:11:57 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , interceptors-ftf@omg.org, ots-rtf@omg.org Subject: Re: Issue 3677, 3679: these are needed by OTS References: <3978E424.B3743FB1@eng.sun.com> <20000721224841.A10278@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ("]!!]]Oe9olL!!ANc!! Mathew, That was a premature question. Please disregard. I initially thought that the OTS interceptor need not be called for location forwarded retries. But it looks like it is necessary, particularly with GIOP 1.2 fragmentation (since the service context for the first request will not be available in memory for the second request, and thus the OTS interceptor has to be called again). thanks Ram Matthew Newhook wrote: > > Hi, > > On Fri, Jul 21, 2000 at 05:00:36PM -0700, Ram Jeyaraman wrote: > > Hi, > > > > OTS implementations need to know when an invocation starts and ends. > > There is no way to tell definitely the end of a request in the current > > PI spec. > > > > However, the proposed solution for issues 3677, 3679 meet these needs. > > In what way does the current spec not meet OTS requirements? How do the > current interceptors not know when an invocation begins and ends? How is > your requirement different from what the current spec offers. Why do you > need to know this? What in particular does OTS need to know, and why? > > > Ram > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 1 Aug 2000 14:46:21 -0700 (PDT) Message-Id: <200008012146.OAA28110@shorter.eng.sun.com> From: Harold Carr To: juergen@omg.org Cc: interceptors-ftf@omg.org, csi_submitters@concept5.com Subject: issue 3677, 3678, 3679 Content-Type: text X-UIDL: CR@e9RcOd9p"O!!@b&!! Juergen, interceptors ftf will be voting on these issues soon. For some reason, the following discussion did not make it into the issue archive for these issues. I am enclosing it again. Could you please ensure that this is in the archive for issues 3677, 3678, 3679? Thanks, Harold ============================================================================== The following is a sketch of a proposal for satisfying CSIv2 requirments stated (along with use-cases) in: http://cgi.omg.org/cgi-bin/doc?orbos/2000-06-20 That document basically calls for a feedback mechanism from client side receive_* points to subsequent send_request points due to retries. Please respond by either submitting an alternate solution or elaborating/fixing this one. Cheers, Harold ------------------------- 1st change: Feedback - 3677 CSIv2 needs to carry information scoped at the client invocation level which, given retries, could span multiple transport-level requests. The existing RequestInfo::request_id is scoped with transport-level requests so it cannot meet those needs. ClientRequestInfo::invocation_id is introduced to satisfy this requirement: local interface ClientRequestInfo : RequestInfo { ... readonly attribute unsigned long invocation_id; ... }; ClientRequestInfo::invocation_id would uniquely identify the invocation regardless of the number of transport level requests used to satisfy the invocation. Security could use invocation_id to index into a cookie jar to feedback information from a client receive_* point to a subsequent send_request due to retries. ------------------------- 2nd change: Cleanup - 3679 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. For example, a successive interceptor may raise an exception. To signal that client invocation scoped cookies should be cleaned up a new interceptor type with associated points is introduced: local interface ClientInvocationInterceptor : Interceptor { void invocation_begin (in ClientRequestInfo ri); void invocation_end (in ClientRequestInfo ri); }; invocation_begin would be invoked before the 1st send_request (or send_poll) which services the client invocation. It would not be invoked on subsequent send_* points due to retries. invocation_end would be invoked after the last receive_* which services the client invocation, before returning control to the client. These points are not allowed to raise exceptions. If they do raise System Exceptions, the ORB must ignore them. ------------------------- 3rd change: retries - 3678 An interceptor may want to force a retry. Currently this can be done by raising ForwardRequest. However, if the forwarded object is identical to the initial target, this may result in a different profile being selected, which may not be the desired semantics. To tell the ORB to retry using the same IOR and same profile within that IOR a new exception is introduced: exception Retry { }; local interface ClientRequestInterceptor : Interceptor { void send_request (in ClientRequestInfo ri) raises (ForwardRequest, Retry); void send_poll (in ClientRequestInfo ri); void receive_reply (in ClientRequestInfo ri); void receive_exception (in ClientRequestInfo ri); raises (ForwardRequest, Retry); void receive_other (in ClientRequestInfo ri); raises (ForwardRequest, Retry); }; ------------------------- Questions: What happens if all the tagged components in the selected profile have been tried unsuccessfully? It would seem that it would be useful to be able to specify to select "the next" profile. What happens if the server raises ForwardRequest, which is reported to receive_other and then receive_other raises Retry? It seems that it should do as told - ignore the ForwardRequest from the server and retry the same IOR/profile. How do retries based on the fault tolerance specification work viz-a-viz interceptors in general and the above proposal? For example, if FT does a retry without interceptors does the retry show up as a send_request with appropriate target and effective_target attributes? What does security's retry do to the FT algorithms? Are there any other CORBA-defined retry mechanisms?