Issue 1303: TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Is there any particular reason that we shouldn"t allow these two ComponentIds in IIOP IORs? They certainly can be useful using IIOP for optimization of client/server interactions, and can be safely ignored by clients that don"t implement/understand them. So could we add text to the spec that states that these components are allowed in IIOP IORs, but the clients are free to ignore them? Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do Revised Text: Actions taken: May 4, 1998: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Sun, 03 May 1998 20:10:17 -0700 From: Jonathan Biggar To: interop@omg.org, issues@omg.org Subject: TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY Is there any particular reason that we shouldn't allow these two ComponentIds in IIOP IORs? They certainly can be useful using IIOP for optimization of client/server interactions, and can be safely ignored by clients that don't implement/understand them. So could we add text to the spec that states that these components are allowed in IIOP IORs, but the clients are free to ignore them? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 20 Jul 1998 13:21:56 -0400 From: Bob Kukura Organization: IONA Technologies To: interop@omg.org Subject: interop vote 1 Here are IONA/Martin's votes for vote 1: 782, 885, 935, 1503, 1525, 1544, 1588, 1669, IIOPMessagingRFP, IIOPFirewallRFP: YES 1303: NO - We agree with Jon Biggar that the TAG_ENDPOINT_ID_POSITION, and maybe TAG_LOCATION_POLICY, components should be available for GIOP to use. Even if these components are not sufficient, some other solution for optimization of object location should be adopted. Therefore, we'd rather leave this issue open for the next RTF rather than close it with no action. On 1588, our YES vote is contingent on only the note being added, and not the Encapsulation typedef, since we haven't seen actual text incorporating the typedef into existing component definitions. Our understanding of the IIOPFirewallRFP item is that only chapter 5 of orbos/98-07-03 is being incorporated, and nothing firewall specific. Chapter 5 defines a ServiceContext that is used to negotiate the ability to use the same connection for both client and server roles, and a Policy passed to create_POA() to enable this. Finally, has vote 2 been issued? If so, could someone forward me a copy? Thanks, -Bob Return-Path: Sender: jon@floorboard.com Date: Mon, 20 Jul 1998 15:04:17 -0700 From: Jonathan Biggar To: interop@omg.org Subject: Proposal for Issue 1303 for consideration on Thursday's CC Here is the proposal to add support for TAG_ENDPOINT_ID_POSITION and TAG_LOCATE_POLICY to IIOP. I have extracted the text from the DCE-CIOP protocol description and rewritten all DCE specific stuff in terms of IIOP. ------------------------------------------------------------------------------- Copy the TAG_ENDPOINT_ID_POSITION, TAG_LOCATION_POLICY, EndPointIdPositionComponent, LOCATE_NEVER, LOCATE_OBJECT, LOCATE_OPERATION, and LOCATE_ALWAYS definitions from the DCE_CIOP module (in section 14.7) and add them to the IIOP module (section 13.8.2). ------------------------------------------------------------------------------- Add the following to the end of section 13.7.3: An optional endpoint ID position component can be included in IOR profiles to enable client ORBs to minimize resource utilization and to avoid redundant locate messages. It can be used by other protocols besides IIOP. No more than one endpoint ID position component can be included in a profile. module IIOP { // IDL const ComponentId TAG_ENDPOINT_ID_POSITION = 6; struct EndpointIdPositionComponent { unsigned short begin; unsigned short end; }; }; An endpoint ID position component, identified by TAG_ENDPOINT_ID_POSITION, indicates the portion of the profile's object key that identifies the endpoint at which operations on an object can be invoked. The component_data is a CDR encapsulation of an EndpointIdPositionComponent structure. The begin member of this structure specifies the index in the object key of the first octet of the endpoint ID. The end member specifies the index of the last octet of the endpoint ID. An index value of zero specifies the first octet of the object key. The value of end must be greater than the value of begin, but less than the total number of octets in the object key. The endpoint ID is made up of the octets located between these two indices inclusively. The endpoint ID should be unique within the domain of interoperability. When a client has an object with the same host, port and endpoint ID as another object which is already bound to an IIOP connection, then the client can use that IIOP connection to send requests for the new object. The client must still be prepared to handle forwarding responses. An optional location policy component can be included in IOR profiles to specify when a client should send a LocateRequest message before attempting to send a Request message. It can be used by other protocols besides IIOP. No more than one location policy component should be included in a profile. module IIOP { // IDL const ComponentId TAG_LOCATION_POLICY = 12; // IDL does not support octet constants #define LOCATE_NEVER 0 #define LOCATE_OBJECT 1 #define LOCATE_OPERATION 2 #define LOCATE_ALWAYS 3 }; A TaggedComponent structure for a location policy component is built by setting the tag member to TAG_LOCATION_POLICY and setting the component_data member to a sequence containing a single octet, whose value is LOCATE_NEVER, LOCATE_OBJECT, LOCATE_OPERATION, or LOCATE_ALWAYS. If a location policy component is not present in a profile, the client should assume a location policy of LOCATE_OBJECT. A client should interpret the location policy as follows: o LOCATE_NEVER - Always send a Request message, never send a LocateRequest. o LOCATE_OBJECT - Send a LocateRequest message when the first invocation is performed on the object. o LOCATE_OPERATION - Send a LocateRequest message for each distinct operation on the object. This policy can be used when different methods of an object are located in different processes. o LOCATE_ALWAYS - Send a LocateRequest message before each invocation on the object. This policy can be used to support server-per-method activation. The location policy is a hint that enables a client to avoid sending unnecessary LocateRequest messages and to avoid Request messages that return LOCATION_FORWARD status. It is not needed to provide correct semantics, and can be ignored. Even when this hint is utilized, an Request message might result in an LOCATION_FORWARD response. A client does not need to implement all location policies to make use of this hint. A location policy with a higher value can be substituted for one with a lower value. For instance, a client might treat LOCATE_OPERATION as LOCATE_ALWAYS to avoid having to keep track of binding information for each operation on an object. When combined with an endpoint ID component, a location policy of LOCATE_OBJECT indicates that the client should send a LocateRequest message for the first object with a particular endpoint ID, and then just send a Request message for other objects with the same endpoint ID. When a location policy of LOCATE_NEVER is combined with an endpoint ID component, only Request messages need be sent. The LOCATE_ALWAYS and LOCATE_OPERATION policies should not be combined with an endpoint ID component in a profile. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org x