Issue 4305: unknown context issue (ots-structs-ftf) Source: University of Newcastle upon Tyne (Dr. Mark Little, m.c.little@ncl.ac.uk) Nature: Uncategorized Issue Severity: Summary: Currently the text states that an importing domain that does not understand activity_specific_information encoded within the context (typically determined by looking at the type field) should simply null them out (or replace them with its own). I'd like to suggest that we change this so that the importing domain throws an exception, and does no work on behalf of that invocation. This is because typically this data will be dependant upon the specific extended transaction model in use, and an importing domain could corrupt data if it doesn't use the entire context correctly. Resolution: As per summary Revised Text: Additional information may be encoded within the activity_specific_data and invocation_specific_data fields. It is legal for these fields to contain an empty any. An implementation must not rely on the data that was sent with an outbound context being available on the reply context. The invocation_specific_data is meant to carry information which is required for a specific implementation of the service. Because this information is specific to a given implementation of the Activity Service it is illegal for an importing domain that is different from the exporting domain to use this field. To ensure integrity of the application (specifically in the case of loop-backs between foreign and native domains), a domain which does not understand the invocation_specific_data within an activity context must replace it with an empty any. Such a domain is free, however, to replace the data with data specific to itself. The activity_specific_data is meant to carry information which is required for an implementation of a specific extended transaction model. If an importing domain implements a different extended transaction model than the exporting domain, i.e., it does not understand the activity_specific_data, then it must not use the context, and should throw BAD_CONTEXT. Type values for Activities supporting specific extended transaction models will be defined in the future. Each specific type will also define the format of the activity_specific_data that may be propagated as part of the ActivityIdentity structure in the service context. Actions taken: May 14, 2001: received issue May 2, 2003: closed issue Discussion: End of Annotations:===== From: "Mark Little" To: "XOTS FTF" Cc: Subject: unknown context issue Date: Mon, 14 May 2001 16:48:32 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0149_01C0DC95.B60A73B0" X-UIDL: ];+e9[?-e9(M9!!38Je9 Currently the text states that an importing domain that does not understand activity_specific_information encoded within the context (typically determined by looking at the type field) should simply null them out (or replace them with its own). I'd like to suggest that we change this so that the importing domain throws an exception, and does no work on behalf of that invocation. This is because typically this data will be dependant upon the specific extended transaction model in use, and an importing domain could corrupt data if it doesn't use the entire context correctly. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id KAA73920; Fri, 18 May 2001 10:38:53 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A50.0034FDB8 ; Fri, 18 May 2001 10:38:48 +0100 X-Lotus-FromDomain: IBMGB To: "Mark Little" cc: ots-structs-ftf@omg.org Message-ID: <80256A50.0034FD0C.00@d06mta05.portsmouth.uk.ibm.com> Date: Fri, 18 May 2001 10:29:36 +0100 Subject: Re: issue # 4305 - unknown context issue Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: No"e9_5Xd9';R!!i@B->A2, where A and B represent different Activity service vendors. If B was not required to null A1's activity_specific_data, then A2 might believe it could participate in an optimized exchange with its immediate superior on the basis of understanding the received activity_specific_data. The specification says the following about the activity_specific_data: "An implementation must not rely on the data that was sent with an outbound context being available on the reply context. Because this information is likely to be specific to a given implementation of the Activity Service it is illegal for an importing domain that is different from the exporting domain to use these fields. To ensure integrity of the application (specifically in the case of loop-backs between foreign and native domains), a domain which does not understand the anys within an activity context must at least replace them all with empty anys. Such a domain is free, however, to replace the anys with implementations specific to itself, but only if it replaces them all or sets those it does not need to an empty any." The means by which an Activity service determines whether or not it recognises the activity_specific_data is not defined, although Mark has suggested that the 'type' field could be used for this purpose. Currently, the defined role of the 'type' field is to distinguish between an ActivityIdentity representing an Activity or marking the position in the ActivityIdentity sequence of a transaction. It was defined as an unsigned long to enable it to be used in the future to define different types of Activity, which might have different characteristics. I think there is value in the view that different types of Activity (for example representing different types of extended transaction model, regardless of any vendor-specific considerations) might have sufficiently specific behaviour that an importing domain that does not support that specific type of Activity should not allow the invocation to proceed, for fear of failing to satisfy the intent of the invocation. I also think that there is very real value in providing vendor-specific data for optimising performance between execution environments within a homogenous domain, that should not cause an invocation failure if the format of the data is not understood. I would therefore like to propose the following modification to the ActivityIdentity structure to accomodate these different requirements: - the addition of a new field: Any type_specific_data - the modification of the 'type' description to indicate that it describes the format of the type_specific_data. We could then keep the existing intention, usage and behaviour of the activity_specific_data (although we might want to rename it implementation_specific_data). The precise behaviour would then be: - a receiving domain that does not understand the content of the activity_specific_data should set it to nil or replace it. - a receiving domain that does not support the type (which is equivalent to not understanding the content of the type_specific_data) should throw an exception. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com "Mark Little" on 14/05/2001 16:48:32 Please respond to "Mark Little" To: "XOTS FTF" cc: issues@omg.org Subject: unknown context issue Currently the text states that an importing domain that does not understand activity_specific_information encoded within the context (typically determined by looking at the type field) should simply null them out (or replace them with its own). I'd like to suggest that we change this so that the importing domain throws an exception, and does no work on behalf of that invocation. This is because typically this data will be dependant upon the specific extended transaction model in use, and an importing domain could corrupt data if it doesn't use the entire context correctly. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 #### att1.htm has been removed from this note on 15 May 2001 by Ian Robinson Importance: Normal Subject: Issue 4305: proposal To: ots-structs-ftf@omg.org Cc: mcl@arjuna.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Fri, 20 Jul 2001 12:12:21 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 12:19:30 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: O9`!!X1_d9@l5e91]8e9 There is a need to provide a facility for the propagation of "implementation specific data" in the Activity service context for the benefits of both an Activity service implementation itself and for higher-level extended transaction models built on top of the Activity service. Such implementation specific data is private to the component using it and the required behaviour of the target system in the case that this information is not understand differs depending on whether it is the implementation_specific_data belonging to the Activity service or extended transaction model that is not understood. The following is proposed to resolve this issue. 1. The ActivityIdentity structure is modified with the addition of a new field: Any type_specific_data 2. The ActivityIdentity 'type' description is modified to indicate that it describes the format of the type_specific_data. 3. The precise behaviour for handling a received ActivityIdentity should be: - a receiving domain that does not understand the content of the activity_specific_data should set it to nil or replace it. - a receiving domain that does not support the type (which is equivalent to not understanding the content of the type_specific_data) should throw an INVALID_ACTIVITY system exception. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com Importance: Normal Subject: Issue 4305: proposal To: ots-structs-ftf@omg.org Cc: mcl@arjuna.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Fri, 20 Jul 2001 16:08:09 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 16:20:22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 1m[d9P-5e94p_d9f"Yd9 Before any comments are posted, let me clarify this proposal with further detail. There is a need to provide a facility for the propagation of "implementation specific data" in the Activity service context for the benefits of both an Activity service implementation itself and for higher-level extended transaction models built on top of the Activity service. Such implementation specific data is private to the component using it and the required behaviour of the target system in the case that this information is not understand differs depending on whether it is the implementation_specific_data belonging to the Activity service or extended transaction model that is not understood. The following is proposed to resolve this issue. 1. The ActivityIdentity structure is modified with the addition of a new field, of type 'any', called type_specific_data. Sections 2.1.3.4 and B.1 should be updated to describe the ActivityIdentity structure: struct ActivityIdentity { unsigned long type; long timeout; ActivityCoordinator coord; sequence ctxId; sequence pgCtx; any activity_specific_data; any type_specific_data; }; 2. The ActivityIdentity 'type' description is modified to indicate that it describes the format of the type_specific_data. 3. The precise behaviour for handling a received ActivityIdentity should be described in section 2.1.3.4: - a receiving domain that does not understand the content of the activity_specific_data should set it to nil or replace it. - a receiving domain that does not support the type (which is equivalent to not understanding the content of the type_specific_data) should throw an INVALID_ACTIVITY system exception. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com From: "Mark Little" To: "XOTS" Subject: FTF meeting summary Date: Wed, 18 Jul 2001 10:05:44 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *%D!!CL[d9H0jd9D]:!! Just a quick note to report on the meeting we had at Danvers. We managed to work through all of the issues that were reported prior to Danvers, though some have come up since. A brief summary of the issues we discussed, and the resolutions follows (the individuals who will write up the final proposed resolutions are also indicated). Proposal for 4305: must understand semantics for specific extended transaction model. [Mark Little to write up.] From: "Mark Little" To: "XOTS FTF" Subject: Proposal for 4305 Date: Tue, 31 Jul 2001 16:53:18 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: @k^!!$>7e9<,6!!k95e9 Update the final paragraph in section 2.1.3.4 to read: Additional information may be encoded within the activity_specific_data and invocation_specific_data fields. It is legal for these fields to contain an empty any. The activity_specific_data is meant to carry information which is required for an implementation of a specific extended transaction model. An implementation must not rely on the data that was sent with an outbound context being available on the reply context. Because this information is likely to be specific to a given implementation of the Activity Service it is illegal for an importing domain that is different from the exporting domain to use these fields. To ensure integrity of the application (specifically in the case of loop-backs between foreign and native domains), a domain which does not understand the invocation_specific_data within an activity context must at least replace them all with empty anys. Such a domain is free, however, to replace the anys with implementations specific to itself, but only if it replaces them all or sets those it does not need to an empty any. If an importing domain implements a different extended transaction model than the exporting domain, i.e., it does not understand the activity_specific_data, then it must not use the context, and should throw BAD_CONTEXT. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203 Importance: Normal Subject: Re: Proposal for 4305 To: "Mark Little" Cc: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Thu, 2 Aug 2001 21:38:58 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 02/08/2001 21:51:44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: :"ad9PD`d9VgKe9nL_!! Mark, You have proposed that the ActivityContext.invocation_specific_data field be used for the purpose of carrying Activity service implementation-specific-data and that the ActivityIdentity.activity_specific_data field be used for the purpose of carrying data specific to a particular extended transaction model. I believe there is value in providing a means for an Activity service implementation to scope its own implementation-specific-data at an ActivityIdentity-level rather than an ActivityContext-level, providing better encapsulation of context data. While it would be perfectly possible to build all the implementation-specific-data for all the ActivityIdentities into a single Any (for example as a sequence of structures), this might not be the most efficient or convenient way to marshal and demarshal a complex hierarchy of contexts each containing its own Activity service implementation-specific-data. I believe we should design for maximum flexibility from the outset; an Activity service implementation is, of course, free to use the ActivityContext.invocation_specific_data rather than (or even as well as) a new field on the ActivityIdentity. This is why I have previously suggested a new field in the ActivityIdentity structure. Since the extended transaction model data should ideally be tied to the ActivityIdentity type value, I have suggested that that ActivityIdentity.activity_specific_data be used for the Activity service implementation-specific data and that a new field, type_specific_data, be provided for the specific exended transaction model data. If we accepted something like this, then the specification would need to be modified as follows: (changes highlighted by ... below): Update the 4th paragraph in section 2.1.3.4 to read: The type field, which must be a positive, non-zero value, is used to indicate the type of the element for which the information is being maintained. Currently defined values are: > 1: the element in the hierarchy is a transaction. > 2: the element in the hierarchy is an Activity. Type values for Activities supporting specific extended transaction models will be defined in the future. Each specific type will also define the format of the type_specific_data that may be propagated as part of the ActivityIdentity structure in the service context. Update the final paragraph in section 2.1.3.4 to read: Additional information may be encoded within the activity_specific_data, type_specific_data and invocation_specific_data fields. It is legal for these fields to contain an empty any. An implementation must not rely on the data that was sent with an outbound context being available on the reply context. The activity_specific_data is used to carry information specific to an implementation of the Activity service and may be used, for example, for performance optimzations within a common domain. It is illegal for an importing domain that is different from the exporting domain to use these fields. To ensure integrity of the application (specifically in the case of loop-backs between foreign and native domains), a domain which does not understand the activity_specific_data anys within an activity context must at least replace them all with empty anys. Such a domain is free, however, to replace the anys with implementations specific to itself, but only if it replaces them all or sets those it does not need to an empty any. The type_specific_data is meant to carry information which is required for an implementation of a specific extended transaction model. If an importing domain does not support the type of extended transaction model in a received context i.e., it does not understand the type_specific_data, then it must not use the context, and should throw BAD_CONTEXT. Update the IDL in sections 2.1.3.4 and B.1 to read: struct ActivityIdentity { unsigned long type; long timeout; ActivityCoordinator coord; sequence ctxId; sequence pgCtx; any activity_specific_data; any type_specific_data; }; Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com "Mark Little" on 31/07/2001 16:53:18 Please respond to "Mark Little" To: "XOTS FTF" cc: Subject: Proposal for 4305 Update the final paragraph in section 2.1.3.4 to read: Additional information may be encoded within the activity_specific_data and invocation_specific_data fields. It is legal for these fields to contain an empty any. The activity_specific_data is meant to carry information which is required for an implementation of a specific extended transaction model. An implementation must not rely on the data that was sent with an outbound context being available on the reply context. Because this information is likely to be specific to a given implementation of the Activity Service it is illegal for an importing domain that is different from the exporting domain to use these fields. To ensure integrity of the application (specifically in the case of loop-backs between foreign and native domains), a domain which does not understand the invocation_specific_data within an activity context must at least replace them all with empty anys. Such a domain is free, however, to replace the anys with implementations specific to itself, but only if it replaces them all or sets those it does not need to an empty any. If an importing domain implements a different extended transaction model than the exporting domain, i.e., it does not understand the activity_specific_data, then it must not use the context, and should throw BAD_CONTEXT. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203 From: "Mark Little" To: "Ian Robinson" Cc: References: Subject: Re: Proposal for 4305 Date: Mon, 6 Aug 2001 08:56:19 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Filter-Version: 3.3 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X-jd9<[id9V^!"!1]&!! > You have proposed that the ActivityContext.invocation_specific_data field > be used for the purpose > of carrying Activity service implementation-specific-data and that the > ActivityIdentity.activity_specific_data field be used for the purpose of > carrying data specific to a > particular extended transaction model. > I believe there is value in providing a means for an Activity service > implementation to scope its own > implementation-specific-data at an ActivityIdentity-level rather than an > ActivityContext-level, providing > better encapsulation of context data. Can you give me an example. What I don't want to see is us ending up with anys in every single data structure/interface simply because of "flexibility" that is never used. If we go that route then, as I pointed out when we first started the specification work, we'll end up with simply passing anys around the place and require the user to implement pretty complex, and implementation specific parsers. > While it would be perfectly possible > to build all the > implementation-specific-data for all the ActivityIdentities into a > single > Any (for example as a sequence > of structures), this might not be the most efficient or convenient > way to > marshal and demarshal a > complex hierarchy of contexts each containing its own Activity > service > implementation-specific-data. I agree it's flexible, I disagree that it's required. We have a lot of flexibility in the specification at the moment that probably won't be fully excercised for some time. I would prefer incremental changes to cover what user requirements are being unfulfilled and are deemed a necessity. If we find the single any is not sufficient then we can address it in a later RTF. The more anys we add, the more complexity in interoperation and useage we potentially add. > I believe we should design for maximum flexibility from the outset; an > Activity service implementation I agree, and disagree. From our experience of designing and building fairly complex systems over many years, users tend to require flexibility in areas we can't begin to see until people are *using* the system. If we add the flexibility we think they require, I'd take a bet that it wouldn't be sufficient, and probably wouldn't be used as much as we would expect. Let's get user feedback first. > is, of course, free to use the ActivityContext.invocation_specific_data > rather than (or even as well as) > a new field on the ActivityIdentity. > This is why I have previously suggested a new field in the ActivityIdentity > structure. Since the extended > transaction model data should ideally be tied to the ActivityIdentity type > value, I have suggested that > that ActivityIdentity.activity_specific_data be used for the Activity > service implementation-specific data > and that a new field, type_specific_data, be provided for the specific > exended transaction model data. I understand your rational, I just don't agree that it's the best way currently to address it. I think we have sufficient flexibility already built-in to the data structures to allow us to do what you mention. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203 From: "Mark Little" To: "Ian Robinson" Cc: References: Subject: Re: Proposal for 4305 Date: Tue, 7 Aug 2001 14:17:14 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^T+!!h%)!!#4 First of all, we need to recognise that changing the structure of the > service context in a future RTF is going to present an interoperation > headache that we won't have if we do it now. Agreed. But that's not an argument for adding the anys IMO. > So I wouldn't want to leave > that to a future RTF. > What I want is to build in the flexibility that implementors find > useful > now; as we are implementing the Activity service specification, IBM > already puts Activity service implementation-specific-data in our > service contexts on a per ActivityIdentity basis. If this information is not related to the implementation of a specific extended transaction model then I don't see why it is in the ActivityIdentity. If it is specific to IBMs implementation of the activity service (similar to the use of the implementation_specific_data field in the OTS context) then it should be in the ActivityContext. > We could move this to the ActivityContext.invocation_specific_data > but this becomes a minor nuisance to manage at marshal/unmarshal. We > build an array of ActivityIdentities, together with any i-s-d for > each one, and simply add to the ActivityContext. On the receiving > end, we can unpack each ActivityIdentity and it contains everything > we need. What we don't really want to do is to build the array of > ActivityIdentites, then build a second, separate array of structures > containing our i-s-d for each ActivityIdentity that we then need to > match-up at the reciving end. Having said that, this is actually the > least of my concerns regarding this proposal (but something I don't > want to lose sight of). I can understand your concern, but I think it a) breaks the model [ActivityIdentity is meant for model specific data], and b) still doesn't show a requirement for it at this level. I would like to keep the number of typeless variables in this specification to a minimum to reduce the complexity and any future headaches with interoperability. > My greater concerns are: > 1. Clearer descriptions of the different roles of the 'additional > information' fields in the ActivityIdentity/ActivityContext structures > and the different rules governing what happens if they are not > understood by the receiving end. The text proposed is misleading. For > example: > "...The activity_specific_data is meant to carry information which is > required for an implementation of a specific extended transaction model. An > implementation must not rely on the data that was sent with an outbound > context being available on the reply context. Because this information is > likely to be specific to a given implementation of the Activity Service it > is illegal for an importing domain that is different from the exporting > domain to use these fields..." > The final sentence above pertains to the invocation_specific_data, not > the activity_specific_data. Agreed. > 2. A clearer relationship between the activity_specific_data and the > ActivityIdentity.type field. > > So, I would still like to see a 3rd field for > ActivityIdentity.type_specific_data, text for which I've already proposed. > If we decide that we really don't want this, then I would suggest the > following text to describe the use of the existing fields: > > > Update the 4th paragraph in section 2.1.3.4 to read: > > The type field, which must be a positive, non-zero value, is used to > indicate the type of the element for which the information is being > maintained. Currently defined values are: > 1: the element in the hierarchy is a transaction. > 2: the element in the hierarchy is an Activity. > > Type values for Activities supporting specific extended transaction > models will be defined in the future. Each specific type will also define > the format of the activity_specific_data that may be propagated as part of > the > ActivityIdentity structure in the service context. > > Update the final paragraph in section 2.1.3.4 to read: > > Additional information may be encoded within the activity_specific_data, > and invocation_specific_data fields of the ActivityIdentity and > ActivityContext structures. It is legal for these fields to contain an > empty any. An implementation must not rely on the data that was sent > with an outbound context being available on the reply context. > The invocation_specific_data is used to carry information specific > to an implementation of the Activity service and may be used, for > example, for performance optimzations within a common domain. To > ensure integrity of the application (specifically in the case of > loop-backs between foreign and native domains), > a domain which does not understand the invocation_specific_data > any within an activity context must at least replace it with an > empty any. Such a domain is free, however, to replace the > invocation_specific_data with its own implementations specific any. > The activity_specific_data is meant to carry information which is > required for an implementation of a specific extended transaction model. > If an importing domain does not support the type of extended > transaction model in a received context i.e., it does not understand > the activity_specific_data, then it must not use the context, and should > throw BAD_CONTEXT. The above text is fine by me. > Given the ongoing discussion of this one proposal, could I suggest > that we defer its resolution to Vote 2? Fine by me. Any objections? Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 Importance: Normal Subject: Re: Proposal for 4305 To: mcl@arjuna.com Cc: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Tue, 7 Aug 2001 13:30:43 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 07/08/2001 13:33:06 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: E>5e9)M>!!aSkd92K+!! Mark, First of all, we need to recognise that changing the structure of the service context in a future RTF is going to present an interoperation headache that we won't have if we do it now. So I wouldn't want to leave that to a future RTF. What I want is to build in the flexibility that implementors find useful now; as we are implementing the Activity service specification, IBM already puts Activity service implementation-specific-data in our service contexts on a per ActivityIdentity basis. We could move this to the ActivityContext.invocation_specific_data but this becomes a minor nuisance to manage at marshal/unmarshal. We build an array of ActivityIdentities, together with any i-s-d for each one, and simply add to the ActivityContext. On the receiving end, we can unpack each ActivityIdentity and it contains everything we need. What we don't really want to do is to build the array of ActivityIdentites, then build a second, separate array of structures containing our i-s-d for each ActivityIdentity that we then need to match-up at the reciving end. Having said that, this is actually the least of my concerns regarding this proposal (but something I don't want to lose sight of). My greater concerns are: 1. Clearer descriptions of the different roles of the 'additional information' fields in the ActivityIdentity/ActivityContext structures and the different rules governing what happens if they are not understood by the receiving end. The text proposed is misleading. For example: "...The activity_specific_data is meant to carry information which is required for an implementation of a specific extended transaction model. An implementation must not rely on the data that was sent with an outbound context being available on the reply context. Because this information is likely to be specific to a given implementation of the Activity Service it is illegal for an importing domain that is different from the exporting domain to use these fields..." The final sentence above pertains to the invocation_specific_data, not the activity_specific_data. 2. A clearer relationship between the activity_specific_data and the ActivityIdentity.type field. So, I would still like to see a 3rd field for ActivityIdentity.type_specific_data, text for which I've already proposed. If we decide that we really don't want this, then I would suggest the following text to describe the use of the existing fields: Update the 4th paragraph in section 2.1.3.4 to read: The type field, which must be a positive, non-zero value, is used to indicate the type of the element for which the information is being maintained. Currently defined values are: 1: the element in the hierarchy is a transaction. 2: the element in the hierarchy is an Activity. Type values for Activities supporting specific extended transaction models will be defined in the future. Each specific type will also define the format of the activity_specific_data that may be propagated as part of the ActivityIdentity structure in the service context. Update the final paragraph in section 2.1.3.4 to read: Additional information may be encoded within the activity_specific_data, and invocation_specific_data fields of the ActivityIdentity and ActivityContext structures. It is legal for these fields to contain an empty any. An implementation must not rely on the data that was sent with an outbound context being available on the reply context. The invocation_specific_data is used to carry information specific to an implementation of the Activity service and may be used, for example, for performance optimzations within a common domain. To ensure integrity of the application (specifically in the case of loop-backs between foreign and native domains), a domain which does not understand the invocation_specific_data any within an activity context must at least replace it with an empty any. Such a domain is free, however, to replace the invocation_specific_data with its own implementations specific any. The activity_specific_data is meant to carry information which is required for an implementation of a specific extended transaction model. If an importing domain does not support the type of extended transaction model in a received context i.e., it does not understand the activity_specific_data, then it must not use the context, and should throw BAD_CONTEXT. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Given the ongoing discussion of this one proposal, could I suggest that we defer its resolution to Vote 2? Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com "Mark Little" on 06/08/2001 08:56:19 Please respond to "Mark Little" To: Ian Robinson/UK/IBM@IBMGB cc: ots-structs-ftf@omg.org Subject: Re: Proposal for 4305 > You have proposed that the ActivityContext.invocation_specific_data field > be used for the purpose > of carrying Activity service implementation-specific-data and that the > ActivityIdentity.activity_specific_data field be used for the purpose of > carrying data specific to a > particular extended transaction model. > I believe there is value in providing a means for an Activity service > implementation to scope its own > implementation-specific-data at an ActivityIdentity-level rather than an > ActivityContext-level, providing > better encapsulation of context data. Can you give me an example. What I don't want to see is us ending up with anys in every single data structure/interface simply because of "flexibility" that is never used. If we go that route then, as I pointed out when we first started the specification work, we'll end up with simply passing anys around the place and require the user to implement pretty complex, and implementation specific parsers. > While it would be perfectly possible > to build all the > implementation-specific-data for all the ActivityIdentities into a > single > Any (for example as a sequence > of structures), this might not be the most efficient or convenient > way to > marshal and demarshal a > complex hierarchy of contexts each containing its own Activity > service > implementation-specific-data. I agree it's flexible, I disagree that it's required. We have a lot of flexibility in the specification at the moment that probably won't be fully excercised for some time. I would prefer incremental changes to cover what user requirements are being unfulfilled and are deemed a necessity. If we find the single any is not sufficient then we can address it in a later RTF. The more anys we add, the more complexity in interoperation and useage we potentially add. > I believe we should design for maximum flexibility from the outset; an > Activity service implementation I agree, and disagree. From our experience of designing and building fairly complex systems over many years, users tend to require flexibility in areas we can't begin to see until people are *using* the system. If we add the flexibility we think they require, I'd take a bet that it wouldn't be sufficient, and probably wouldn't be used as much as we would expect. Let's get user feedback first. > is, of course, free to use the ActivityContext.invocation_specific_data > rather than (or even as well as) > a new field on the ActivityIdentity. > This is why I have previously suggested a new field in the ActivityIdentity > structure. Since the extended > transaction model data should ideally be tied to the ActivityIdentity type > value, I have suggested that > that ActivityIdentity.activity_specific_data be used for the Activity > service implementation-specific data > and that a new field, type_specific_data, be provided for the specific > exended transaction model data. I understand your rational, I just don't agree that it's the best way currently to address it. I think we have sufficient flexibility already built-in to the data structures to allow us to do what you mention. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203 Importance: Normal Subject: Re: Proposal for 4305 To: "Mark Little" Cc: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Thu, 23 Aug 2001 21:54:39 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 27/08/2001 08:45:58 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: EA[d9T,Ud97(W!!U3Od9 OK. If we use the proposed text but give up on the additional ActivityIdentity-specific any then we're close enough. Regards...Ian Ian Robinson, WebSphere Transactions Architecture IBM Hursley Lab Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com "Mark Little" on 07/08/2001 14:17:14 Please respond to "Mark Little" To: Ian Robinson/UK/IBM@IBMGB cc: ots-structs-ftf@omg.org Subject: Re: Proposal for 4305 > First of all, we need to recognise that changing the structure of the > service context in a future RTF is going to present an interoperation > headache that we won't have if we do it now. Agreed. But that's not an argument for adding the anys IMO. > So I wouldn't want to leave > that to a future RTF. > What I want is to build in the flexibility that implementors find > useful > now; as we are implementing the Activity service specification, IBM > already puts Activity service implementation-specific-data in our > service contexts on a per ActivityIdentity basis. If this information is not related to the implementation of a specific extended transaction model then I don't see why it is in the ActivityIdentity. If it is specific to IBMs implementation of the activity service (similar to the use of the implementation_specific_data field in the OTS context) then it should be in the ActivityContext. > We could move this to the ActivityContext.invocation_specific_data > but this becomes a minor nuisance to manage at marshal/unmarshal. We > build an array of ActivityIdentities, together with any i-s-d for > each one, and simply add to the ActivityContext. On the receiving > end, we can unpack each ActivityIdentity and it contains everything > we need. What we don't really want to do is to build the array of > ActivityIdentites, then build a second, separate array of structures > containing our i-s-d for each ActivityIdentity that we then need to > match-up at the reciving end. Having said that, this is actually the > least of my concerns regarding this proposal (but something I don't > want to lose sight of). I can understand your concern, but I think it a) breaks the model [ActivityIdentity is meant for model specific data], and b) still doesn't show a requirement for it at this level. I would like to keep the number of typeless variables in this specification to a minimum to reduce the complexity and any future headaches with interoperability. > My greater concerns are: > 1. Clearer descriptions of the different roles of the 'additional > information' fields in the ActivityIdentity/ActivityContext structures > and the different rules governing what happens if they are not > understood by the receiving end. The text proposed is misleading. For > example: > "...The activity_specific_data is meant to carry information which is > required for an implementation of a specific extended transaction model. An > implementation must not rely on the data that was sent with an outbound > context being available on the reply context. Because this information is > likely to be specific to a given implementation of the Activity Service it > is illegal for an importing domain that is different from the exporting > domain to use these fields..." > The final sentence above pertains to the invocation_specific_data, not > the activity_specific_data. Agreed. > 2. A clearer relationship between the activity_specific_data and the > ActivityIdentity.type field. > > So, I would still like to see a 3rd field for > ActivityIdentity.type_specific_data, text for which I've already proposed. > If we decide that we really don't want this, then I would suggest the > following text to describe the use of the existing fields: > > > Update the 4th paragraph in section 2.1.3.4 to read: > > The type field, which must be a positive, non-zero value, is used to > indicate the type of the element for which the information is being > maintained. Currently defined values are: > 1: the element in the hierarchy is a transaction. > 2: the element in the hierarchy is an Activity. > > Type values for Activities supporting specific extended transaction > models will be defined in the future. Each specific type will also define > the format of the activity_specific_data that may be propagated as part of > the > ActivityIdentity structure in the service context. > > Update the final paragraph in section 2.1.3.4 to read: > > Additional information may be encoded within the activity_specific_data, > and invocation_specific_data fields of the ActivityIdentity and > ActivityContext structures. It is legal for these fields to contain an > empty any. An implementation must not rely on the data that was sent > with an outbound context being available on the reply context. > The invocation_specific_data is used to carry information specific > to an implementation of the Activity service and may be used, for > example, for performance optimzations within a common domain. To > ensure integrity of the application (specifically in the case of > loop-backs between foreign and native domains), > a domain which does not understand the invocation_specific_data > any within an activity context must at least replace it with an > empty any. Such a domain is free, however, to replace the > invocation_specific_data with its own implementations specific any. > The activity_specific_data is meant to carry information which is > required for an implementation of a specific extended transaction model. > If an importing domain does not support the type of extended > transaction model in a received context i.e., it does not understand > the activity_specific_data, then it must not use the context, and should > throw BAD_CONTEXT. The above text is fine by me. > Given the ongoing discussion of this one proposal, could I suggest > that we defer its resolution to Vote 2? Fine by me. Any objections? Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 From: "Mark Little" To: "Ian Robinson" Cc: References: Subject: Re: Proposal for 4305 Date: Wed, 5 Sep 2001 12:21:12 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Filter-Version: 3.4 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `P>e9:aHe9O)~e9HI"e9 > OK. > If we use the proposed text but give up on the additional > ActivityIdentity-specific any then we're close enough. OK, that gives us a good starting point. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203 Importance: Normal Subject: Re: Proposal for 4305 To: "Mark Little" Cc: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Mon, 5 Nov 2001 21:51:13 +0000 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.8 |June 18, 2001) at 05/11/2001 22:06:32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: a)3e9aKJ!!-:F!!M& > Type values for Activities supporting specific extended transaction > models will be defined in the future. Each specific type will also define > the format of the activity_specific_data that may be propagated as part of > the ActivityIdentity structure in the service context. > Thanks....Ian Ian Robinson, WebSphere Transactions Architecture IBM Hursley Lab Tel (Ext) +44-1962-818626 (Int) 7-248626 Fax +44-1962-818626 ian_robinson@uk.ibm.com ---------------------- Forwarded by Ian Robinson/UK/IBM on 05/11/2001 21:30 --------------------------- Ian Robinson 23/08/2001 21:54 To: "Mark Little" cc: ots-structs-ftf@omg.org From: Ian Robinson/UK/IBM@IBMGB Subject: Re: Proposal for 4305 (Document link: Ian Robinson) OK. If we use the proposed text but give up on the additional ActivityIdentity-specific any then we're close enough. Regards...Ian Ian Robinson, WebSphere Transactions Architecture IBM Hursley Lab Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com "Mark Little" on 07/08/2001 14:17:14 Please respond to "Mark Little" To: Ian Robinson/UK/IBM@IBMGB cc: ots-structs-ftf@omg.org Subject: Re: Proposal for 4305 > First of all, we need to recognise that changing the structure of the > service context in a future RTF is going to present an interoperation > headache that we won't have if we do it now. Agreed. But that's not an argument for adding the anys IMO. > So I wouldn't want to leave > that to a future RTF. > What I want is to build in the flexibility that implementors find > useful > now; as we are implementing the Activity service specification, IBM > already puts Activity service implementation-specific-data in our > service contexts on a per ActivityIdentity basis. If this information is not related to the implementation of a specific extended transaction model then I don't see why it is in the ActivityIdentity. If it is specific to IBMs implementation of the activity service (similar to the use of the implementation_specific_data field in the OTS context) then it should be in the ActivityContext. > We could move this to the ActivityContext.invocation_specific_data > but this becomes a minor nuisance to manage at marshal/unmarshal. We > build an array of ActivityIdentities, together with any i-s-d for > each one, and simply add to the ActivityContext. On the receiving > end, we can unpack each ActivityIdentity and it contains everything > we need. What we don't really want to do is to build the array of > ActivityIdentites, then build a second, separate array of structures > containing our i-s-d for each ActivityIdentity that we then need to > match-up at the reciving end. Having said that, this is actually the > least of my concerns regarding this proposal (but something I don't > want to lose sight of). I can understand your concern, but I think it a) breaks the model [ActivityIdentity is meant for model specific data], and b) still doesn't show a requirement for it at this level. I would like to keep the number of typeless variables in this specification to a minimum to reduce the complexity and any future headaches with interoperability. > My greater concerns are: > 1. Clearer descriptions of the different roles of the 'additional > information' fields in the ActivityIdentity/ActivityContext structures > and the different rules governing what happens if they are not > understood by the receiving end. The text proposed is misleading. For > example: > "...The activity_specific_data is meant to carry information which is > required for an implementation of a specific extended transaction model. An > implementation must not rely on the data that was sent with an outbound > context being available on the reply context. Because this information is > likely to be specific to a given implementation of the Activity Service it > is illegal for an importing domain that is different from the exporting > domain to use these fields..." > The final sentence above pertains to the invocation_specific_data, not > the activity_specific_data. Agreed. > 2. A clearer relationship between the activity_specific_data and the > ActivityIdentity.type field. > > So, I would still like to see a 3rd field for > ActivityIdentity.type_specific_data, text for which I've already proposed. > If we decide that we really don't want this, then I would suggest the > following text to describe the use of the existing fields: > > > Update the 4th paragraph in section 2.1.3.4 to read: > > The type field, which must be a positive, non-zero value, is used to > indicate the type of the element for which the information is being > maintained. Currently defined values are: > 1: the element in the hierarchy is a transaction. > 2: the element in the hierarchy is an Activity. > > Type values for Activities supporting specific extended transaction > models will be defined in the future. Each specific type will also define > the format of the activity_specific_data that may be propagated as part of > the > ActivityIdentity structure in the service context. > > Update the final paragraph in section 2.1.3.4 to read: > > Additional information may be encoded within the activity_specific_data, > and invocation_specific_data fields of the ActivityIdentity and > ActivityContext structures. It is legal for these fields to contain an > empty any. An implementation must not rely on the data that was sent > with an outbound context being available on the reply context. > The invocation_specific_data is used to carry information specific > to an implementation of the Activity service and may be used, for > example, for performance optimzations within a common domain. To > ensure integrity of the application (specifically in the case of > loop-backs between foreign and native domains), > a domain which does not understand the invocation_specific_data > any within an activity context must at least replace it with an > empty any. Such a domain is free, however, to replace the > invocation_specific_data with its own implementations specific any. > The activity_specific_data is meant to carry information which is > required for an implementation of a specific extended transaction model. > If an importing domain does not support the type of extended > transaction model in a received context i.e., it does not understand > the activity_specific_data, then it must not use the context, and should > throw BAD_CONTEXT. The above text is fine by me. > Given the ongoing discussion of this one proposal, could I suggest > that we defer its resolution to Vote 2? Fine by me. Any objections? Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 From: "Mark Little" To: "Ian Robinson" Cc: References: Subject: Re: Proposal for 4305 Date: Tue, 6 Nov 2001 10:12:49 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-ECS-MailScanner: Scanned successfully Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _E+!!gcW!!'L*!!W%