Issue 1613: QoS Policy values in compliance chapter (messaging-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: The compliance chapter needs to clarify which (if any) QoS Policy values must be supported by a compliant implementation. Resolution: Revised Text: As per discussion at face to face meeting a while back, the compliance statement was felt to be sufficient. Quoting Section B.1 (which should be editorially moved somewhere else) In order to be conformant with this specification, the following mappings and features must be supported and implemented using the specified semantics : ..... Quality of Service Policies for Messaging. These new Policies and their possible values are described in "Messaging Quality of Service" on page 1-2 Implementation of the following component is not required to be conformant with this specification : Time Independant Invocations (TII). This component includes the QoS Policy that supports TII(Queued Devliery Policy), the typed PersistentPollers described in Persistent Type Specific Poller on page 1-28, and all interoperable Routing interfaces described in "Message Routing Interoperability" on page 1-44 Close this issue. Actions taken: June 30, 1998: received issue January 9, 2001: closed issue Discussion: As per discussion at face to face meeting a while back, the compliance statement was felt to be sufficient. Quoting Section B.1 (which should be editorially moved somewhere else) In order to be conformant with this specification, the following mappings and features must be supported and implemented using the specified semantics : ..... Quality of Service Policies for Messaging. These new Policies and their possible values are described in "Messaging Quality of Service" on page 1-2 Implementation of the following component is not required to be conformant with this specification : Time Independant Invocations (TII). This component includes the QoS Policy that supports TII(Queued Devliery Policy), the typed PersistentPollers described in Persistent Type Specific Poller on page 1-28, and all interoperable Routing interfaces described in "Message Routing Interoperability" on page 1-44 Close this issue. End of Annotations:===== Return-Path: Sender: "Jon Goldberg" Date: Mon, 29 Jun 1998 16:00:05 -0700 From: Jon Goldberg To: "Daniel R. Frantz" CC: william.robinson@gte.com, messaging-rtf@omg.org, issues@omg.org Subject: Re: Quality of Service References: Hi Folks- I agree with Dan's assessment. Since all the framework is there to indicate support (or lack thereof), this should only require a minor addition of text to the compliance chapter. The following issue should be opened for the RTF: The compliance chapter needs to clarify which (if any) QoS Policy values must be supported by a compliant implementation. take care, Jon Daniel R. Frantz wrote: > > >-----Original Message----- > >From: William Robinson [mailto:william.robinson@gte.com] > >Sent: Monday, June 29, 1998 11:25 AM > > >The newly adopted messaging specification alludes to > >Guaranteed Delivery as an example of the kind of > >Quality of Service a vendor might provide. The > >spec seems to define a generic, extensible mechanism > >for requesting various kinds of QoS. Is there a > >formally defined list of the mandatory QoS that > >must be provided, or is it up each vendor to specify > >them? > > Hmmm... As one of the submitters, it was my understanding (perhaps > only > mine, others please join in) that there were no mandatory QoS > values. I > looked through the document to answer this question, expecting to > say > "Of course it says so, right here in section ....". Oops! I couldn't > find it. > > My understanding was that vendors would provide the QoS that their > customers demand and, as with many less explicitly defined qualities > of > implementation, QoS is a product differentiator. As far as > interoperability, that is taken care of by the reconciliation > process > that is well described. Programs have to be prepared to deal with > QoS > not offered or not reconcilable between client and server. > > What I can state in support of that interpretation is the > following. The > ORB::create_policy operation has an exception, PolicyError, > described > as: > > 5.2.2.4 exception PolicyError > > The requested Policy is not supported. The reason for the > failure is specified in the body of the exception. > > and the body is described as: > > 5.2.1.1 typedef short PolicyErrorCode > > A Policy may be invalid for the following reasons: > > * BAD_POLICY -- the requested Policy is not understood > by the ORB. > * UNSUPPORTED_POLICY - the requested Policy is understood > to be valid by the ORB, but is not currently supported. > * BAD_POLICY_TYPE - The type of the value requested for the > Policy is not valid for that PolicyType. > * BAD_POLICY_VALUE - The value requested for the Policy is > of a valid type but is not within the valid range for > that type. > * UNSUPPORTED_POLICY_VALUE - The value requested for the > Policy is of a valid type and within the valid range for > that type, but this valid value is not currently > supported. > > The USUPPORTED_POLICY and UNSUPPORTED_POLICY_VALUE are the means by > which the vendors informs the program that a policy isn't supported. > Since the TII feature is not mandated for conformance, for example, > this > would be the way a conforming implementation would tell the user > that it > doesn't support the optional part > > I suspect it would be a good idea for the RTF to make it very > explicit > what the requirements are. From: Bill Binko To: Messaging-Rtf Subject: Discussion Issue 1613: QoS Policy values in compliance chapter (m essaging-rtf) Date: Wed, 22 Mar 2000 12:29:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /H To: Messaging-Rtf Subject: RE: Discussion Issue 1613: QoS Policy values in compliance chapte r (m essaging-rtf) Date: Tue, 28 Mar 2000 13:34:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: A~+!!mI8!!V//!!&a[d9 This issue has still not gotten any discussion and it looks like it will be voted out of existence. However, I have two problems that I feel should be addressed and that I think were covered by this issue. I will vote for the resolution to close this one if we can agree to discuss the following in separate issues. 1) Are the MaxHops and QueueOrder also TII-specific policies. They seem to be peers with RoutingPolicy, so we should clarify that. 2) What is a non-TII ORB supposed to do when it gets an IOR with a RoutingPolicy that is not ROUTE_NONE. It seems that by killing 1613, we are not requiring non-TII ORBs to even check for this (since they don't even have to understand the Policy). However, I think it would be incorrect for any ORB to directly invoke a Object that has said it requires ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD. I would normally just put these in as separate issues, but I fear that I will get back "We decided that in 1613" as an argument to them. Can I get a sense of the RTF as to whether or you all feel these are valid concerns? Thanks Binko >-----Original Message----- >From: Bill Binko [mailto:Bill.Binko@trcinc.com] >Sent: Wednesday, March 22, 2000 12:29 PM >To: Messaging-Rtf >Subject: Discussion Issue 1613: QoS Policy values in compliance chapter >(m essaging-rtf) > > > > I don't think this issue has gotten enough discussion to >close at this >time. For example, I think that a Messaging-aware ORB should >be required to >understand all of the values of RoutingPolicy, even if it does >not support >TII. Since this policy can be set on the server-side, it is >possible for a >non-TII ORB to get an Object Reference that requires >ROUTE_STORE_AND_FORWARD. It is prohibited by the spec from >making direct >calls (if I read the spec right) and should fail if the >client's override >does not intersect, which it cannot without TII(as per section >5.3.5.3). > > I also think that the text quoted in the resolution >(section B1) straw >man is not complete as it does not address the MaxHopsPolicy or the >QueueOrderPolicy even though they are only meaningful in TII. > >Binko > Sender: Chris.Smith@uab.ericsson.se Message-ID: <38E1B14B.8759A174@uab.ericsson.se> Date: Wed, 29 Mar 2000 09:31:23 +0200 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Bill Binko CC: Messaging-Rtf Subject: Re: Discussion Issue 1613: QoS Policy values in compliance chapte r (m essaging-rtf) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: NoJe9k>)!!9hPe9Y<%e9 > 1) Are the MaxHops and QueueOrder also TII-specific policies. They seem to > be peers with RoutingPolicy, so we should clarify that. We discussed the general issue of the policies and their policy values at one of the face to face meetings and the resolution I proposed was the outcome of that discussion. I raised the issue of the MaxHops and QueueOrder a few weeks afterwards when I noticed that they probably apply only to TII. I seem to remember that there was some discussion that this did apply to non TII cases, but I could be imagining it. I wouldnt consider a new issue about these two particular policies to be "out of order". > 2) What is a non-TII ORB supposed to do when it gets an IOR with a > RoutingPolicy that is not ROUTE_NONE. It seems that by killing > 1613, we are > not requiring non-TII ORBs to even check for this (since they don't > even > have to understand the Policy). However, I think it would be > incorrect for > any ORB to directly invoke a Object that has said it requires > ROUTE_FORWARD > or ROUTE_STORE_AND_FORWARD. My wonderings about this a few months back were as follows. The Compliance statements said that it is optional to support "the Qos Policy that support TII(QueuedDeliveryPolicy) ....". However, there is no policy called QueuedDeliveryPolicy. I wondered whether in a previous draft there was one Policy that is now mapped to RoutingPolicy, MaxHopsPolicy and QueueOrderPolicy. Its probably a bit late in the vote to address this, but there is certainly an ambiguity that needs to be addressed in the next vote concerning what QueuedDeliveryPolicy in the compliance statement is supposed to map to. I think Issue 1613 was about the general issue of whether a compliant implementation has to support all the regular policies and all their values. > > I would normally just put these in as separate issues, but I fear > that I > will get back "We decided that in 1613" as an argument to them. > > Can I get a sense of the RTF as to whether or you all feel these are > valid > concerns? > > Thanks > Binko > > >-----Original Message----- > >From: Bill Binko [mailto:Bill.Binko@trcinc.com] > >Sent: Wednesday, March 22, 2000 12:29 PM > >To: Messaging-Rtf > >Subject: Discussion Issue 1613: QoS Policy values in compliance > chapter > >(m essaging-rtf) > > > > > > > > I don't think this issue has gotten enough discussion to > >close at this > >time. For example, I think that a Messaging-aware ORB should > >be required to > >understand all of the values of RoutingPolicy, even if it does > >not support > >TII. Since this policy can be set on the server-side, it is > >possible for a > >non-TII ORB to get an Object Reference that requires > >ROUTE_STORE_AND_FORWARD. It is prohibited by the spec from > >making direct > >calls (if I read the spec right) and should fail if the > >client's override > >does not intersect, which it cannot without TII(as per section > >5.3.5.3). > > > > I also think that the text quoted in the resolution > >(section B1) straw > >man is not complete as it does not address the MaxHopsPolicy or the > >QueueOrderPolicy even though they are only meaningful in TII. > > > >Binko > >