Issue 9746: Negotiation (qos4ccm-ftf) Source: Fraunhofer FOKUS (Mr. Tom Ritter, tom.ritter@fokus.fraunhofer.de) Nature: Clarification Severity: Minor Summary: Its not really clear here what is done by the business-logic component executor, what is done by the container, and what is done by QoSEnabler components. Who implements the Negotiation facet? Who makes the require_qos calls? Resolution: closed no change Revised Text: Actions taken: May 18, 2006: received issue January 15, 2008: closed issue Discussion: The basic intention of integrating negotiation into the connection set up is to make this transparent for the business logic. So business logic, which is component executor, is not involved or at least should not be involved in negotiation. Furthermore, the exact implementation strategy is left open to not restrict the implementation of the specification. Most likely negotiation is implemented by the container. The connect call which is used to connect two component instance is intercepted by the container. This interceptor calls the provide_facet with the identifier (_ccm_qos_negotiation) to get the reference of the negotiation interface. The negotiation interface is also implemented by the container. If QoSEnablers are used for generic management of QoS aspects they will use extended COPI to influence the outcome of the negotiation by examining the client requirements and allocating resources or by raising exception, which leads to unsuccessful completion of require_qos call. Again, the external interfaces and the external negotiation flow are defined by the specification the exact mechanisms to implement negotiation are not prescribed by this specification since, for example, negotiation and QoS management could also be done without QoSEnablers but with an otherwise extended container. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 18 May 2006 04:36:32 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Tom Ritter Company: Fraunhofer FOKUS mailFrom: ritter@fokus.fraunhofer.de Notification: Yes Specification: QoS4CCM Section: 8.8 FormalNumber: ptc/06-04-15 Version: final adopted RevisionDate: April/2006 Page: 35 pp. Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Description Negotiation Its not really clear here what is done by the business-logic component executor, what is done by the container, and what is done by QoSEnabler components. Who implements the Negotiation facet? Who makes the require_qos calls? Date: Mon, 27 Aug 2007 13:32:39 +0200 From: Tom Ritter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) To: qos4ccm-ftf@omg.org Subject: proposed solution to issue 9746 X-OriginalArrivalTime: 27 Aug 2007 11:32:31.0413 (UTC) FILETIME=[F492F650:01C7E89D] X-Fraunhofer-Email-Policy: accepted Hi All, I would propose to close issue 9746 with the following text: The basic intention of integrating negotiation into the connection set up is to make this transparent for the business logic. So business logic, which is component executor, is not involved or at least should not be involved in negotiation. Furthermore, the exact implementation strategy is left open to not restrict the implementation of the specification. Most likely negotiation is implemented by the container. The connect call which is used to connect two component instance is intercepted by the container. This interceptor calls the provide_facet with the identifier (_ccm_qos_negotiation) to get the reference of the negotiation interface. The negotiation interface is also implemented by the container. If QoSEnablers are used for generic management of QoS aspects they will use extended COPI to influence the outcome of the negotiation by examining the client requirements and allocating resources or by raising exception, which leads to unsuccessful completion of require_qos call. Again, the external interfaces and the external negotiation flow are defined by the specification the exact mechanisms to implement negotiation are not prescribed by this specification since, for example, negotiation and QoS management could also be done without QoSEnablers but with an otherwise extended container. please respond if you have any comment regarding this issue and the proposed solution. For history of issues please visist: http://www.omg.org/issues/qos4ccm-ftf.open.html Cheers, Tom -- Tom Ritter Head of Working Area Model-Driven Engineering Fraunhofer FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany +49 30 3463 - 7278 (fon), - 8000 (fax) mailto:tom.ritter@fokus.fraunhofer.de Date: Thu, 30 Aug 2007 14:57:10 +0200 From: Ansgar Radermacher User-Agent: Thunderbird 1.5.0.12 (X11/20070606) To: Tom Ritter Cc: qos4ccm-ftf@omg.org Subject: Re: proposed solution to issue 9746 Hello Tom, I think, we should use a more rigid wording in the specification: like currently stated, the business logic *should* not be involved, but the implementation strategy is left open. If our intention is that it may not be involved, I propose to replace the 2nd and 3rd sentence by the following text: "Whereas the exact implementation strategy is not restricted by the specification, the business logic may not be involved in negotiation." Btw: the only way for the business logic to find out that a negotiation has failed, is to find itself with an unconnected receptacle, right? Ansgar Tom Ritter wrote: Hi All, I would propose to close issue 9746 with the following text: The basic intention of integrating negotiation into the connection set up is to make this transparent for the business logic. So business logic, which is component executor, is not involved or at least should not be involved in negotiation. Furthermore, the exact implementation strategy is left open to not restrict the implementation of the specification. Most likely negotiation is implemented by the container. The connect call which is used to connect two component instance is intercepted by the container. This interceptor calls the provide_facet with the identifier (_ccm_qos_negotiation) to get the reference of the negotiation interface. The negotiation interface is also implemented by the container. If QoSEnablers are used for generic management of QoS aspects they will use extended COPI to influence the outcome of the negotiation by examining the client requirements and allocating resources or by raising exception, which leads to unsuccessful completion of require_qos call. Again, the external interfaces and the external negotiation flow are defined by the specification the exact mechanisms to implement negotiation are not prescribed by this specification since, for example, negotiation and QoS management could also be done without QoSEnablers but with an otherwise extended container. please respond if you have any comment regarding this issue and the proposed solution. For history of issues please visist: http://www.omg.org/issues/qos4ccm-ftf.open.html Cheers, Tom -- Ansgar Radermacher CEA/DRT/LIST http://www-list.cea.fr/index.htm http://www2.cs.unibw.de/alumni/Ansgar/ phone: +33 16908 3812 mailto: ansgar.radermacher@cea.fr Date: Fri, 31 Aug 2007 08:24:15 +0200 From: Tom Ritter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) To: Ansgar Radermacher Cc: qos4ccm-ftf@omg.org Subject: Re: proposed solution to issue 9746 X-OriginalArrivalTime: 31 Aug 2007 06:24:16.0193 (UTC) FILETIME=[8E375B10:01C7EB97] X-Fraunhofer-Email-Policy: accepted Hello Ansgar, ok I agree. We can change the text in response to this issue. However, the resolution is still to close this issue with no change. I think, you can therefore place your vote on this issue. Cheers, Tom Ansgar Radermacher wrote: Hello Tom, I think, we should use a more rigid wording in the specification: like currently stated, the business logic *should* not be involved, but the implementation strategy is left open. If our intention is that it may not be involved, I propose to replace the 2nd and 3rd sentence by the following text: "Whereas the exact implementation strategy is not restricted by the specification, the business logic may not be involved in negotiation." Btw: the only way for the business logic to find out that a negotiation has failed, is to find itself with an unconnected receptacle, right? Ansgar Tom Ritter wrote: Hi All, I would propose to close issue 9746 with the following text: The basic intention of integrating negotiation into the connection set up is to make this transparent for the business logic. So business logic, which is component executor, is not involved or at least should not be involved in negotiation. Furthermore, the exact implementation strategy is left open to not restrict the implementation of the specification. Most likely negotiation is implemented by the container. The connect call which is used to connect two component instance is intercepted by the container. This interceptor calls the provide_facet with the identifier (_ccm_qos_negotiation) to get the reference of the negotiation interface. The negotiation interface is also implemented by the container. If QoSEnablers are used for generic management of QoS aspects they will use extended COPI to influence the outcome of the negotiation by examining the client requirements and allocating resources or by raising exception, which leads to unsuccessful completion of require_qos call. Again, the external interfaces and the external negotiation flow are defined by the specification the exact mechanisms to implement negotiation are not prescribed by this specification since, for example, negotiation and QoS management could also be done without QoSEnablers but with an otherwise extended container. please respond if you have any comment regarding this issue and the proposed solution. For history of issues please visist: http://www.omg.org/issues/qos4ccm-ftf.open.html Cheers, Tom -- Tom Ritter Head of Working Area Model-Driven Engineering Fraunhofer FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany +49 30 3463 - 7278 (fon), - 8000 (fax) mailto:tom.ritter@fokus.fraunhofer.de http://www.fokus.fraunhofer.de/usr/ritter