RE: [bt-spec] BTP Issue 85 : Relationship by separate container,not containment - 0.9.0.3 solution - 0.9.0.4 revision

[Peter Furniss <peter.furniss@choreology.com>]

Further revisions relating to this issue are in 0.9.0.4, dealing with the outstanding points in 0.9.0.3 (see earlier message below)

 

a notation to clarify the characterising sets of messages in each group is defined - the most complex case is "CONTEXT_REPLY (& ENROL) & PREPARED / & CANCELLED", which is explained (in its first paragraph) as :"This combination is characterised by a related CONTEXT_REPLY and either or both of PREPARED and CANCELLED, with or without ENROL. "

 

the text on relation of BTP to application messages has been revised slightly - for CONTEXT & application message, the "meaning" now reads:

 

Meaning: the transmission of the application message is deemed to be part of the business transaction identified by the CONTEXT. The exact effect of this for application work implied by the transmission of the message is determined by the application – in many cases, it will mean the effects of the application message are to be subject to the outcome delivered to an enrolled Inferior, thus requiring the enrolment of a new Inferior if no appropriate Inferior is enrolled or if the CONTEXT is for cohesion.

 

 

All CONTEXT_REPLY & ENROL groups are allowed to use ENROL/rsp-req - the receiver of the group forwards a received ENROLLED back to the original Enroller (if the receiver ( client-side inbound interceptor/communicator) is distinct from the Superior, this requires it to substitute and remember the reply-address. The two cases below (end of original message) argue in opposite directions - but the last one (the volunteer enrollment of "remote" atoms in a cohesion) almost certainly needs to have ENROLLED back to the Inferiors. Having written the details for that, it was perverse to forbid CONTEXT_REPLY & ENROL/rsp-req when there happened not to be any application message. (perverse = it would be more difficult to implement)

 

 

The examples in the SOAP binding have been aligned.

 

The XML schema has not been changed yet.

 

(outlook is messing up the formatting of this message and won't do what I want)

 

Peter

-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 18 December 2001 13:38
To: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 85 : Relationship by separate container, not containment - 0.9.0.3 solution

The following changes in 0.9.0.3 are a response/solution to issue 85

 

 

In the first part of "Compounding messages" (page 26 of 0.9.0.3) , which also address issue 84. The addition of the term "groups" as a set of related messages is made to ease the description of A&B cases.

 

The new section "Groups - combinations of related messages" is added to define the possible related combinations, and what the particular processing is - i.e. what the semantic significance of the relatedness (since related is defined as having semantic significance, unlike bundling)

 

Changes in the section "Compounding messages" within the XML representation  (page 105) are entirely due to this.

 

The btp:related element will need to be added to the XML schema - this is not in 0.9.0.3

 

 

There are some sub-issues in the text on "Groups - combination of related messages"

 

in CONTEXT & application message, the phrase "Changes in application state resulting ..." is questioned. Replacing that by "Application effects resulting ..." would align it with the (current) overview text.

 

CONTEXT_REPLY & ENROL/no-rsp-req - there is a question on whether ENROL/rsp-req is allowed. This would cause some complications, as the ENROL would have to be forwarded to the Superior as described in the section, but then the ENROLLED will have to be sent back to the original Enroller (as well as being processed by whatever handled the CONTEXT_REPLY & ENROL group). Since the CONTEXT_REPLY&ENROL group exists to avoid having to send ENROLLED downtree, there seems no point in alloweing ENROL/rsp-req here. .

 

CONTEXT_REPLY & ENROL & application message (& PREPARED) - same comment as above (but as an "editor" paragraph, not a winword comment).. In this case, with entrollment in a cohesion by "volunteer" inferiors, they are more likely to want to know they are enrolled.

 

 

 

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX