Issue 2803: Support of some form of correlation identification is needed (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Severity: Summary: 2. There is a lack in providing support for correlating requests and replies in the case of TII. Support of some form of correlation identification is needed. Resolution: resolved Revised Text: a) -------------------------------------------------------------- The following changes are referring to document ptc/00-02-05. p. 1-26, change "1.3.6 Type-Specific Poller Mapping The polling model requires usage of generated type-specific Poller values.A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds private state that allows the response to be obtained from a client other than the client that made the request. This private state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." to read " 1.3.6 Type-Specific Poller Mapping The polling model requires usage of generated type-specific Poller values. A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds public state and initializers that allows the response to be obtained from a client other than the client that made the request. This public state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." p. 1-28, change "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: value AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { MessageRouting::PersistentRequest outstanding_request; }; Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." to read "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used by the messaging-aware ORB. It is also made directly accessible to the application such that it can be used to save it in a persistent store and initialize PersistentPoller values in a different client. The generated PersistentPoller value type is derived from the basic one. It adds no methods, only one piece of public state and an initializer. For an interface named ifaceName the following PersistentPoller is generated: valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { public MessageRouting::PersistentRequest outstanding_request; factory init(in MessageRouting::PersistentRequest outstanding_request); }; This PersistentPoller can be instantiated by the application by providing the value of the outstanding_request state member of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." p. 1-99, change "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." to read "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is specified to allow client applications to save it in a persistent store and to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability," on page 1-44. b) -------------------------------------------------------------- The following changes are referring to document ptc/00-02-05. p. 1-24, 1-25 change "The Poller has the following definition: module Messaging { valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; };" to read "The Poller has the following definition: module Messaging { typedef string CorrelationId; valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; readonly attribute CorrelationId id; Object target; string op_name; }; };" p. 1-25, add after the paragraph 'is_from_poller' "id A correlation id for the request is accessible from any poller. The returned string is of opaque content. Non-TII applications may only use it for comparison: the correlation id for two pollers are the same if and only if the pollers refer to the same original request. When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of a special poller subtype is returned from such invocations. The instance contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. However, the correlation id attribute provides the applications access to this state in a stringified form. This allows the state to be stored in a persistent store and later use it for initializing an equivalent poller in the client that will poll the reply." p. 1-18, change "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: value AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { MessageRouting::PersistentRequest outstanding_request; }; Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." to read "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state and an initialier. For an interface named ifaceName the following PersistentPoller is generated: valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { private MessageRouting::PersistentRequest outstanding_request; factory init(in Messaging::CorrelationId id); }; This PersistentPoller can be instantiated by the application by providing the value of the correlation id attribute of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." p. 1-67, change " // // Base value for the Polling model // valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; " to read " // // Base value for the Polling model // typedef string CorrelationId; valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; readonly attribute CorrelationId id; Object target; string op_name; }; " p. 1-99, change "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the originalinvoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." to read "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." Actions taken: July 14, 1999: received issue January 9, 2001: closed issue Discussion: a) - the generated, persistent type-specific pollers have a private state member of type MessageRouting::PersistentRequest; change it to public access - introduce initializers on the persistent type-specific pollers b) - define correlation id as a string of opaque content - introduce a correlation id attribute on CORBA::Poller - introduce initializers on persistent type-specific pollers c) - Close this issue Proposed Resolutions a) -------------------------------------------------------------- The following changes are referring to document ptc/00-02-05. p. 1-26, change "1.3.6 Type-Specific Poller Mapping The polling model requires usage of generated type-specific Poller values.A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds private state that allows the response to be obtained from a client other than the client that made the request. This private state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." to read " 1.3.6 Type-Specific Poller Mapping The polling model requires usage of generated type-specific Poller values. A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds public state and initializers that allows the response to be obtained from a client other than the client that made the request. This public state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." p. 1-28, change "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: value AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { MessageRouting::PersistentRequest outstanding_request; }; Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." to read "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used by the messaging-aware ORB. It is also made directly accessible to the application such that it can be used to save it in a persistent store and initialize PersistentPoller values in a different client. The generated PersistentPoller value type is derived from the basic one. It adds no methods, only one piece of public state and an initializer. For an interface named ifaceName the following PersistentPoller is generated: valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { public MessageRouting::PersistentRequest outstanding_request; factory init(in MessageRouting::PersistentRequest outstanding_request); }; This PersistentPoller can be instantiated by the application by providing the value of the outstanding_request state member of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." p. 1-99, change "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." to read "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is specified to allow client applications to save it in a persistent store and to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability," on page 1-44. b) -------------------------------------------------------------- The following changes are referring to document ptc/00-02-05. p. 1-24, 1-25 change "The Poller has the following definition: module Messaging { valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; };" to read "The Poller has the following definition: module Messaging { typedef string CorrelationId; valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; readonly attribute CorrelationId id; Object target; string op_name; }; };" p. 1-25, add after the paragraph 'is_from_poller' "id A correlation id for the request is accessible from any poller. The returned string is of opaque content. Non-TII applications may only use it for comparison: the correlation id for two pollers are the same if and only if the pollers refer to the same original request. When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of a special poller subtype is returned from such invocations. The instance contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. However, the correlation id attribute provides the applications access to this state in a stringified form. This allows the state to be stored in a persistent store and later use it for initializing an equivalent poller in the client that will poll the reply." p. 1-18, change "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: value AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { MessageRouting::PersistentRequest outstanding_request; }; Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." to read "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state and an initialier. For an interface named ifaceName the following PersistentPoller is generated: valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { private MessageRouting::PersistentRequest outstanding_request; factory init(in Messaging::CorrelationId id); }; This PersistentPoller can be instantiated by the application by providing the value of the correlation id attribute of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." p. 1-67, change " // // Base value for the Polling model // valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; " to read " // // Base value for the Polling model // typedef string CorrelationId; valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; readonly attribute CorrelationId id; Object target; string op_name; }; " p. 1-99, change "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the originalinvoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." to read "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4, "Message Routing Interoperability", on page 1-44." End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 9 Mar 2000 14:28:57 +0100 Message-Id: Subject: 2803: Requirement for Correlation Id MIME-Version: 1.0 TO: messaging-rtf@omg.org, uabcsru@uab.ericsson.se Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 9 Mar 2000 14:28:57 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 9 Mar 2000 14:28:57 +0100" X-UIDL: b)9e9C1-e9b50!!<,He9 >From Proposed Resolutions for Vote 1. Draft 1 - 25th February 2000: > >Issue 2803: Support of some form of correlation identification is needed (messaging-rtf) > >Summary: 2. There is a lack in providing support for correlating requests and replies in >the case of TII. Support of some form of correlation identification is needed. > >Proposed Resolution >The issue of having request identifiers was discussed long and hard in the original >submission team, and the current solution was the result of a tough compromise. In the >case of TII, one still has a single Poller per request sent and so correlation is not >difficult in this case. For the TII callbacks, it was envisioned that one would have >separate callback object references for each request, so that correlation could be >achieved in this way, and perhaps use the POA to have a single servant or even >activated-on-demand servants for these callback object references. >Close this issue. Could someone please explain to me what the compromise is, ie. what is the trade off for not having correlation ids? Here is why I think that there is a "hard" requirement for correlation ids in the case of TII: (1) A first program sends an asynchronous request and gets back a poller. The poller must contain all the necessary information for retrieving the reply to this request. With TII it must be possible to store this information somewhere to a persistent store such that a different program can later reconstruct an equivalent poller from this information in order to retrieve the reply. -> How can the information in the poller be stored to a persistent store? -> How can an equivalent poller be constructed from this information? Note that the target objref and the operation name on the generic Poller valuetype is not enough information to correlate requests and replies. A TII implementation must maintain internally more correlation information. -> When the poller supports a correlation id attribute the above scenario is easy: the first program queries the poller for the value of the correlation id that could be implemented as a string of implementation-specific content. It then writes the string to a persistent store. The second program then instantiates a poller and sets the correlation id attribute. This poller then can be used to retrieve the desired reply. (2) There can be multiple poller instances that refer to the same reply, e.g. replies are retrieved from a different process than the sending one. But there could also be scenarios where multiple poller instances refering to the same request exist within the same process, e.g. the retrieving applications could simply instantiate multiple times an equivalent poller in different places of the program e.g. in order to compare an earlier instantiated poller to poller information externalized to a persistent store. Therefore there is a need that to poller instances can be compared to be equivalent. -> When the poller supports a correlation id attribute comparison is easy: just compare the value of the correlation id attribute. (3) With TII callbacks, as pointed out in the quoted text above, it is possible to "correlate" requests to replies when the application uses a separate callback object for each request. This works, but is quite awkward (correlation is not supported by the middleware, but has to be done by the application). If the middlware supports a correlation id, this would be much more useful to the applications: -> When the poller supports a correlation id attribute and the callback methods support a correlation id attribute, sendp could be used to send the requests (sendp is already the general form which allows to delay the decision whether replies are retrieved by polling or by callback) and query the correlation id. This value could then be compared to the correlation id received on callbacks. I can't see how (1) can be done based on the current specs, thus I think there is really a defect with the specs here and this is the "hard" requirement for some form of correlation mechanism. (2) could also be resolved by extending the poller by a comparison operation. (3) can already be done. Introducing a correlation id attribute on the generic Poller valuetype is small intervention which should not break any exsiting code and which should be easy implementable as current CORBA Messaging implementation have to maintain internally already now the necessary correlation information. This would solve (1) and (2). (3) would obviously be a major intervention as the signature of the callback methods changes. I think at least (1) and (2) should be solved. I'm also in favor of (3) but I don't now how much other people are worried about backward compatibility (old signatures could be required for backward compatibility). Should I write a straw man for this, or are there any voices completely opposed to the above exposure? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Sender: Chris.Smith@uab.ericsson.se Message-ID: <38C7AFBC.2A87B2AB@uab.ericsson.se> Date: Thu, 09 Mar 2000 15:05:48 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: 2803: Requirement for Correlation Id References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m?O!!fHh!!)$pd93Po!! I'm not an expert on the Message Routing TII bits, but this is how I thought it was supposed to work. When using TII, one MUST use a Persistent Type-Specific Poller (see p1-28 of latest draft) "When Time-Indeppendant Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generate PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state........" Thus, if client A issues a TII request with sendp, he gets a PersistentPoller, which can be sent over CORBA to client B and client B can then use it to get the reply. Isnt it like that? Cheers Chris hans.kneubuehl@ubs.com wrote: > > From Proposed Resolutions for Vote 1. Draft 1 - 25th February 2000: > > > >Issue 2803: Support of some form of correlation identification is > needed > (messaging-rtf) > > > >Summary: 2. There is a lack in providing support for correlating > requests and > replies in > >the case of TII. Support of some form of correlation identification > is needed. > > > >Proposed Resolution > >The issue of having request identifiers was discussed long and hard > in the > original > >submission team, and the current solution was the result of a tough > compromise. In the > >case of TII, one still has a single Poller per request sent and so > correlation > is not > >difficult in this case. For the TII callbacks, it was envisioned > that one > would have > >separate callback object references for each request, so that > correlation > could be > >achieved in this way, and perhaps use the POA to have a single > servant or even > >activated-on-demand servants for these callback object references. > >Close this issue. > > Could someone please explain to me what the compromise is, ie. what > is the > trade off for not having correlation ids? > > Here is why I think that there is a "hard" requirement for > correlation ids in > the case of TII: > > (1) A first program sends an asynchronous request and gets back a > poller. The > poller must contain all the necessary information for retrieving the > reply to > this request. With TII it must be possible to store this information > somewhere > to a persistent store such that a different program can later > reconstruct an > equivalent poller from this information in order to retrieve the > reply. > > -> How can the information in the poller be stored to a persistent > store? > -> How can an equivalent poller be constructed from this > information? > > Note that the target objref and the operation name on the generic > Poller > valuetype is not enough information to correlate requests and > replies. A TII > implementation must maintain internally more correlation > information. > > -> When the poller supports a correlation id attribute the above > scenario is > easy: the first program queries the poller for the value of the > correlation id > that could be implemented as a string of implementation-specific > content. It > then writes the string to a persistent store. The second program > then > instantiates a poller and sets the correlation id attribute. This > poller then > can be used to retrieve the desired reply. > > (2) There can be multiple poller instances that refer to the same > reply, e.g. > replies are retrieved from a different process than the sending > one. But there > could also be scenarios where multiple poller instances refering to > the same > request exist within the same process, e.g. the retrieving > applications could > simply instantiate multiple times an equivalent poller in different > places of > the program e.g. in order to compare an earlier instantiated poller > to poller > information externalized to a persistent store. Therefore there is a > need that > to poller instances can be compared to be equivalent. > > -> When the poller supports a correlation id attribute > comparison is easy: > just compare the value of the correlation id attribute. > > (3) With TII callbacks, as pointed out in the quoted text above, it > is possible > to "correlate" requests to replies when the application uses a > separate > callback object for each request. This works, but is quite awkward > (correlation > is not supported by the middleware, but has to be done by the > application). If > the middlware supports a correlation id, this would be much more > useful to the > applications: > > -> When the poller supports a correlation id attribute and the > callback > methods support a correlation id attribute, sendp could be used to > send the > requests (sendp is already the general form which allows to delay > the decision > whether replies are retrieved by polling or by callback) and query > the > correlation id. This value could then be compared to the correlation > id > received on callbacks. > > I can't see how (1) can be done based on the current specs, thus I > think there > is really a defect with the specs here and this is the "hard" > requirement for > some form of correlation mechanism. (2) could also be resolved by > extending the > poller by a comparison operation. (3) can already be done. > > Introducing a correlation id attribute on the generic Poller > valuetype is small > intervention which should not break any exsiting code and which > should be easy > implementable as current CORBA Messaging implementation have to > maintain > internally already now the necessary correlation information. This > would solve > (1) and (2). (3) would obviously be a major intervention as the > signature of > the callback methods changes. > > I think at least (1) and (2) should be solved. I'm also in favor of > (3) but I > don't now how much other people are worried about backward > compatibility (old > signatures could be required for backward compatibility). > > Should I write a straw man for this, or are there any voices > completely opposed > to the above exposure? > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 9 Mar 2000 16:00:14 +0100 Message-Id: Subject: Re: 2803: Requirement for Correlation Id MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 9 Mar 2000 16:00:14 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 9 Mar 2000 16:00:14 +0100" X-UIDL: X#ed9(dP!!=+&e9S,(!! True. Thanks. I forgot to relate my issues with persistent pollers... TII works with persistent pollers which have an additional private state member of type objref representing the outstanding reply. The state member is called 'outstanding_request'. Clearly, 'outstanding_request' corresponds to the correlation information that I was saying that a TII-ORB has to maintain internally. However, this doesn't really solve the points I brought up because this state is not accessible to the application. p. 1-28: "The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application." I agree that this solves the problem where client A sends the persistent poller over CORBA to client B doing the retrieval. However, that scenario is rather the exception with TII. TII must also work if the client A stops before client B is started. For example, you use CORBA Messaging to send a long-during query, you stop the application, go home, and expect to be able to retrieve the reply on the next day. Also, you might want to store the correlation information as part of the same transaction as when sending the request and remove the correlation information as part of the same transaction as retrieving the reply, such that you can guarantee that all replies will be retrieved. Thus, the "hard" requirement is really how the application can store all the necessary correlation information from a persistent poller into a persistent store and reconstruct an equivalent poller out of this. To my knowledge, there is no such thing as an object_to_string and string_to_object for valuetypes. Certainly, there are different variants how this could be solved: (a) one is the correlation id I proposed (b) another one would be to make the outstanding_request member accessible to the application such that it can do an object_to_string to it and store it in a persistent store (a) provides a more "service-oriented" view to the application whilst (b) reveals the internals. (b) would also solve my point (2), comparision of pollers. Thanks again. Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > -----Original Message----- > From: uabcsru [mailto:uabcsru@uab.ericsson.se] > Sent: Thursday, March 09, 2000 3:06 PM > To: Hans z.h.k.k.8. Kneubuehl > Cc: uabcsru; messaging-rtf > Subject: UNAUTHENTICATED: Re: 2803: Requirement for Correlation Id > > > I'm not an expert on the Message Routing TII bits, > but this is how I thought it was supposed to work. > > When using TII, one MUST use a Persistent Type-Specific > Poller (see p1-28 of latest draft) > > "When Time-Indeppendant Invocations are made, the reply > may be obtained by a different client than the one that > made the original request. An instance of persistent > poller is returned from such invocations. The PersistentPoller > contains the state necessary to allow polling to be performed > in a client distinct from the one that made the request. > This state is used privately by the messaging-aware ORB and > is not directly accessible to the application. > > The generate PersistentPoller value is derived from the > basic one. It adds no methods, only one piece of private > state........" > > Thus, if client A issues a TII request with sendp, he gets > a PersistentPoller, which can be sent over CORBA to > client B and client B can then use it to get the reply. > > Isnt it like that? > > > Cheers > > Chris > > > > > > > > hans.kneubuehl@ubs.com wrote: > > > > From Proposed Resolutions for Vote 1. Draft 1 - 25th February > 2000: > > > > > >Issue 2803: Support of some form of correlation > identification is needed > > (messaging-rtf) > > > > > >Summary: 2. There is a lack in providing support for > correlating requests and > > replies in > > >the case of TII. Support of some form of correlation > identification is needed. > > > > > >Proposed Resolution > > >The issue of having request identifiers was discussed long > and hard in the > > original > > >submission team, and the current solution was the result of a > tough > > compromise. In the > > >case of TII, one still has a single Poller per request > sent and so correlation > > is not > > >difficult in this case. For the TII callbacks, it was > envisioned that one > > would have > > >separate callback object references for each request, so > that correlation > > could be > > >achieved in this way, and perhaps use the POA to have a > single servant or even > > >activated-on-demand servants for these callback object > references. > > >Close this issue. > > > > Could someone please explain to me what the compromise is, > ie. what is the > > trade off for not having correlation ids? > > > > Here is why I think that there is a "hard" requirement for > correlation ids in > > the case of TII: > > > > (1) A first program sends an asynchronous request and gets > back a poller. The > > poller must contain all the necessary information for > retrieving the reply to > > this request. With TII it must be possible to store this > information somewhere > > to a persistent store such that a different program can > later reconstruct an > > equivalent poller from this information in order to > retrieve the reply. > > > > -> How can the information in the poller be stored to a > persistent store? > > -> How can an equivalent poller be constructed from this > information? > > > > Note that the target objref and the operation name on the > generic Poller > > valuetype is not enough information to correlate requests > and replies. A TII > > implementation must maintain internally more correlation > information. > > > > -> When the poller supports a correlation id attribute > the above scenario is > > easy: the first program queries the poller for the value of > the correlation id > > that could be implemented as a string of > implementation-specific content. It > > then writes the string to a persistent store. The second > program then > > instantiates a poller and sets the correlation id > attribute. This poller then > > can be used to retrieve the desired reply. > > > > (2) There can be multiple poller instances that refer to > the same reply, e.g. > > replies are retrieved from a different process than the > sending one. But there > > could also be scenarios where multiple poller instances > refering to the same > > request exist within the same process, e.g. the retrieving > applications could > > simply instantiate multiple times an equivalent poller in > different places of > > the program e.g. in order to compare an earlier > instantiated poller to poller > > information externalized to a persistent store. Therefore > there is a need that > > to poller instances can be compared to be equivalent. > > > > -> When the poller supports a correlation id attribute > comparison is easy: > > just compare the value of the correlation id attribute. > > > > (3) With TII callbacks, as pointed out in the quoted text > above, it is possible > > to "correlate" requests to replies when the application > uses a separate > > callback object for each request. This works, but is quite > awkward (correlation > > is not supported by the middleware, but has to be done by > the application). If > > the middlware supports a correlation id, this would be much > more useful to the > > applications: > > > > -> When the poller supports a correlation id attribute > and the callback > > methods support a correlation id attribute, sendp could be > used to send the > > requests (sendp is already the general form which allows to > delay the decision > > whether replies are retrieved by polling or by callback) > and query the > > correlation id. This value could then be compared to the > correlation id > > received on callbacks. > > > > I can't see how (1) can be done based on the current specs, > thus I think there > > is really a defect with the specs here and this is the > "hard" requirement for > > some form of correlation mechanism. (2) could also be > resolved by extending the > > poller by a comparison operation. (3) can already be done. > > > > Introducing a correlation id attribute on the generic > Poller valuetype is small > > intervention which should not break any exsiting code and > which should be easy > > implementable as current CORBA Messaging implementation > have to maintain > > internally already now the necessary correlation > information. This would solve > > (1) and (2). (3) would obviously be a major intervention as > the signature of > > the callback methods changes. > > > > I think at least (1) and (2) should be solved. I'm also in > favor of (3) but I > > don't now how much other people are worried about backward > compatibility (old > > signatures could be required for backward compatibility). > > > > Should I write a straw man for this, or are there any > voices completely opposed > > to the above exposure? > > > > Regards > > Hans > > -- > > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > From: KNAPMAN@uk.ibm.com X-Lotus-FromDomain: IBMGB To: messaging-rtf@omg.org Message-ID: <8025689D.007C3250.00@d06mta10.portsmouth.uk.ibm.com> Date: Thu, 9 Mar 2000 22:23:00 +0000 Subject: Re: 2803: Requirement for Correlation Id Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 5;;!!~8gd96iI!!MTp!! I do agree with Hans. I really can't see now TII is practical if the user has to save and interrogate poller objects for every outstanding request. There are applications where dozens of requests can be outstanding for extended periods and the replies don't come in the order in which the requests were made. I thought that the compromise was to place all the outstanding poller objects into a pollable set. I don't think this was specified fully in the end, but the idea was to be that you could interrogate the set and receive the poller object that matched whatever incoming reply happened to arrive. In effect, the pollable set acts as a store for the expected replies, so each poller object in the set represents the correlation id of an outstanding request. This isn't as simple as correlation IDs, but it seemed to satisfy the purists. John Knapman Dr J M Knapman, MQSeries Technical Strategy, IBM, Hursley, UK Telephone: +44-1962-818381; fax: +44-1962-818338 Notes: John Knapman@IBMGB; internet: knapman@uk.ibm.com hans.kneubuehl@ubs.com on 03/09/2000 01:28:57 PM Please respond to hans.kneubuehl@ubs.com To: messaging-rtf@omg.org, uabcsru@uab.ericsson.se cc: (bcc: John Knapman/UK/IBM) Subject: 2803: Requirement for Correlation Id >From Proposed Resolutions for Vote 1. Draft 1 - 25th February 2000: > >Issue 2803: Support of some form of correlation identification is needed (messaging-rtf) > >Summary: 2. There is a lack in providing support for correlating requests and replies in >the case of TII. Support of some form of correlation identification is needed. > >Proposed Resolution >The issue of having request identifiers was discussed long and hard in the original >submission team, and the current solution was the result of a tough compromise. In the >case of TII, one still has a single Poller per request sent and so correlation is not >difficult in this case. For the TII callbacks, it was envisioned that one would have >separate callback object references for each request, so that correlation could be >achieved in this way, and perhaps use the POA to have a single servant or even >activated-on-demand servants for these callback object references. >Close this issue. Could someone please explain to me what the compromise is, ie. what is the trade off for not having correlation ids? Here is why I think that there is a "hard" requirement for correlation ids in the case of TII: (1) A first program sends an asynchronous request and gets back a poller. The poller must contain all the necessary information for retrieving the reply to this request. With TII it must be possible to store this information somewhere to a persistent store such that a different program can later reconstruct an equivalent poller from this information in order to retrieve the reply. -> How can the information in the poller be stored to a persistent store? -> How can an equivalent poller be constructed from this information? Note that the target objref and the operation name on the generic Poller valuetype is not enough information to correlate requests and replies. A TII implementation must maintain internally more correlation information. -> When the poller supports a correlation id attribute the above scenario is easy: the first program queries the poller for the value of the correlation id that could be implemented as a string of implementation-specific content. It then writes the string to a persistent store. The second program then instantiates a poller and sets the correlation id attribute. This poller then can be used to retrieve the desired reply. (2) There can be multiple poller instances that refer to the same reply, e.g. replies are retrieved from a different process than the sending one. But there could also be scenarios where multiple poller instances refering to the same request exist within the same process, e.g. the retrieving applications could simply instantiate multiple times an equivalent poller in different places of the program e.g. in order to compare an earlier instantiated poller to poller information externalized to a persistent store. Therefore there is a need that to poller instances can be compared to be equivalent. -> When the poller supports a correlation id attribute comparison is easy: just compare the value of the correlation id attribute. (3) With TII callbacks, as pointed out in the quoted text above, it is possible to "correlate" requests to replies when the application uses a separate callback object for each request. This works, but is quite awkward (correlation is not supported by the middleware, but has to be done by the application). If the middlware supports a correlation id, this would be much more useful to the applications: -> When the poller supports a correlation id attribute and the callback methods support a correlation id attribute, sendp could be used to send the requests (sendp is already the general form which allows to delay the decision whether replies are retrieved by polling or by callback) and query the correlation id. This value could then be compared to the correlation id received on callbacks. I can't see how (1) can be done based on the current specs, thus I think there is really a defect with the specs here and this is the "hard" requirement for some form of correlation mechanism. (2) could also be resolved by extending the poller by a comparison operation. (3) can already be done. Introducing a correlation id attribute on the generic Poller valuetype is small intervention which should not break any exsiting code and which should be easy implementable as current CORBA Messaging implementation have to maintain internally already now the necessary correlation information. This would solve (1) and (2). (3) would obviously be a major intervention as the signature of the callback methods changes. I think at least (1) and (2) should be solved. I'm also in favor of (3) but I don't now how much other people are worried about backward compatibility (old signatures could be required for backward compatibility). Should I write a straw man for this, or are there any voices completely opposed to the above exposure? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 10 Mar 2000 11:58:18 +0100 Message-Id: Subject: Re: 2803: Requirement for Correlation Id MIME-Version: 1.0 TO: KNAPMAN@uk.ibm.com, messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 10 Mar 2000 11:58:18 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 10 Mar 2000 11:58:18 +0100" X-UIDL: 'P[d9iHb!!$_`d9MF&e9 > -----Original Message----- > From: KNAPMAN [mailto:KNAPMAN@uk.ibm.com] > Sent: Thursday, March 09, 2000 11:23 PM > To: messaging-rtf > Cc: KNAPMAN > Subject: Re: 2803: Requirement for Correlation Id > > > > > I do agree with Hans. :-) > I really can't see now TII is > practical if the user > has to save and interrogate poller objects for every > outstanding request. Hmm. I think that you are more refering to issue 2802 (Polling by Objref and Operation Name) here. Although, 2802 and 2803 are somehow related, I tried to differentiate them: - 2802: How you can poll just the next available reply from a certain target object? - 2803: How can I pass a poller from the sending client to the polling client by a persistent store, e.g. because the sending client is already terminated when the polling client is started or simply for recoverability reasons in case of failures? How can two poller instances be compared whether they refer to the same outstanding reply. > There are applications where dozens of requests can be outstanding for > extended periods and the replies don't come in the order in which the > requests were made. I thought that the compromise was to > place all the > outstanding poller objects into a pollable set. I don't > think this was > specified fully in the end, but the idea was to be that you could > interrogate the set and receive the poller object that > matched whatever > incoming reply happened to arrive. In effect, the pollable > set acts as a > store for the expected replies, so each poller object in the > set represents > the correlation id of an outstanding request. Yes, pollable sets are specified in - chapt. 9.3.4.3 of orbos/98-05-05 (original submission), or in - chapt. 7.4 of ptc/99-12-02 (draft for new CORBA core) They offer the functionality to do an is-ready call (called 'CORBA::PollableSet::poll') on a set of pollers. The is-ready call will return with a poller that represents an outstanding reply ready to retrieve. Clearly, pollable sets are very useful, if you have a clearly defined set of outsanding replies, however they don't solve 2803 (see above) and they are very awkward to use if you want to retrieve a continuous stream of replies (issue 2802). > This isn't as simple as correlation IDs, but it seemed to satisfy the > purists. Ok, that is one alternative: the poller itself is the objectification of a correlation id and extend the poller such that you can compare them and store them temporarily to a persistent store. A better and simpler alternative is - define the correlation id as a string of opaque content - to look at the poller, as the name suggests, as a retriever object. As already mentioned (issue 2802) there are requirements for retrieving objects by other means than a correlation id and you can even think of supporting different kinds of filters for retrieving replies in the future (see also JMS). Thus even from a purist point of view, I would rather make a difference between pollers and correlation ids. Thanks and regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > John Knapman > > Dr J M Knapman, MQSeries Technical Strategy, IBM, Hursley, UK > Telephone: +44-1962-818381; fax: +44-1962-818338 > Notes: John Knapman@IBMGB; internet: knapman@uk.ibm.com > > > hans.kneubuehl@ubs.com on 03/09/2000 01:28:57 PM > > Please respond to hans.kneubuehl@ubs.com > > To: messaging-rtf@omg.org, uabcsru@uab.ericsson.se > cc: (bcc: John Knapman/UK/IBM) > Subject: 2803: Requirement for Correlation Id > > > > > From Proposed Resolutions for Vote 1. Draft 1 - 25th February 2000: > > > >Issue 2803: Support of some form of correlation > identification is needed > (messaging-rtf) > > > >Summary: 2. There is a lack in providing support for > correlating requests > and > replies in > >the case of TII. Support of some form of correlation > identification is > needed. > > > >Proposed Resolution > >The issue of having request identifiers was discussed long > and hard in the > original > >submission team, and the current solution was the result of a tough > compromise. In the > >case of TII, one still has a single Poller per request sent and so > correlation > is not > >difficult in this case. For the TII callbacks, it was > envisioned that one > would have > >separate callback object references for each request, so > that correlation > could be > >achieved in this way, and perhaps use the POA to have a > single servant or > even > >activated-on-demand servants for these callback object references. > >Close this issue. > > Could someone please explain to me what the compromise is, > ie. what is the > trade off for not having correlation ids? > > Here is why I think that there is a "hard" requirement for > correlation ids > in > the case of TII: > > (1) A first program sends an asynchronous request and gets > back a poller. > The > poller must contain all the necessary information for > retrieving the reply > to > this request. With TII it must be possible to store this information > somewhere > to a persistent store such that a different program can later > reconstruct > an > equivalent poller from this information in order to retrieve > the reply. > > -> How can the information in the poller be stored to a > persistent store? > -> How can an equivalent poller be constructed from this > information? > > Note that the target objref and the operation name on the > generic Poller > valuetype is not enough information to correlate requests and > replies. A > TII > implementation must maintain internally more correlation > information. > > -> When the poller supports a correlation id attribute the above > scenario is > easy: the first program queries the poller for the value of > the correlation > id > that could be implemented as a string of > implementation-specific content. > It > then writes the string to a persistent store. The second program > then > instantiates a poller and sets the correlation id attribute. > This poller > then > can be used to retrieve the desired reply. > > (2) There can be multiple poller instances that refer to the > same reply, > e.g. > replies are retrieved from a different process than the > sending one. But > there > could also be scenarios where multiple poller instances > refering to the > same > request exist within the same process, e.g. the retrieving > applications > could > simply instantiate multiple times an equivalent poller in > different places > of > the program e.g. in order to compare an earlier instantiated poller > to > poller > information externalized to a persistent store. Therefore > there is a need > that > to poller instances can be compared to be equivalent. > > -> When the poller supports a correlation id attribute > comparison is > easy: > just compare the value of the correlation id attribute. > > (3) With TII callbacks, as pointed out in the quoted text above, it > is > possible > to "correlate" requests to replies when the application uses > a separate > callback object for each request. This works, but is quite awkward > (correlation > is not supported by the middleware, but has to be done by the > application). > If > the middlware supports a correlation id, this would be much > more useful to > the > applications: > > -> When the poller supports a correlation id attribute > and the callback > methods support a correlation id attribute, sendp could be > used to send the > requests (sendp is already the general form which allows to delay > the > decision > whether replies are retrieved by polling or by callback) and query > the > correlation id. This value could then be compared to the > correlation id > received on callbacks. > > I can't see how (1) can be done based on the current specs, > thus I think > there > is really a defect with the specs here and this is the "hard" > requirement > for > some form of correlation mechanism. (2) could also be > resolved by extending > the > poller by a comparison operation. (3) can already be done. > > Introducing a correlation id attribute on the generic Poller > valuetype is > small > intervention which should not break any exsiting code and > which should be > easy > implementable as current CORBA Messaging implementation have > to maintain > internally already now the necessary correlation information. > This would > solve > (1) and (2). (3) would obviously be a major intervention as > the signature > of > the callback methods changes. > > I think at least (1) and (2) should be solved. I'm also in > favor of (3) but > I > don't now how much other people are worried about backward > compatibility > (old > signatures could be required for backward compatibility). > > Should I write a straw man for this, or are there any voices > completely > opposed > to the above exposure? > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > Sender: Chris.Smith@uab.ericsson.se Message-ID: <38C8E08E.A1FCD1D7@uab.ericsson.se> Date: Fri, 10 Mar 2000 12:46:22 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: KNAPMAN@uk.ibm.com, messaging-rtf@omg.org Subject: Re: 2803: Requirement for Correlation Id References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Gm;!!IS^!!+L;e9i4Le9 > - 2802: How you can poll just the next available reply from a certain target > object? Cant you put the Pollers for a particular target object into a Pollable set? > - 2803: How can I pass a poller from the sending client to the polling client > by a persistent store, e.g. because the sending client is already terminated > when the polling client is started or simply for recoverability reasons in case > of failures? How can two poller instances be compared whether they refer to the > same outstanding reply. The original submitters didnt (I believe) attempt to satisfy the requirement to "externalize" a PersistentPoller which is what I believe you want. They supported passing a PersistentPoller from one place to another. I do not believe that exposing lots of ids and things to the application is the way to solve this. The only state that a PersistentPoller has is the object reference of the MessageRouting::PersistentRequest object that was created as a result of the TII request. We could make this accessible to the application, so that it could be object_to_string'd, but then you would still have the problem of creating a new PersistentPoller valueType somewhere else. Currently the application never creates pollers - they are created by the ORB - there may be an implication of changing this. > > > There are applications where dozens of requests can be outstanding > for > > extended periods and the replies don't come in the order in which > the > > requests were made. I thought that the compromise was to > > place all the > > outstanding poller objects into a pollable set. I don't > > think this was > > specified fully in the end, but the idea was to be that you could > > interrogate the set and receive the poller object that > > matched whatever > > incoming reply happened to arrive. In effect, the pollable > > set acts as a > > store for the expected replies, so each poller object in the > > set represents > > the correlation id of an outstanding request. > > Yes, pollable sets are specified in > > - chapt. 9.3.4.3 of orbos/98-05-05 (original submission), or in > - chapt. 7.4 of ptc/99-12-02 (draft for new CORBA core) > > They offer the functionality to do an is-ready call (called > 'CORBA::PollableSet::poll') on a set of pollers. The is-ready call > will return > with a poller that represents an outstanding reply ready to > retrieve. > > Clearly, pollable sets are very useful, if you have a clearly > defined set of > outsanding replies, however they don't solve 2803 (see above) and > they are very > awkward to use if you want to retrieve a continuous stream of > replies (issue > 2802). > > > This isn't as simple as correlation IDs, but it seemed to satisfy > the > > purists. > > Ok, that is one alternative: the poller itself is the > objectification of a > correlation id and extend the poller such that you can compare them > and store > them temporarily to a persistent store. > > A better and simpler alternative is > - define the correlation id as a string of opaque content > - to look at the poller, as the name suggests, as a retriever > object. As > already mentioned (issue 2802) there are requirements for retrieving > objects by > other means than a correlation id and you can even think of > supporting > different kinds of filters for retrieving replies in the future (see > also JMS). > > Thus even from a purist point of view, I would rather make a > difference between > pollers and correlation ids. > > Thanks and regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > John Knapman > > > > Dr J M Knapman, MQSeries Technical Strategy, IBM, Hursley, UK > > Telephone: +44-1962-818381; fax: +44-1962-818338 > > Notes: John Knapman@IBMGB; internet: knapman@uk.ibm.com > > > > > > hans.kneubuehl@ubs.com on 03/09/2000 01:28:57 PM > > > > Please respond to hans.kneubuehl@ubs.com > > > > To: messaging-rtf@omg.org, uabcsru@uab.ericsson.se > > cc: (bcc: John Knapman/UK/IBM) > > Subject: 2803: Requirement for Correlation Id > > > > > > > > > > From Proposed Resolutions for Vote 1. Draft 1 - 25th February > 2000: > > > > > >Issue 2803: Support of some form of correlation > > identification is needed > > (messaging-rtf) > > > > > >Summary: 2. There is a lack in providing support for > > correlating requests > > and > > replies in > > >the case of TII. Support of some form of correlation > > identification is > > needed. > > > > > >Proposed Resolution > > >The issue of having request identifiers was discussed long > > and hard in the > > original > > >submission team, and the current solution was the result of a > tough > > compromise. In the > > >case of TII, one still has a single Poller per request sent and > so > > correlation > > is not > > >difficult in this case. For the TII callbacks, it was > > envisioned that one > > would have > > >separate callback object references for each request, so > > that correlation > > could be > > >achieved in this way, and perhaps use the POA to have a > > single servant or > > even > > >activated-on-demand servants for these callback object > references. > > >Close this issue. > > > > Could someone please explain to me what the compromise is, > > ie. what is the > > trade off for not having correlation ids? > > > > Here is why I think that there is a "hard" requirement for > > correlation ids > > in > > the case of TII: > > > > (1) A first program sends an asynchronous request and gets > > back a poller. > > The > > poller must contain all the necessary information for > > retrieving the reply > > to > > this request. With TII it must be possible to store this > information > > somewhere > > to a persistent store such that a different program can later > > reconstruct > > an > > equivalent poller from this information in order to retrieve > > the reply. > > > > -> How can the information in the poller be stored to a > > persistent store? > > -> How can an equivalent poller be constructed from this > > information? > > > > Note that the target objref and the operation name on the > > generic Poller > > valuetype is not enough information to correlate requests and > > replies. A > > TII > > implementation must maintain internally more correlation > information. > > > > -> When the poller supports a correlation id attribute the > above > > scenario is > > easy: the first program queries the poller for the value of > > the correlation > > id > > that could be implemented as a string of > > implementation-specific content. > > It > > then writes the string to a persistent store. The second program > then > > instantiates a poller and sets the correlation id attribute. > > This poller > > then > > can be used to retrieve the desired reply. > > > > (2) There can be multiple poller instances that refer to the > > same reply, > > e.g. > > replies are retrieved from a different process than the > > sending one. But > > there > > could also be scenarios where multiple poller instances > > refering to the > > same > > request exist within the same process, e.g. the retrieving > > applications > > could > > simply instantiate multiple times an equivalent poller in > > different places > > of > > the program e.g. in order to compare an earlier instantiated > poller to > > poller > > information externalized to a persistent store. Therefore > > there is a need > > that > > to poller instances can be compared to be equivalent. > > > > -> When the poller supports a correlation id attribute > > comparison is > > easy: > > just compare the value of the correlation id attribute. > > > > (3) With TII callbacks, as pointed out in the quoted text above, > it is > > possible > > to "correlate" requests to replies when the application uses > > a separate > > callback object for each request. This works, but is quite awkward > > (correlation > > is not supported by the middleware, but has to be done by the > > application). > > If > > the middlware supports a correlation id, this would be much > > more useful to > > the > > applications: > > > > -> When the poller supports a correlation id attribute > > and the callback > > methods support a correlation id attribute, sendp could be > > used to send the > > requests (sendp is already the general form which allows to delay > the > > decision > > whether replies are retrieved by polling or by callback) and query > the > > correlation id. This value could then be compared to the > > correlation id > > received on callbacks. > > > > I can't see how (1) can be done based on the current specs, > > thus I think > > there > > is really a defect with the specs here and this is the "hard" > > requirement > > for > > some form of correlation mechanism. (2) could also be > > resolved by extending > > the > > poller by a comparison operation. (3) can already be done. > > > > Introducing a correlation id attribute on the generic Poller > > valuetype is > > small > > intervention which should not break any exsiting code and > > which should be > > easy > > implementable as current CORBA Messaging implementation have > > to maintain > > internally already now the necessary correlation information. > > This would > > solve > > (1) and (2). (3) would obviously be a major intervention as > > the signature > > of > > the callback methods changes. > > > > I think at least (1) and (2) should be solved. I'm also in > > favor of (3) but > > I > > don't now how much other people are worried about backward > > compatibility > > (old > > signatures could be required for backward compatibility). > > > > Should I write a straw man for this, or are there any voices > > completely > > opposed > > to the above exposure? > > > > Regards > > Hans > > -- > > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > > > > > > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 10 Mar 2000 13:25:38 +0100 Message-Id: Subject: Re: 2803: Requirement for Correlation Id MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: KNAPMAN@uk.ibm.com, messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 10 Mar 2000 13:25:38 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 10 Mar 2000 13:25:38 +0100" X-UIDL: h]Z!!eG6!!eg%!!o43e9 > -----Original Message----- > From: uabcsru [mailto:uabcsru@uab.ericsson.se] > Sent: Friday, March 10, 2000 12:46 PM > To: Hans z.h.k.k.8. Kneubuehl > Cc: uabcsru; KNAPMAN; messaging-rtf > Subject: UNAUTHENTICATED: Re: 2803: Requirement for Correlation Id > > > > - 2802: How you can poll just the next available reply from > a certain target > > object? > > Cant you put the Pollers for a particular target object into a > Pollable set? > Our own implementation allows this. Of course, it doesn't make sense to put multiple pollers that refer to the same reply into a pollable set. But if, for example, you want to retrieve a stream of replies resulting form invocations of op1 on target1 and op2 on target2. The application then can just constantly initialize a pollable set with a poller for op1 on target1 and a poller for op2 on target2. > > - 2803: How can I pass a poller from the sending client to > the polling client > > by a persistent store, e.g. because the sending client is > already terminated > > when the polling client is started or simply for > recoverability reasons in case > > of failures? How can two poller instances be compared > whether they refer to the > > same outstanding reply. > > The original submitters didnt (I believe) attempt to satisfy the > requirement to "externalize" a PersistentPoller which is what > I believe you want. Yes, that's one point. Another is that I would like to compare pollers whether they refer to the same reply. I just had a look at the C++ PollableSet Example: There pollers are compared using is_equivalent, the comparision operation defined for objrefs. Thus, from the point of view of the original submitters, pollers could be compared and with the change for Pollable to an abstract valuetype we should make sure that pollers can still be compared. > They supported passing a PersistentPoller > from one place to another. I do not believe that exposing lots > of ids and things to the application is the way to solve this. > The only state that a PersistentPoller has is the object > reference of the MessageRouting::PersistentRequest object that > was created as a result of the TII request. We could make this > accessible to the application, so that it could be > object_to_string'd, I agree that this would be one solution, and I could perfectly live with it. Personally, however, I'm more in favor of the id variant, because with the object reference of the MessageRouting::PersistingRequest you are revealing something to the application that is ORB-internal. Maybe a compromise would be to have second PersistentRequest-Interface, which is basically empty and in the CORBA module instead of MessageRouting and then have MessageRouting::PersistentRequest inherit CORBA::PersistentRequest. Anyhow, I'm already pleased if there is at least a standard way which solves the requirement. > but then you would still have the problem > of creating a new PersistentPoller valueType somewhere else. > Currently the application never creates pollers - they are > created by the ORB - there may be an implication of changing this. Good point. In order to ensure portability, it would be necessary that CORBA Messaging defines initializers (ie. constructors). CORBA 2.3: "If no initializer are specified in IDL, the value type does not provide a portable way of creating a runtime instance of its type. There is no default initializer. This allows the definition of IDL value types which are not intended to be directly instantiated by client code." (Our implementation uses the default constructor, this is not portable, but currently does not matter because the extension is proprietary anyhow...) Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > > > > > There are applications where dozens of requests can be > outstanding for > > > extended periods and the replies don't come in the order > in which the > > > requests were made. I thought that the compromise was to > > > place all the > > > outstanding poller objects into a pollable set. I don't > > > think this was > > > specified fully in the end, but the idea was to be that you > could > > > interrogate the set and receive the poller object that > > > matched whatever > > > incoming reply happened to arrive. In effect, the pollable > > > set acts as a > > > store for the expected replies, so each poller object in the > > > set represents > > > the correlation id of an outstanding request. > > > > Yes, pollable sets are specified in > > > > - chapt. 9.3.4.3 of orbos/98-05-05 (original submission), or in > > - chapt. 7.4 of ptc/99-12-02 (draft for new CORBA core) > > > > They offer the functionality to do an is-ready call (called > > 'CORBA::PollableSet::poll') on a set of pollers. The > is-ready call will return > > with a poller that represents an outstanding reply ready to > retrieve. > > > > Clearly, pollable sets are very useful, if you have a > clearly defined set of > > outsanding replies, however they don't solve 2803 (see > above) and they are very > > awkward to use if you want to retrieve a continuous stream > of replies (issue > > 2802). > > > > > This isn't as simple as correlation IDs, but it seemed to > satisfy the > > > purists. > > > > Ok, that is one alternative: the poller itself is the > objectification of a > > correlation id and extend the poller such that you can > compare them and store > > them temporarily to a persistent store. > > > > A better and simpler alternative is > > - define the correlation id as a string of opaque content > > - to look at the poller, as the name suggests, as a > retriever object. As > > already mentioned (issue 2802) there are requirements for > retrieving objects by > > other means than a correlation id and you can even think of > supporting > > different kinds of filters for retrieving replies in the > future (see also JMS). > > > > Thus even from a purist point of view, I would rather make > a difference between > > pollers and correlation ids. > > > > Thanks and regards > > Hans > > -- > > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > > > > John Knapman > > > > > > Dr J M Knapman, MQSeries Technical Strategy, IBM, Hursley, UK > > > Telephone: +44-1962-818381; fax: +44-1962-818338 > > > Notes: John Knapman@IBMGB; internet: knapman@uk.ibm.com > > > > > > > > > hans.kneubuehl@ubs.com on 03/09/2000 01:28:57 PM > > > > > > Please respond to hans.kneubuehl@ubs.com > > > > > > To: messaging-rtf@omg.org, uabcsru@uab.ericsson.se > > > cc: (bcc: John Knapman/UK/IBM) > > > Subject: 2803: Requirement for Correlation Id > > > > > > > > > > > > > > > From Proposed Resolutions for Vote 1. Draft 1 - 25th > February 2000: > > > > > > > >Issue 2803: Support of some form of correlation > > > identification is needed > > > (messaging-rtf) > > > > > > > >Summary: 2. There is a lack in providing support for > > > correlating requests > > > and > > > replies in > > > >the case of TII. Support of some form of correlation > > > identification is > > > needed. > > > > > > > >Proposed Resolution > > > >The issue of having request identifiers was discussed long > > > and hard in the > > > original > > > >submission team, and the current solution was the result > of a tough > > > compromise. In the > > > >case of TII, one still has a single Poller per request > sent and so > > > correlation > > > is not > > > >difficult in this case. For the TII callbacks, it was > > > envisioned that one > > > would have > > > >separate callback object references for each request, so > > > that correlation > > > could be > > > >achieved in this way, and perhaps use the POA to have a > > > single servant or > > > even > > > >activated-on-demand servants for these callback object > references. > > > >Close this issue. > > > > > > Could someone please explain to me what the compromise is, > > > ie. what is the > > > trade off for not having correlation ids? > > > > > > Here is why I think that there is a "hard" requirement for > > > correlation ids > > > in > > > the case of TII: > > > > > > (1) A first program sends an asynchronous request and gets > > > back a poller. > > > The > > > poller must contain all the necessary information for > > > retrieving the reply > > > to > > > this request. With TII it must be possible to store this > information > > > somewhere > > > to a persistent store such that a different program can later > > > reconstruct > > > an > > > equivalent poller from this information in order to retrieve > > > the reply. > > > > > > -> How can the information in the poller be stored to a > > > persistent store? > > > -> How can an equivalent poller be constructed from this > > > information? > > > > > > Note that the target objref and the operation name on the > > > generic Poller > > > valuetype is not enough information to correlate requests and > > > replies. A > > > TII > > > implementation must maintain internally more correlation > information. > > > > > > -> When the poller supports a correlation id attribute > the above > > > scenario is > > > easy: the first program queries the poller for the value of > > > the correlation > > > id > > > that could be implemented as a string of > > > implementation-specific content. > > > It > > > then writes the string to a persistent store. The second > program then > > > instantiates a poller and sets the correlation id attribute. > > > This poller > > > then > > > can be used to retrieve the desired reply. > > > > > > (2) There can be multiple poller instances that refer to the > > > same reply, > > > e.g. > > > replies are retrieved from a different process than the > > > sending one. But > > > there > > > could also be scenarios where multiple poller instances > > > refering to the > > > same > > > request exist within the same process, e.g. the retrieving > > > applications > > > could > > > simply instantiate multiple times an equivalent poller in > > > different places > > > of > > > the program e.g. in order to compare an earlier > instantiated poller to > > > poller > > > information externalized to a persistent store. Therefore > > > there is a need > > > that > > > to poller instances can be compared to be equivalent. > > > > > > -> When the poller supports a correlation id attribute > > > comparison is > > > easy: > > > just compare the value of the correlation id attribute. > > > > > > (3) With TII callbacks, as pointed out in the quoted text > above, it is > > > possible > > > to "correlate" requests to replies when the application uses > > > a separate > > > callback object for each request. This works, but is quite > awkward > > > (correlation > > > is not supported by the middleware, but has to be done by the > > > application). > > > If > > > the middlware supports a correlation id, this would be much > > > more useful to > > > the > > > applications: > > > > > > -> When the poller supports a correlation id attribute > > > and the callback > > > methods support a correlation id attribute, sendp could be > > > used to send the > > > requests (sendp is already the general form which allows > to delay the > > > decision > > > whether replies are retrieved by polling or by callback) > and query the > > > correlation id. This value could then be compared to the > > > correlation id > > > received on callbacks. > > > > > > I can't see how (1) can be done based on the current specs, > > > thus I think > > > there > > > is really a defect with the specs here and this is the "hard" > > > requirement > > > for > > > some form of correlation mechanism. (2) could also be > > > resolved by extending > > > the > > > poller by a comparison operation. (3) can already be done. > > > > > > Introducing a correlation id attribute on the generic Poller > > > valuetype is > > > small > > > intervention which should not break any exsiting code and > > > which should be > > > easy > > > implementable as current CORBA Messaging implementation have > > > to maintain > > > internally already now the necessary correlation information. > > > This would > > > solve > > > (1) and (2). (3) would obviously be a major intervention as > > > the signature > > > of > > > the callback methods changes. > > > > > > I think at least (1) and (2) should be solved. I'm also in > > > favor of (3) but > > > I > > > don't now how much other people are worried about backward > > > compatibility > > > (old > > > signatures could be required for backward compatibility). > > > > > > Should I write a straw man for this, or are there any voices > > > completely > > > opposed > > > to the above exposure? > > > > > > Regards > > > Hans > > > -- > > > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > > > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > > > > > > > > > > > > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 13 Mar 2000 11:50:45 +0100 Message-Id: Subject: 2803 (Correlation/Externalization) -> Which resolution? MIME-Version: 1.0 TO: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 13 Mar 2000 11:50:45 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 13 Mar 2000 11:50:45 +0100" X-UIDL: QOkd9[3:e9NdN!!jf(!! Dear RTF member, hopefully, the problematic of issue 2803 ('requirement for correlation' aka 'requirement for externalization') are well-understood. There are different possibilities how to resolve this, and I would like to find out for which ones the RTF members are in favor of, such that I could work out a resolution proposal for vote 1 before the freeze on 15 March. Which one, or which ones, should I consider for a resolution proposal? (1) introduce correlation id attribute (2) introduce correlation id attribute and state member (3) change MessageRouting::PersistentRequest state member to public (4) introduce Messaging::Request attribute Below you find an issue summary and a short description of (1) - (4): issue summary: -------------- > > > - 2803: How can I pass a poller from the sending client to > > the polling client > > > by a persistent store, e.g. because the sending client is > > already terminated > > > when the polling client is started or simply for > > recoverability reasons in case > > > of failures? How can two poller instances be compared > > whether they refer to the > > > same outstanding reply. > > > > The original submitters didnt (I believe) attempt to satisfy the > > requirement to "externalize" a PersistentPoller which is what > > I believe you want. > > Yes, that's one point. Another is that I would like to > compare pollers whether they refer to the same reply. > > I just had a look at the C++ PollableSet Example: > There pollers are compared using is_equivalent, the > comparision operation defined for objrefs. Thus, from the > point of view of the original submitters, pollers could be > compared and with the change for Pollable to an abstract > valuetype we should make sure that pollers can still be compared. (1) introduce correlation id attribute - define correlation id as a string of opaque content - introduce a correlation id attribute on CORBA::Poller - introduce initializers on persistent type-specific pollers -> correlation can be done by saving the correlation id to a persistent store and instantiating a persistent type-specific poller in a different process using the saved correlation id -> comparison of non-persistent and persistent pollers can be done by comparing the correlation id (2) introduce correlation id attribute and state member - define correlation id as a string of opaque content - introduce a correlation id attribute on CORBA::Poller - introduce a private correlation id state member on CORBA::Poller - introduce initializers on type-specific pollers - remove persistent type-specific pollers -> correlation can be done by saving the correlation id to a persistent store and instantiating a type-specific poller in a different process using the saved correlation id -> comparison of non-persistent and persistent pollers can be done by comparing the correlation id (3) change MessageRouting::PersistentRequest state member to public - the generated, persistent type-specific pollers have a private state member of type MessageRouting::PersistentRequest; change it to public access - introduce initializers on the persistent type-specific pollers - introduce a comparison operation on CORBA::Poller -> correlation can be done by saving the object_to_string'ed state member to a persistent store and instantiating a persistent type-specific poller in a different process using the string_to_object'ed saved value -> comparison of non-persistent and persistent pollers can be done by using the comparison operation (4) introduce Messaging::Request attribute - define an (probably empty) interface Messaging::Request - introduce an oustanding request attribute of type Messaging::Request on CORBA::Poller - introduce a private state member on CORBA::Poller - change MessageRouting::PersistentRequest to inherit from Messaging::Request - introduce initializers on type-specific pollers - remove persistent type-specific pollers - define that the private state member of CORBA::Poller must contain a PeristentRequest in the case of TII -> correlation can be done by saving the object_to_string'ed state member to a persistent store and instantiating a type-specific poller in a different process using the string_to_object'ed saved value -> comparison of non-persistent and persistent pollers can be done by comparing the outstanding request attribute Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 13 Mar 2000 11:50:45 +0100 Message-Id: Subject: 2803 (Correlation/Externalization) -> Which resolution? MIME-Version: 1.0 TO: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 13 Mar 2000 11:50:45 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 13 Mar 2000 11:50:45 +0100" X-UIDL: QOkd9[3:e9NdN!!jf(!! Dear RTF member, hopefully, the problematic of issue 2803 ('requirement for correlation' aka 'requirement for externalization') are well-understood. There are different possibilities how to resolve this, and I would like to find out for which ones the RTF members are in favor of, such that I could work out a resolution proposal for vote 1 before the freeze on 15 March. Which one, or which ones, should I consider for a resolution proposal? (1) introduce correlation id attribute (2) introduce correlation id attribute and state member (3) change MessageRouting::PersistentRequest state member to public (4) introduce Messaging::Request attribute Below you find an issue summary and a short description of (1) - (4): issue summary: -------------- > > > - 2803: How can I pass a poller from the sending client to > > the polling client > > > by a persistent store, e.g. because the sending client is > > already terminated > > > when the polling client is started or simply for > > recoverability reasons in case > > > of failures? How can two poller instances be compared > > whether they refer to the > > > same outstanding reply. > > > > The original submitters didnt (I believe) attempt to satisfy the > > requirement to "externalize" a PersistentPoller which is what > > I believe you want. > > Yes, that's one point. Another is that I would like to > compare pollers whether they refer to the same reply. > > I just had a look at the C++ PollableSet Example: > There pollers are compared using is_equivalent, the > comparision operation defined for objrefs. Thus, from the > point of view of the original submitters, pollers could be > compared and with the change for Pollable to an abstract > valuetype we should make sure that pollers can still be compared. (1) introduce correlation id attribute - define correlation id as a string of opaque content - introduce a correlation id attribute on CORBA::Poller - introduce initializers on persistent type-specific pollers -> correlation can be done by saving the correlation id to a persistent store and instantiating a persistent type-specific poller in a different process using the saved correlation id -> comparison of non-persistent and persistent pollers can be done by comparing the correlation id (2) introduce correlation id attribute and state member - define correlation id as a string of opaque content - introduce a correlation id attribute on CORBA::Poller - introduce a private correlation id state member on CORBA::Poller - introduce initializers on type-specific pollers - remove persistent type-specific pollers -> correlation can be done by saving the correlation id to a persistent store and instantiating a type-specific poller in a different process using the saved correlation id -> comparison of non-persistent and persistent pollers can be done by comparing the correlation id (3) change MessageRouting::PersistentRequest state member to public - the generated, persistent type-specific pollers have a private state member of type MessageRouting::PersistentRequest; change it to public access - introduce initializers on the persistent type-specific pollers - introduce a comparison operation on CORBA::Poller -> correlation can be done by saving the object_to_string'ed state member to a persistent store and instantiating a persistent type-specific poller in a different process using the string_to_object'ed saved value -> comparison of non-persistent and persistent pollers can be done by using the comparison operation (4) introduce Messaging::Request attribute - define an (probably empty) interface Messaging::Request - introduce an oustanding request attribute of type Messaging::Request on CORBA::Poller - introduce a private state member on CORBA::Poller - change MessageRouting::PersistentRequest to inherit from Messaging::Request - introduce initializers on type-specific pollers - remove persistent type-specific pollers - define that the private state member of CORBA::Poller must contain a PeristentRequest in the case of TII -> correlation can be done by saving the object_to_string'ed state member to a persistent store and instantiating a type-specific poller in a different process using the string_to_object'ed saved value -> comparison of non-persistent and persistent pollers can be done by comparing the outstanding request attribute Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Sender: Chris.Smith@uab.ericsson.se Message-ID: <38CCE30E.87BC6112@uab.ericsson.se> Date: Mon, 13 Mar 2000 13:46:06 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: 2803 (Correlation/Externalization) -> Which resolution? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,S4!!OQ[!!Kg*e9 Which one, or which ones, should I consider for a resolution proposal? > (1) introduce correlation id attribute > (2) introduce correlation id attribute and state member > (3) change MessageRouting::PersistentRequest state member to public > (4) introduce Messaging::Request attribute > Either 3) or close without action. The PersistentPollers can be passed from one client to another without change today. There is no language portable support for externalisation of valuetypes (as far I know), which is what you basically want. Doing 3) is a "cheat" way of externalising the PersistentPoller since its only state is an object reference which can be object_to_string'd. Your product could of course provide value add to allow persistification of PersistentPollers and creation of new ones from the persistified state.... From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 14 Mar 2000 16:59:26 +0100 Message-Id: Subject: Re: 2803 (Correlation/Externalization) -> Which resolution? MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 14 Mar 2000 16:59:26 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 14 Mar 2000 16:59:26 +0100" X-UIDL: Z5G!!Uf~e9`4/e9Dpe!! > -----Original Message----- > From: uabcsru [mailto:uabcsru@uab.ericsson.se] > Sent: Monday, March 13, 2000 1:46 PM > > Which one, or which ones, should I consider for a > resolution proposal? > > (1) introduce correlation id attribute > > (2) introduce correlation id attribute and state member > > (3) change MessageRouting::PersistentRequest state member to > public > > (4) introduce Messaging::Request attribute > > > > > Either 3) or close without action. The PersistentPollers can be > passed from one client to another without change today. There > is no language portable support for externalisation of valuetypes > (as far I know), which is what you basically want. Doing 3) is > a "cheat" way of externalising the PersistentPoller since its > only state is an object reference which can be object_to_string'd. > Your product could of course provide value add to allow > persistification of PersistentPollers and creation of new ones > from the persistified state.... Ok, I take note of your position (and it would be good to get some more opinions... ) I just wanted to clarify to things which might not be clear from the issue description: - The issue is about externalization support for *portable* applications which might not be clear from the issue description. Thus close without action would not solve the issue. - I'm not sure what you mean by "cheat" way. Anyhow, I want to externalize pollers which happen to be valuetypes. For me it makes sense that there is no object_to_string equivalent for valuetypes because valuetypes are user-defined types whereas Objrefs are predefined type. Thus, IMO, I'm *not* proposing a workaround for a defect that must be solved in another place. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Sender: Chris.Smith@uab.ericsson.se Message-ID: <38CE6DD1.23C1DBBC@uab.ericsson.se> Date: Tue, 14 Mar 2000 17:50:25 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: 2803 (Correlation/Externalization) -> Which resolution? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Z7~e9'R-e9]h:!!/_+!! > > Either 3) or close without action. The PersistentPollers can be > > passed from one client to another without change today. There > > is no language portable support for externalisation of valuetypes > > (as far I know), which is what you basically want. Doing 3) is > > a "cheat" way of externalising the PersistentPoller since its > > only state is an object reference which can be object_to_string'd. > > Your product could of course provide value add to allow > > persistification of PersistentPollers and creation of new ones > > from the persistified state.... > > Ok, I take note of your position (and it would be good to get some > more > opinions... ) > > I just wanted to clarify to things which might not be clear from the > issue > description: > - The issue is about externalization support for *portable* > applications which > might not be clear from the issue description. Thus close without > action would > not solve the issue. > - I'm not sure what you mean by "cheat" way. Anyhow, I want to > externalize > pollers which happen to be valuetypes. For me it makes sense that > there is no > object_to_string equivalent for valuetypes because valuetypes are > user-defined > types whereas Objrefs are predefined type. Well, I meant it was a cheat way of externalising because it wont allow you to externalize the Poller, but just get to its state from an application and externalize that. But thats not a big problem I guess. I find it difficult to see how you would portably create a new Poller and internalize the state though. Since these valuetypes are created by the IDL compiler, an application cannot know how to get to a valutype factory for them, and their is no standardised constructor on these valuetypes either. > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 15 Mar 2000 08:42:19 +0100 Message-Id: Subject: Re: 2803 (Correlation/Externalization) -> Which resolution? MIME-Version: 1.0 TO: hans.kneubuehl@ubs.com, uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 15 Mar 2000 08:42:18 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 15 Mar 2000 08:42:18 +0100" X-UIDL: L\T!!M2>e97V0e9\E*e9 > -----Original Message----- > From: uabcsru [mailto:uabcsru@uab.ericsson.se] > Well, I meant it was a cheat way of externalising because it > wont allow you to externalize the Poller, but just get to its > state from an application and externalize that. But thats not > a big problem I guess. I find it difficult to see how you > would portably create a new Poller and internalize the state > though. Since these valuetypes are created by the IDL compiler, > an application cannot know how to get to a valutype factory > for them, and their is no standardised constructor on these > valuetypes either. You have pointed that out already earlier. I think the way to do is by introducing standardised constructors (called valuetype initializers in CORBA) on the IDL-generated persistent pollers. >From my previous e-mail: (3) change MessageRouting::PersistentRequest state member to public - the generated, persistent type-specific pollers have a private state member of type MessageRouting::PersistentRequest; change it to public access - introduce initializers on the persistent type-specific pollers - introduce a comparison operation on CORBA::Poller -> correlation can be done by saving the object_to_string'ed state member to a persistent store and instantiating a persistent type-specific poller in a different process using the string_to_object'ed saved value -> comparison of non-persistent and persistent pollers can be done by using the comparison operation Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 15 Mar 2000 17:43:27 +0100 Message-Id: Subject: 2803: variant (2) -> introduce correlation id attribute MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 15 Mar 2000 17:43:27 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id NAA12740 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Wed, 15 Mar 2000 17:43:27 +0100" X-UIDL: eb0e9P"jd9G&#!!g-1e9 > Issue 2803: 'requirement for correlation' aka 'requirement for externalization' > > Summary: In the case of TII, how can I pass a poller from the sending client to > the polling client by a persistent store, e.g. because the sending client is > already terminated when the polling client is started or simply for > recoverability reasons in case of failures? The original submitters probably > didnt attempt to satisfy the requirement to "externalize" a PersistentPoller. Proposed Resolution Summary: ---------------------------- - define correlation id as a string of opaque content - introduce a correlation id attribute on CORBA::Poller - introduce initializers on persistent type-specific pollers Proposed Resolution: -------------------- The following changes are referring to document ptc/00-02-05. p. 1-24, 1-25 change "The Poller has the following definition: module Messaging { valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; };" to read "The Poller has the following definition: module Messaging { typedef string CorrelationId; valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; readonly attribute CorrelationId id; Object target; string op_name; }; };" p. 1-25, add after the paragraph 'is_from_poller' "id A correlation id for the request is accessible from any poller. The returned string is of opaque content. Non-TII applications may only use it for comparison: the correlation id for two pollers are the same if and only if the pollers refer to the same original request. When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of a special poller subtype is returned from such invocations. The instance contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. However, the correlation id attribute provides the applications access to this state in a stringified form. This allows the state to be stored in a persistent store and later use it for initializing an equivalent poller in the client that will poll the reply." p. 1-18, change "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: value AMI_PersistentPoller : AMI_Poller { MessageRouting::PersistentRequest outstanding_request; }; Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." to read "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state and an initialier. For an interface named ifaceName the following PersistentPoller is generated: valuetype AMI_PersistentPoller : AMI_Poller { private MessageRouting::PersistentRequest outstanding_request; factory init(in Messaging::CorrelationId id); }; This PersistentPoller can be instantiated by the application by providing the value of the correlation id attribute of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." p. 1-67, change " // // Base value for the Polling model // valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; Object target; string op_name; }; " to read " // // Base value for the Polling model // typedef string CorrelationId; valuetype Poller : CORBA::Pollable { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; readonly attribute CorrelationId id; Object target; string op_name; }; " p. 1-99, change "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4 , on page 1-44." to read "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4 , on page 1-44." Rational: --------- See the issue summary for a description of the requirement. The current specs defines that the PersistentRequest reference is what is required to make it possible to poll for the reply in a client different from the one that made the initial request. This resolution provides access to the PersistentRequest reference indirectly by defining a way how the applications can gain the equivalent information in form of an opaque string. This avoids that the application gets in touch with ORB-internal data structures. A TII-aware ORB implementation might choose to use the object_to_string'd PersistentRequest reference as the correlatio id, but it might as well choose to define some other format for which it is able to reconstitute an equivalent poller. -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 15 Mar 2000 17:42:56 +0100 Message-Id: Subject: 2803: variant (3) -> change MessageRouting::PersistentRequest state member to public MIME-Version: 1.0 TO: uabcsru@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 15 Mar 2000 17:42:55 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id OAA14286 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Wed, 15 Mar 2000 17:42:55 +0100" X-UIDL: Z2%e9p<)e95ja!!?iEe9 > Issue 2803: 'requirement for correlation' aka 'requirement for externalization' > > Summary: In the case of TII, how can I pass a poller from the sending client to > the polling client by a persistent store, e.g. because the sending client is > already terminated when the polling client is started or simply for > recoverability reasons in case of failures? The original submitters probably > didnt attempt to satisfy the requirement to "externalize" a PersistentPoller. Proposed Resolution Summary: ---------------------------- - the generated, persistent type-specific pollers have a private state member of type MessageRouting::PersistentRequest; change it to public access - introduce initializers on the persistent type-specific pollers Proposed Resolution: -------------------- The following changes are referring to document ptc/00-02-05. p. 1-26, change "1.3.6 Type-Specific Poller Mapping The polling model requires usage of generated type-specific Poller values.A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds private state that allows the response to be obtained from a client other than the client that made the request. This private state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." to read " 1.3.6 Type-Specific Poller Mapping The polling model requires usage of generated type-specific Poller values. A value is used because all operations are locally implemented. The basic generated Poller encapsulates the operations for obtaining replies to an outstanding asynchronous request. A derived PersistentPoller value also adds public state and initializers that allows the response to be obtained from a client other than the client that made the request. The PerThis public state is used by the PersistentPoller implementation in conjunction with the messaging-aware ORB." p. 1-28, change "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used privately by the messaging-aware ORB and is not directly accessible to the application. The generated PersistentPoller value is derived from the basic one. It adds no methods, only one piece of private state. For an interface named ifaceName the following PersistentPoller is generated: value AMI_PersistentPoller : AMI_Poller { MessageRouting::PersistentRequest outstanding_request; }; Just as with any CORBA value this PersistentPoller can be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee." to read "1.3.6.2 Persistent Type-Specific Poller When Time-Independent Invocations are made, the reply may be obtained by a different client than the one that made the original request. An instance of persistent poller is returned from such invocations. The PersistentPoller contains the state necessary to allow polling to be performed in a client distinct from the one that made the request. This state is used by the messaging-aware ORB. It is also made directly accessible to the application such that it can be used to save it in a persistent store and initialize PersistentPoller values in a different client. The generated PersistentPoller value type is derived from the basic one. It adds no methods, only one piece of public state and an initializer. For an interface named ifaceName the following PersistentPoller is generated: valuetype AMI_PersistentPoller : AMI_Poller { public MessageRouting::PersistentRequest outstanding_request; factory init(in MessageRouting::PersistentRequest outstanding_request); }; This PersistentPoller can be instantiated by the application by providing the value of the outstanding_request state member of the persistent poller returned from a Time-Independent Invocation. For optimisation reasons, it is not required that PersistentPoller instances that are created via the initializer will have the target and op_name members initalized with the values from the original request upon creation. This PersistentPoller can also be passed as an argument to IDL operations and a copy of the Poller will be instantiated local to the callee. Note that the IDL operation must use the generic Poller or Pollable type for the parameter because type-specific pollers are only defined in implied-IDL." p. 1-99, change "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4 , on page 1-44." to read "A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is specified to allow client applications to save it in a persistent store and to enable interoperability between Messaging products. When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client or by instantiating an equivalent Poller in the latter client using the initializer). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 1.4 , on page 1-44." Rational: --------- See the issue summary for a description of the requirement. The current specs defines that the PersistentRequest reference is what is required to make it possible to poll for the reply in a client different from the one that made the initial request. This resolution provides public access to the PersistentRequest reference such that applications can store the object_to_string'd reference in a persistent store and instantiate an equivalent poller in the polling client by providing the string_to_object'd reference. -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: Bill Binko To: Messaging-Rtf Subject: Discussion Issue 2803: Support of some form of correlation identi fication is needed (messaging-rtf) Date: Wed, 22 Mar 2000 12:29:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Sb/!!?UQ!!MK7!!<>8!! I am leaning toward option A) on this one for the following reasons: 1) I think it is true that a PersistentPoller should be able to be persisted to stable storage BY THE APPLICATION. With its current definition, I believe it would be difficult if not impossible to do this. 2) Option B) may be useful to people not planning to use a PersistentRequest behind the poller. However, the TII portion of the spec is designed with those semantics in mind, and to loosen those semantics would be outside the scope of this RTF IMHO. That being said, I would request that some of the RTF members with more OBV experience than I review option A with a fine-tooth comb. Particularly, I'm concerned about the multiple-inheritence issues that came up (late!) with the ExceptionHolders--does adding the initializer add any problems? Must we inherit like the ExceptionHolders? Anyway, I will lean towards A until convinced otherwise. Binko From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 23 Mar 2000 08:12:39 +0100 Message-Id: Subject: RE: Discussion Issue 2803: Support of some form of correlation identi fication is needed (messaging-rtf) MIME-Version: 1.0 TO: Bill.Binko@trcinc.com, messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 23 Mar 2000 08:12:38 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 23 Mar 2000 08:12:38 +0100" X-UIDL: _VCe9EeCe99Ok!! -----Original Message----- > From: Bill.Binko [mailto:Bill.Binko@trcinc.com] > Sent: Wednesday, March 22, 2000 6:29 PM > > That being said, I would request that some of the RTF members > with more OBV > experience than I review option A with a fine-tooth comb. > Particularly, I'm > concerned about the multiple-inheritence issues that came up > (late!) with > the ExceptionHolders--does adding the initializer add any > problems? Must we > inherit like the ExceptionHolders? Bill, there should be no inheritance issue with initializers. They are like C++ constructors, ie. initializers are specific to one value type. In case of value type inheritance, they don't get inherited from base value types. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11