Issue 9744: target_id and origin_id (qos4ccm-ftf) Source: Fraunhofer FOKUS (Mr. Tom Ritter, ritter@fokus.fraunhofer.de tom@users.berlios.de) Nature: Clarification Severity: Significant Summary: How does the client get the target_id? How does the server get the origin_id? It would seem that IOR components and service contexts would need to be standardized to portably exchange these. Resolution: Service Context ID and the content of the service context need to be standardized. For this reason a subsection has been added to section 8.3 Revised Text: A new subsection 8.3.6 has been added at the end of 8.3: 8.3.6 COPIServiceContext The COPIServiceContext struct contains information about the component identifier of the component instances participating in a call. origin_id denotes the client side component instance id. target_id denotes the server side component instance id. When Container Portable Interceptors are used the context_data component of the ServiceContext shall contain a CDR encapsulation of the COPIServiceContext struct, which is defined below: module IOP { const ServiceID COPI = 18; }; module Components { module ContainerPortableInterceptor { struct COPIServiceContext { CORBA::OctetSeq origin_id; CORBA::OCtetSeq target_id; CustomSlotItemSeq slot_info; }; }; }; 8.3.6.1 origin_id This identifies the client component instance id which is the originator of a call. Whenever a call is not issued by a component instance or the originator id can not be determined for any reason the sequence should have a zero length. 8.3.6.2 target_id This identifies the server component instance id which is the target of the call. Whenever the id of the target component instance can not be determined for any reason the sequence should have a zero length. 8.3.6.2 slot_info slot_info is used to transmit a CustomSlotItemSeq sequence between client side and server side Container Portable Interceptors. CustomSlotItems arey provided by Container PortableInterceptors during the processing of a call. See section 8.3.4.3 for details. · In Annex A2 the following IDL fragment has been inserted after opening the ContainerPortableInterceptor module. struct COPIServiceContext { CORBA::OctetSeq origin_id; CORBA::OCtetSeq target_id; CustomSlotItemSeq slot_info; }; Actions taken: May 18, 2006: received issue January 15, 2008: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 18 May 2006 04:33:25 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Tom Ritter Company: Fraunhofer FOKUS mailFrom: ritter@fokus.fraunhofer.de Notification: Yes Specification: QoS4CCM Section: 8.6.1 FormalNumber: ptc/06-04-15 Version: final adopted RevisionDate: April/2006 Page: 28 pp. Nature: Clarification Severity: Significant 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 target_id and origin_id How does the client get the target_id? How does the server get the origin_id? It would seem that IOR components and service contexts would need to be standardized to portably exchange these. Date: Tue, 21 Aug 2007 16:08:58 +0200 From: Tom Ritter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: qos4ccm-ftf@omg.org Subject: Propsoes solution issue 9744 X-OriginalArrivalTime: 21 Aug 2007 14:08:59.0929 (UTC) FILETIME=[D2165090:01C7E3FC] X-Fraunhofer-Email-Policy: accepted Hi All, I would propose the following solution for issue 9744. A new serviceID needs to be defined. The next one which is not already defined seems to be 18. Furthermore, the format of how to transmit origin_id and target id in the service context of a call has to be standardised. To reflekt these changes the following text will be added in the specification at the end of section 8.3 Please reply if you have any comment on this issue. For all the issues I have sent you may consult the issues history at: http://www.omg.org/issues/qos4ccm-ftf.open.html Cheers, Tom *************************** 8.3.6 COPIServiceContext The COPIServiceContext struct contains information about the component identifier of the component instances participating in a call. origin_id denotes the client side component instance id. target_id denotes the server side component instance id. When Container Portable Interceptors are used the context_data component of the ServiceContext shall contain a CDR encapsulation of the COPIServiceContext struct, which is defined below: module IOP { const ServiceID COPI = 18; }; module ContainerPortableInterceptor { struct COPIServiceContext { sequence origin_id; sequence target_id; }; }; 8.3.6.1 origin_id This identifies the client component instance id which is the originator of a call. Whenever a call is not issued by a component instance or the originator id can not be determined for any reason the sequence should have a zero length. 8.3.6.2 target_id This identifies the server component instance id which is the target of the call. Whenever the id of the target component instance can not be determined for any reason the sequence should have a zero length. -- 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