Issue 6314: GIOP Conformance and Interceptors (corba-rtf) Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: GIOP Conformance and Interceptor don't play well together. GIOP minor version conformance mandates two things. 1. That standard service contexts that are considered optional can be ignored should the implementation not understand them. 2. That certain service contexts get processed according to the specification of where they are defined. This requirement works well for GIOP 1.2 where a lot of them are optional, since (1) will apply. An implementation can claim 1.2 conformance and not process any of them. However, 1.3 and upcoming 1.4 will mandate the processing of them according to their specification. In many cases, this means that some default response may be required, which means that a GIOP 1.3, or later engine must have a "default" response for these service contexts. In an ORB that uses interceptors and has a generic GIOP messaging engine there is no way for the engine to "know" when or not to process a particular service context. It requires strict processing by the GIOP engine, or it requires "default" interceptors to be installed to maintain the level of conformance. However, interceptors have no way of "declaring" which service contexts they handle, and whether they they are overriding already installed (default) interceptors for processing those particular service contexts. For example, an non-transactional ORB that is GIOP 1.2 compliant must process the Transaction Service Context by raising a TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but by certain in implementations it ALWAYS is). A default interceptor is needed in the ORB implementation to do this. However, for an ORB configuration that wants to process this, there is no way for an interceptor to "override" default processing. Resolution: Revised Text: Actions taken: October 8, 2003: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== uthentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Wed, 8 Oct 2003 10:04:55 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: issues@omg.org, corba-rtf@omg.org Subject: GIOP Conformance and Interceptors CORE RTF Issue GIOP Conformance and Interceptor don't play well together. GIOP minor version conformance mandates two things. 1. That standard service contexts that are considered optional can be ignored should the implementation not understand them. 2. That certain service contexts get processed according to the specification of where they are defined. This requirement works well for GIOP 1.2 where a lot of them are optional, since (1) will apply. An implementation can claim 1.2 conformance and not process any of them. However, 1.3 and upcoming 1.4 will mandate the processing of them according to their specification. In many cases, this means that some default response may be required, which means that a GIOP 1.3, or later engine must have a "default" response for these service contexts. In an ORB that uses interceptors and has a generic GIOP messaging engine there is no way for the engine to "know" when or not to process a particular service context. It requires strict processing by the GIOP engine, or it requires "default" interceptors to be installed to maintain the level of conformance. However, interceptors have no way of "declaring" which service contexts they handle, and whether they they are overriding already installed (default) interceptors for processing those particular service contexts. For example, an non-transactional ORB that is GIOP 1.2 compliant must process the Transaction Service Context by raising a TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but by certain in implementations it ALWAYS is). A default interceptor is needed in the ORB implementation to do this. However, for an ORB configuration that wants to process this, there is no way for an interceptor to "override" default processing. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: GIOP Conformance and Interceptors Date: Thu, 9 Oct 2003 14:19:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIOP Conformance and Interceptors Thread-Index: AcONp1P6vYJgt30lQVGM+D33/CM7AQA6hN9Q From: "Bergersen, Rebecca" To: "Polar Humenn" , , Cc: "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h99IGBQR014035 If processing a particular service context is required by a particular GIOP version, and an ORB implementation uses a (portable or native?) interceptor to process this service context, then the ORB is misconfigured if this interceptor is not present in the server-side binding. Polar appears to be looking for some standard way of checking that the particular interceptor is present in the binding, by it declaring up front what service contexts it processes. But this doesn't really guarantee that the correct behaviour will occur when the service context is encountered - i.e. there would nothing stopping an application level portable interceptor claiming to process TAG_CODE_SETS contexts, but then just logging the service context data instead of implementing any real codeset functionality. So I think its up to the ORB config/deployment/admin mechanisms to ensure that the correct ORB service interceptors particpate in the appropriate bindings, and this is not an issue for the spec. Regards, Rebecca Rebecca Bergersen PRINCIPAL ARCHITECT, Middleware Standards rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street, Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Wednesday, October 08, 2003 10:05 AM > To: issues@omg.org; corba-rtf@omg.org > Subject: GIOP Conformance and Interceptors > > > > CORE RTF Issue > > GIOP Conformance and Interceptor don't play well together. > > GIOP minor version conformance mandates two things. > > 1. That standard service contexts that are considered optional > can be ignored should the implementation not understand them. > > 2. That certain service contexts get processed according to the > specification of where they are defined. > > This requirement works well for GIOP 1.2 where a lot of them > are optional, > since (1) will apply. An implementation can claim 1.2 > conformance and not > process any of them. > > However, 1.3 and upcoming 1.4 will mandate the processing of them > according to their specification. In many cases, this means that some > default response may be required, which means that a GIOP > 1.3, or later > engine must have a "default" response for these service contexts. > > In an ORB that uses interceptors and has a generic GIOP > messaging engine > there is no way for the engine to "know" when or not to process a > particular service context. It requires strict processing by the GIOP > engine, or it requires "default" interceptors to be installed > to maintain > the level of conformance. > > However, interceptors have no way of "declaring" which > service contexts > they handle, and whether they they are overriding already installed > (default) interceptors for processing those particular > service contexts. > > For example, an non-transactional ORB that is GIOP 1.2 compliant must > process the Transaction Service Context by raising a > TRANSACTION_UNAVAILABLE exception, because by default the ORB > is in the > OTS_NOT_CONNECTED state. It cannot be ignored to comply with > GIOP 1.2 (but > by certain in implementations it ALWAYS is). A default interceptor is > needed in the ORB implementation to do this. However, for an ORB > configuration that wants to process this, there is no way for an > interceptor to "override" default processing. > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Fri, 10 Oct 2003 13:58:13 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: "Bergersen, Rebecca" cc: issues@omg.org, corba-rtf@omg.org, "Bergersen, Rebecca" Subject: RE: GIOP Conformance and Interceptors On Thu, 9 Oct 2003, Bergersen, Rebecca wrote: > If processing a particular service context is required by a particular > GIOP version, and an ORB implementation uses a (portable or native?) > interceptor to process this service context, then the ORB is > misconfigured if this interceptor is not present in the server-side > binding. > > Polar appears to be looking for some standard way of checking that the > particular interceptor is present in the binding, by it declaring up > front what service contexts it processes. But this doesn't really > guarantee that the correct behaviour will occur when the service context > is encountered - That's exactly what I am looking for. Something to guarantee the correct behavior. > i.e. there would nothing stopping an application level portable > interceptor claiming to process TAG_CODE_SETS contexts, but then just > logging the service context data instead of implementing any real > codeset functionality. This is a problem, caused by just what I was arguing about for Firewall and BidDirectional. Code Sets have nothing to do with request level service contexts. They are session paramaters, and don't belong there. It would really be unfortunate that this problem may indeed hinder a good resolution to the problem at hand. I can see now, band-aiding the process by declaring some ServiceContexts as request related, and others as Session Related. > So I think its up to the ORB config/deployment/admin mechanisms to > ensure that the correct ORB service interceptors particpate in the > appropriate bindings, That might be an option for an ORB of which you *have* control of the configuration at start time. And even if it is done that way, none of those configuration paramters are standard. We do have standard methods that support configuration, such as InitRef and NameService and loading of ORBInitializers. So, why not for this? I should be able to build a flexible ORB, one that does the right thing for GIOP 1.3 right out of the box, according to the GIOP interoperability conformance specification. There should be a standard way for somebody, perhaps using standard ORBInitializers that obviate the need for default processing of certain "request related" service contexts, such as installing an OTS interceptor. This would help us with portability of interceptors as well as building flexible ORBs that can handle standard initialization. > and this is not an issue for the spec. Seems like it certainly warrants discussion within the CORE RTF and I believe we should be able to come to an acceptable resolution for the problem at hand. It is issue 6314. Cheers, -Polar > Regards, > Rebecca > > Rebecca Bergersen > PRINCIPAL ARCHITECT, Middleware Standards > rebecca.bergersen@iona.com > ------------------------------------------------------- > IONA Technologies > 200 West Street, Waltham, MA 02451 USA > Tel: (781) 902-8265 > Fax: (781) 902-8001 > ------------------------------------------------------- > Making Software Work Together TM > > > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Wednesday, October 08, 2003 10:05 AM > > To: issues@omg.org; corba-rtf@omg.org > > Subject: GIOP Conformance and Interceptors > > > > > > > > CORE RTF Issue > > > > GIOP Conformance and Interceptor don't play well together. > > > > GIOP minor version conformance mandates two things. > > > > 1. That standard service contexts that are considered optional > > can be ignored should the implementation not understand them. > > > > 2. That certain service contexts get processed according to the > > specification of where they are defined. > > > > This requirement works well for GIOP 1.2 where a lot of them > > are optional, > > since (1) will apply. An implementation can claim 1.2 > > conformance and not > > process any of them. > > > > However, 1.3 and upcoming 1.4 will mandate the processing of them > > according to their specification. In many cases, this means that some > > default response may be required, which means that a GIOP > > 1.3, or later > > engine must have a "default" response for these service contexts. > > > > In an ORB that uses interceptors and has a generic GIOP > > messaging engine > > there is no way for the engine to "know" when or not to process a > > particular service context. It requires strict processing by the GIOP > > engine, or it requires "default" interceptors to be installed > > to maintain > > the level of conformance. > > > > However, interceptors have no way of "declaring" which > > service contexts > > they handle, and whether they they are overriding already installed > > (default) interceptors for processing those particular > > service contexts. > > > > For example, an non-transactional ORB that is GIOP 1.2 compliant must > > process the Transaction Service Context by raising a > > TRANSACTION_UNAVAILABLE exception, because by default the ORB > > is in the > > OTS_NOT_CONNECTED state. It cannot be ignored to comply with > > GIOP 1.2 (but > > by certain in implementations it ALWAYS is). A default interceptor is > > needed in the ORB implementation to do this. However, for an ORB > > configuration that wants to process this, there is no way for an > > interceptor to "override" default processing. > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com