Issue 3677: Interceptors must provide user-level request ID (interceptors-rtf) Source: (, ) 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: June 18, 2000: received issue April 26, 2010: closed issue Discussion: End of Annotations:===== 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 PAA15948; 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 PAA65268; Sun, 18 Jun 2000 15:53:28 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256902.006D3D43 ; Sun, 18 Jun 2000 15:53:11 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, issues@omg.org cc: csi_submitters@concept5.com Message-ID: <85256902.006D3BCD.00@d54mta02.raleigh.ibm.com> Date: Sun, 18 Jun 2000 21:38:03 +0100 Subject: Interceptors must provide user-level request ID Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 5Qe!!@Add9MX/!!HgKe9 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; Russell Butek butek@us.ibm.com Date: Wed, 28 Jun 2000 09:37:30 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID References: <85256902.006D3BCD.00@d54mta02.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \;7!!WDIe9j(Pe9f]:e9 This seems fine to me. However I would name it: invocation_id to further distinquish from transport level request/replies. And to clarify to all, this would be used as an index into a cookie jar specifically for feeding back info from receive_* client points to subsequent retries. An additional point (in a new interceptor) request_done would signal when it is time to clean up the cookie jar entry for this id (the additional point is the subject of a message sent out by Russell earlier). Since there has been no discussion on this (or the other issues raised to support CSIv2 as presented by Rob High in Oslo) I assume everyone basically agrees. If not please speak up. Russell and I plan to work on the three issues a bit more and call a vote soon. Thanks, Harold butek@us.ibm.com wrote: > > 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; > > Russell Butek > butek@us.ibm.com Date: Wed, 28 Jun 2000 13:00:09 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: butek@us.ibm.com, interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID References: <85256902.006D3BCD.00@d54mta02.raleigh.ibm.com> <395A29CA.FEFC605E@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KM,e9HhIe9&[Sd9[WRd9 Don't assume no discussion means agreement. IONA is basically opposed to adding any new intecept points, particularly when they are being added in order to support features not included in the adopted specification. The FTF's charter is to fix whats broken in the adopted specification, not to add features. We are specifically opposed to adding a request_done intercept point. In our experience, this kind of intercept point is not needed, and would add unnecessary overhead to all requests, even when portable interceptors are not being used. -Bob Harold Carr wrote: > > This seems fine to me. However I would name it: > > invocation_id > > to further distinquish from transport level request/replies. > > And to clarify to all, this would be used as an index into a > cookie jar specifically for feeding back info from receive_* > client points to subsequent retries. An additional point > (in a new interceptor) request_done would signal when it > is time to clean up the cookie jar entry for this id (the additional > point is the subject of a message sent out by Russell earlier). > > Since there has been no discussion on this (or the other issues > raised to support CSIv2 as presented by Rob High in Oslo) I > assume everyone basically agrees. If not please speak up. > Russell and I plan to work on the three issues a bit more > and call a vote soon. > > Thanks, > Harold > > butek@us.ibm.com wrote: > > > > 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; > > > > Russell Butek > > butek@us.ibm.com Date: Wed, 28 Jun 2000 10:08:51 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: butek@us.ibm.com, interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID References: <85256902.006D3BCD.00@d54mta02.raleigh.ibm.com> <395A29CA.FEFC605E@sun.com> <395A2F18.B44021B7@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: TA]d9p`Be9m5Qe9IpW!! Bob, IONA did have a person at the meeting when Rob High presented CSIv2 requirements. There was some brainstorming on how to meet those requirements. At that time IONA did not object. I assume something has changed? FTFs charter is to fix what is broken to meet the RFP which calls for specifically supporting security and transactions services. Also, the proposal to meet these requirements calls for a new interceptor, not a new point on the existing client side. I would imagine in general the list of this new interceptor would be small or empty in many cases. Therefore the overhead does not seem to be a problem. I assume you have read Rob High's presentation: http://www.omg.org/cgi-bin/doc?orbos/2000-06-20 If so, can you present an alternative solution to what Russell proposed? Cheers, Harold Bob Kukura wrote: > > Don't assume no discussion means agreement. IONA is basically opposed to > adding any new intecept points, particularly when they are being added > in order to support features not included in the adopted specification. > The FTF's charter is to fix whats broken in the adopted specification, > not to add features. > > We are specifically opposed to adding a request_done intercept point. In > our experience, this kind of intercept point is not needed, and would > add unnecessary overhead to all requests, even when portable > interceptors are not being used. > > -Bob > > Harold Carr wrote: > > > > This seems fine to me. However I would name it: > > > > invocation_id > > > > to further distinquish from transport level request/replies. > > > > And to clarify to all, this would be used as an index into a > > cookie jar specifically for feeding back info from receive_* > > client points to subsequent retries. An additional point > > (in a new interceptor) request_done would signal when it > > is time to clean up the cookie jar entry for this id (the additional > > point is the subject of a message sent out by Russell earlier). > > > > Since there has been no discussion on this (or the other issues > > raised to support CSIv2 as presented by Rob High in Oslo) I > > assume everyone basically agrees. If not please speak up. > > Russell and I plan to work on the three issues a bit more > > and call a vote soon. > > > > Thanks, > > Harold > > > > butek@us.ibm.com wrote: > > > > > > 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; > > > > > > Russell Butek > > > butek@us.ibm.com From: highr@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 NAA62036; Wed, 28 Jun 2000 13:04:20 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA41304; Wed, 28 Jun 2000 13:13:09 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690C.005E94B3 ; Wed, 28 Jun 2000 13:13:04 -0400 X-Lotus-FromDomain: IBMUS To: Harold Carr cc: butek@us.ibm.com, interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Message-ID: <8525690C.005E4A7A.00@d54mta03.raleigh.ibm.com> Date: Wed, 28 Jun 2000 12:09:51 -0500 Subject: Re: Interceptors must provide user-level request ID Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 3[-e9(0d!![]ld9IOMe9 If you're going to use the name 'invocation_id' to distinguish the higher-level idea from the lower level request messages, does it make sense to all use the name 'invocation_done' for the clean-up interceptor for the same reason? Rob High Jr. Senior Technical Staff Member WebSphere Architecture and Development IBM Corporation Austin, TX ------------------------------------------------------ Lotus Notes: Rob High/Austin/IBM@IBMUS, Internet: highr@us.ibm.com External: (512) 838-2103, Tie-line: 678-2103, Fax: (512) 838-1032, Cell: (512) 797-1180 Harold Carr on 06/28/2000 11:37:30 AM To: Russell Butek/Austin/IBM@IBMUS cc: interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID This seems fine to me. However I would name it: invocation_id to further distinquish from transport level request/replies. And to clarify to all, this would be used as an index into a cookie jar specifically for feeding back info from receive_* client points to subsequent retries. An additional point (in a new interceptor) request_done would signal when it is time to clean up the cookie jar entry for this id (the additional point is the subject of a message sent out by Russell earlier). Since there has been no discussion on this (or the other issues raised to support CSIv2 as presented by Rob High in Oslo) I assume everyone basically agrees. If not please speak up. Russell and I plan to work on the three issues a bit more and call a vote soon. Thanks, Harold butek@us.ibm.com wrote: > > 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; > > Russell Butek > butek@us.ibm.com From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA20894; Wed, 28 Jun 2000 12:56:48 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA28050; Wed, 28 Jun 2000 13:18:01 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690C.005F07B7 ; Wed, 28 Jun 2000 13:17:58 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, csi_submitters@concept5.com Message-ID: <8525690C.005EC539.00@d54mta03.raleigh.ibm.com> Date: Wed, 28 Jun 2000 13:15:07 -0400 Subject: Re: Interceptors must provide user-level request ID Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ;?9e9@]&!!$~He9~MM!! Bob, Part of the reason for doing Portable Interceptors was to support the security service. If the interceptors do not meet a requirement of security, then I take that as meaning that the PI spec is broken. Please look at the issues (well, they're not formal issues, yet) that I opened for security - notes titled: Interceptors must provide a retry mechanism Interceptors must provide user-level request ID Portable Interceptors must provide a means for security interceptors to clean up If you can come up with a way to solve their problems without adding another interception point, wonderful. But we must solve their problem, otherwise one of the biggest reasons for interceptors goes out the window. Russell Butek butek@us.ibm.com Bob Kukura on 06/28/2000 12:00:09 PM To: Harold Carr cc: Russell Butek/Austin/IBM@IBMUS, interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID Don't assume no discussion means agreement. IONA is basically opposed to adding any new intecept points, particularly when they are being added in order to support features not included in the adopted specification. The FTF's charter is to fix whats broken in the adopted specification, not to add features. We are specifically opposed to adding a request_done intercept point. In our experience, this kind of intercept point is not needed, and would add unnecessary overhead to all requests, even when portable interceptors are not being used. -Bob Harold Carr wrote: > > This seems fine to me. However I would name it: > > invocation_id > > to further distinquish from transport level request/replies. > > And to clarify to all, this would be used as an index into a > cookie jar specifically for feeding back info from receive_* > client points to subsequent retries. An additional point > (in a new interceptor) request_done would signal when it > is time to clean up the cookie jar entry for this id (the additional > point is the subject of a message sent out by Russell earlier). > > Since there has been no discussion on this (or the other issues > raised to support CSIv2 as presented by Rob High in Oslo) I > assume everyone basically agrees. If not please speak up. > Russell and I plan to work on the three issues a bit more > and call a vote soon. > > Thanks, > Harold > > butek@us.ibm.com wrote: > > > > 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; > > > > Russell Butek > > butek@us.ibm.com From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA19200; Wed, 28 Jun 2000 13:01:39 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA34098; Wed, 28 Jun 2000 13:22:52 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690C.005F7977 ; Wed, 28 Jun 2000 13:22:50 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, csi_submitters@concept5.com Message-ID: <8525690C.005F35D7.00@d54mta03.raleigh.ibm.com> Date: Wed, 28 Jun 2000 13:19:56 -0400 Subject: Re: Interceptors must provide user-level request ID Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: l~%e9eS7e925Yd9&M_!! Rob, I agree. Russell Butek butek@us.ibm.com Rob High 06/28/2000 12:09 PM To: Harold Carr cc: Russell Butek/Austin/IBM@IBMUS, interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com From: Rob High/Austin/IBM@IBMUS Subject: Re: Interceptors must provide user-level request ID (Document link: Database 'Russell Butek', View '($Inbox)') If you're going to use the name 'invocation_id' to distinguish the higher-level idea from the lower level request messages, does it make sense to all use the name 'invocation_done' for the clean-up interceptor for the same reason? Rob High Jr. Senior Technical Staff Member WebSphere Architecture and Development IBM Corporation Austin, TX ------------------------------------------------------ Lotus Notes: Rob High/Austin/IBM@IBMUS, Internet: highr@us.ibm.com External: (512) 838-2103, Tie-line: 678-2103, Fax: (512) 838-1032, Cell: (512) 797-1180 Harold Carr on 06/28/2000 11:37:30 AM To: Russell Butek/Austin/IBM@IBMUS cc: interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID This seems fine to me. However I would name it: invocation_id to further distinquish from transport level request/replies. And to clarify to all, this would be used as an index into a cookie jar specifically for feeding back info from receive_* client points to subsequent retries. An additional point (in a new interceptor) request_done would signal when it is time to clean up the cookie jar entry for this id (the additional point is the subject of a message sent out by Russell earlier). Since there has been no discussion on this (or the other issues raised to support CSIv2 as presented by Rob High in Oslo) I assume everyone basically agrees. If not please speak up. Russell and I plan to work on the three issues a bit more and call a vote soon. Thanks, Harold butek@us.ibm.com wrote: > > 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; > > Russell Butek > butek@us.ibm.com Date: Wed, 28 Jun 2000 10:20:18 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: highr@us.ibm.com CC: butek@us.ibm.com, interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID References: <8525690C.005E4A7A.00@d54mta03.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *bJ!!;8Zd9^7n!!4ZNe9 Yes. Basically I would replace "request" with "invocation" in all the parts of Russell's proposal. H highr@us.ibm.com wrote: > > If you're going to use the name 'invocation_id' to distinguish the > higher-level idea from the lower level request messages, does it make sense > to all use the name 'invocation_done' for the clean-up interceptor for the > same reason? > > Rob High Jr. > Senior Technical Staff Member > WebSphere Architecture and Development > IBM Corporation > Austin, TX > ------------------------------------------------------ > Lotus Notes: Rob High/Austin/IBM@IBMUS, Internet: highr@us.ibm.com > External: (512) 838-2103, Tie-line: 678-2103, Fax: (512) 838-1032, Cell: > (512) 797-1180 > > Harold Carr on 06/28/2000 11:37:30 AM > > To: Russell Butek/Austin/IBM@IBMUS > cc: interceptors-ftf@omg.org, issues@omg.org, csi_submitters@concept5.com > Subject: Re: Interceptors must provide user-level request ID > > This seems fine to me. However I would name it: > > invocation_id > > to further distinquish from transport level request/replies. > > And to clarify to all, this would be used as an index into a > cookie jar specifically for feeding back info from receive_* > client points to subsequent retries. An additional point > (in a new interceptor) request_done would signal when it > is time to clean up the cookie jar entry for this id (the additional > point is the subject of a message sent out by Russell earlier). > > Since there has been no discussion on this (or the other issues > raised to support CSIv2 as presented by Rob High in Oslo) I > assume everyone basically agrees. If not please speak up. > Russell and I plan to work on the three issues a bit more > and call a vote soon. > > Thanks, > Harold > > butek@us.ibm.com wrote: > > > > 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; > > > > Russell Butek > > butek@us.ibm.com Date: Wed, 28 Jun 2000 14:04:15 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: butek@us.ibm.com, interceptors-ftf@omg.org, csi_submitters@concept5.com Subject: Re: Interceptors must provide user-level request ID References: <85256902.006D3BCD.00@d54mta02.raleigh.ibm.com> <395A29CA.FEFC605E@sun.com> <395A2F18.B44021B7@iona.com> <395A3123.EBE76B4@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FQ""!D^Oe9@(7!!j&/!! I hadn't seen Rob's presentation, nor heard any of the details. On quick glance, I still fail to see what a portable interceptor can validly do regarding this supposed "request context". For one thing, just because a particular portable interceptor sees one attempt at executing a request does not imply that it will necessarily see all other attempts. Orbix 2000, and probably other advanced ORBs as well, has its own notion of "binding" that goes way beyond what is covered in the portable interceptors specification. A retry basically involves attempting to establish a new binding. Our ORB has mechanisms it uses to decide which interceptors, including portable interceptors, will be involved in a particular binding attempt. There is absolutely no guarantee that all attempts to bind will use the same set of interceptors. The Orbix 2000 core also controls how many retry attempts are made, and things like that, that Rob seems to want to control from the CSIv2 interceptor. Finally, in a multithreaded client, there isn't even a guarantee that all the retry attempts that eventually lead to a particular binding being established were even the result of the same initial invocation (i.e. "request context"). We worked hard in the portable interceptors submission process to ensure that the portable interceptors functionality would peacefully coexist with more advanced proprietary functionality already present in existing ORBs. Rob's proposals do not seem to take the existence of ORB functionality outside the scope of the Portable Interceptors specification into account. I'm obviously going to have to study the current CSIv2 draft, and Rob's proposal, in more detail to decide whether we can support the kinds of changes he is proposing, or to come up with appropriate counter-proposals. -Bob Harold Carr wrote: > > Bob, > > IONA did have a person at the meeting when Rob High > presented CSIv2 requirements. There was some brainstorming > on how to meet those requirements. At that time IONA > did not object. I assume something has changed? > > FTFs charter is to fix what is broken to meet the > RFP which calls for specifically supporting security > and transactions services. > > Also, the proposal to meet these requirements calls > for a new interceptor, not a new point on the existing > client side. I would imagine in general the list > of this new interceptor would be small or empty > in many cases. Therefore the overhead does not seem > to be a problem. > > I assume you have read Rob High's presentation: > > http://www.omg.org/cgi-bin/doc?orbos/2000-06-20 > > If so, can you present an alternative solution > to what Russell proposed? > > Cheers, > Harold > > Bob Kukura wrote: > > > > Don't assume no discussion means agreement. IONA is basically opposed to > > adding any new intecept points, particularly when they are being added > > in order to support features not included in the adopted specification. > > The FTF's charter is to fix whats broken in the adopted specification, > > not to add features. > > > > We are specifically opposed to adding a request_done intercept point. In > > our experience, this kind of intercept point is not needed, and would > > add unnecessary overhead to all requests, even when portable > > interceptors are not being used. > > > > -Bob > > > > Harold Carr wrote: > > > > > > This seems fine to me. However I would name it: > > > > > > invocation_id > > > > > > to further distinquish from transport level request/replies. > > > > > > And to clarify to all, this would be used as an index into a > > > cookie jar specifically for feeding back info from receive_* > > > client points to subsequent retries. An additional point > > > (in a new interceptor) request_done would signal when it > > > is time to clean up the cookie jar entry for this id (the additional > > > point is the subject of a message sent out by Russell earlier). > > > > > > Since there has been no discussion on this (or the other issues > > > raised to support CSIv2 as presented by Rob High in Oslo) I > > > assume everyone basically agrees. If not please speak up. > > > Russell and I plan to work on the three issues a bit more > > > and call a vote soon. > > > > > > Thanks, > > > Harold > > > > > > butek@us.ibm.com wrote: > > > > > > > > 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; > > > > > > > > Russell Butek > > > > butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Interceptors must provide user-level request ID Date: Thu, 29 Jun 2000 08:09:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: #7M!!3>L!!j,g!!I0Ae9 I have read the entire chain on this, and don't yet have a strong opinion one way or the other, except that I think it is probably in scope to find some way to make security work. One question on the specific proposal here: what is the lifetime of the invocation id? When, if ever, can one be recycled? Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Wednesday, June 28, 2000 12:38 PM > To: butek@us.ibm.com > Cc: interceptors-ftf@omg.org; issues@omg.org; > csi_submitters@concept5.com > Subject: Re: Interceptors must provide user-level request ID > > > This seems fine to me. However I would name it: > > invocation_id > > to further distinquish from transport level request/replies. > > And to clarify to all, this would be used as an index into a > cookie jar specifically for feeding back info from receive_* > client points to subsequent retries. An additional point > (in a new interceptor) request_done would signal when it > is time to clean up the cookie jar entry for this id (the additional > point is the subject of a message sent out by Russell earlier). > > Since there has been no discussion on this (or the other issues > raised to support CSIv2 as presented by Rob High in Oslo) I > assume everyone basically agrees. If not please speak up. > Russell and I plan to work on the three issues a bit more > and call a vote soon. > > Thanks, > Harold > > butek@us.ibm.com wrote: > > > > 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; > > > > Russell Butek > > butek@us.ibm.com > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA10588 for ; Thu, 29 Jun 2000 08:28:23 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id IAA90808 for ; Thu, 29 Jun 2000 08:49:39 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.00466F36 ; Thu, 29 Jun 2000 08:49:19 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <8525690D.004669DA.00@d54mta03.raleigh.ibm.com> Date: Thu, 29 Jun 2000 08:49:04 -0400 Subject: RE: Interceptors must provide user-level request ID Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: e2X!!Y0a!!FFld9;=R!! The invocation id is an ID for the method request from the perspective of the client application. So the life of the invocation effectively begins when the client makes a method call on a stub, and it ends when control returns to the client. I see no reason why the id couldn't be recycled when the invocation ends. Russell Butek butek@us.ibm.com Paul Kyzivat on 06/29/2000 07:09:14 AM To: interceptors-ftf@omg.org cc: Subject: RE: Interceptors must provide user-level request ID I have read the entire chain on this, and don't yet have a strong opinion one way or the other, except that I think it is probably in scope to find some way to make security work. One question on the specific proposal here: what is the lifetime of the invocation id? When, if ever, can one be recycled? Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Wednesday, June 28, 2000 12:38 PM > To: butek@us.ibm.com > Cc: interceptors-ftf@omg.org; issues@omg.org; > csi_submitters@concept5.com > Subject: Re: Interceptors must provide user-level request ID > > > This seems fine to me. However I would name it: > > invocation_id > > to further distinquish from transport level request/replies. > > And to clarify to all, this would be used as an index into a > cookie jar specifically for feeding back info from receive_* > client points to subsequent retries. An additional point > (in a new interceptor) request_done would signal when it > is time to clean up the cookie jar entry for this id (the additional > point is the subject of a message sent out by Russell earlier). > > Since there has been no discussion on this (or the other issues > raised to support CSIv2 as presented by Rob High in Oslo) I > assume everyone basically agrees. If not please speak up. > Russell and I plan to work on the three issues a bit more > and call a vote soon. > > Thanks, > Harold > > butek@us.ibm.com wrote: > > > > 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; > > > > Russell Butek > > butek@us.ibm.com > 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?