[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] Jan 16th BTP conference call, details and agenda
Hello, I am going to be out of the office from Tuesday January 15th until Thursday January 24th. Bill Cox from BEA has agreed to chair the conference call this wednesday. Call Details: Thanks to Geoff Brown and Oracle for hosting the call. 888-397-1171 Passcode: BTP Leader: Geoffrey Brown Agenda: 1. Greet, rustle, settle in (5 minutes) 2. Establish minute taker for this meeting 3. Call roll 4. Accept previous minutes 5. Set agenda 6. general meeting, discussion, votes 7. review outstanding action item Items for Agenda: - Votes on issues See below ... - Time frames: Our target date for release of the specification is mid-February. Due to the holidays (or whatever) we are not moving quickly enough to hit that date. A possible way to address this is to develop specific work items and have people sign up to address them. These would most likely be in the form of producing suggested solutions to specific issues. I want to put up for discussion a possible revised timeline. a) Primer avalable, fully cooked, February 13th. b) Revised draft of spec 0.9.5 c) March 27th 0.9.9, available for review towards committee spec, 4 - 6 weeks review period. d) April release from committee. - Discussion of the Primer outline Voice votes will be taken on the proposed solutions to the following issues: Issue 7 Issue 57 Issue 62 Issue 79 Issue 80 Issue 82 Issue 83 Issue 84 Issue 85 Issue 86 William Z Pope zpope@pobox.com
Issue 7: SOAP RPC ========================================================================= Description: Existing SOAP binding does not allow for use of SOAP RPC model, which is inefficient, and makes it hard to construct thin clients without listening capacity, using standard SOAP programming toolkits. ========================================================================= Proposed solution: This solution, including the request/response exploitation rules, is included in draft 0.9.0.4 SOAP RPC will not be used for the BTP-alone case (it may be used for the application-with-BTP, but that isn't the application's option, not ours). The btp:transmission element will not be present. However, to allow http responses to be used for BTP messages, rules to define the use of request/response carrier protocols are defined (the "request/response exploitation rules"). These rules are defined in general but apply to the SOAP binding. The key features are: a) if a BTP message is received on a carrier request, any message to be sent by the receiver back to the sender of the request can be put in the carrier response, or can be sent on a new request in the opposite direction. b) the choice of response or new request is freely up to the receiver (of the request) in the case where a real address is available as the target of the btp message and this corresponds to the sender of the original carrier request c) if the target address is known but different, obviously the message must go on a new carrier request d) if no target address is available (which can only be because the abstract message had a reply address, but the sender did not supply one), then the message MUST go on the carrier response. The last rule allows the sender of one of the BTP request/response messages (e.g. any of the terminator->decider messages, REQUEST_STATUS etc) to force the btp reply to come back on the carrier response, by not sending any value for the reply-address. The text on soap encoding, and the example of btp over SOAP are modified to have a null encodingStyle value. ========================================================================= Supporting Material: Draft 0.9.0.3 contained the following suggested solution: Create outer wrappers <btp:transmission> and <btp:transmissionResponse> to surround existing <btp:messages>. Receiver can choose to send reply messages back in either wrapper, and can choose to use response message of RR carrier such as HTTP, or to send the reply as an independent one-way or RPC. Empty SOAP envelope or carrier ack to be ignored. Original sender must be prepared to receive messages either on carrier response or via listener. If reply-address is empty then reply must go in carrier response. Illegal value if carrier is non-RR. Text 0.9.0.4 has a revised solution, removing the btp:transmission and btp:transmissionResponse wrapper elements, and stating that BTP always uses document literal style. Otherwise, 0.9.0.4 is basically the same - in particular the request/response exploitation rules are the same.
BTP Issue 62 : Names of the relationships ========================================================================= Description: The two distinct relationships in BTP are called "Superior:Inferior" and "Terminator:Decider" in 0.9. These names are cumbersome, and in the latter case, not very accurate - the client-end application to coordination-facility relationship includes Initiator:Factory. Simple names would clarify. ========================================================================= Proposed solution: These changes are included in draft 0.9.0.4 Use the names "outcome" and "control" as headings for the sets of roles and messages, introducing them in the relationships section. In section on relationships, add the following to the paragraph after the list of events: The various particular relationships can be grouped as the "control" relationships - primarily Terminator:Decider, but also Initiator:Factory; and the "outcome" relationships - primarily Superior:Inferior, but also Enroller:Superior. At the beginning of the following paragraph, change "primary" to "groups of". In the headings "Roles involved in ..." change "Superior:Inferior" to "outcome", and "Terminator:Decider" to "control", and make "relationship" plural. In the abstract message list, add headings (for the separate messages): - Messages not restricted to outcome or control relationships - Messages used in outcome relationships - Messages used in control relationships ========================================================================= Supporting Material: This change has been applied in 0.9.0.4, using the names as convenient labels for the sets of relationships - outcome includes both Superior:Inferior and Enroller:Superior, control includes both Initiator:Factory and Terminator:Decider. The names are used semi-informally - as headings for the sublists of abstract message types.
Issue 79: Normalising the Message Set ========================================================================= Description: The BTP abstract message set should be split into subsets, each applicable to one of the "relationships" in BTP. The division should be reflected in the XML. BTP Draft 0.9 covers the two "relationships" (control, outcome are names for these suggested in issue 62), but has a single set of messages. Some messages are used in only one relationship (REQUEST_CONFIRM in control, ENROL, CONFIRM in outcome), but some are used in both (PREPARE, CANCEL). The ones used in both tend to have some parameters used only in one case, some only in another. Splitting the message set will not cause any difference in functionality - the same semantics can be exchanged between the various roles. It will simplify the abstract message specification, and the xml schema, and in turn should make implementation simpler (especially for implemenations that choose to support only the Superior:Inferior relationship and use an internal API for transaction control by the application. ) It should also make the conformance discussion and specification easier. For XML, the names can easily be qualified by namespace, and it seems it will be simplest to invent something similar for the abstract messages - thus PREPARE would become CONTROL.PREPARE and OUTCOME.PREPARE. There should also be a separate basic group, which would include things like FAULT and CONTEXT that are used in both relationships. Possibly the Initiator:Factory relationship (using BEGIN, BEGUN) should have its own group (Factory) Note: The choice of a single message set was made on the principle of conservatism - in adding the coordinator and cohesion control messages [omitted from 0.6, which had not caught up with tc decisions], we were considered making two disjoint message sets, but concluded this would appear as to great a change. ========================================================================= Proposed solution: Presented here in outline, draft 0.9.0.4 includes the changes in detail. Rename the messages used in both outcome and control, as in the table below. Use the groupings (general, outcome, control) as headings in the abstract message set, reordering the messages appropriately. Separate out the parameters and paragraphs explaining the different parts where one old message becomes a pair of new ones. REQUEST_STATUS continues to be sent to any transaction tree node, and so can REQUEST_INFERIORS_STATUS, but they can reject the request with a FAULT(StatusRefused) (except in the case of REQUEST_INFERIORS_STATUS from Terminator to Decider). Separate old CANCEL/whole and CANCEL/inferiors (both Terminator:Decider) into CANCEL_TRANSACTION and CANCEL_INFERIORS (original CANCEL is Superior:Inferior). Old Name Name in Outcome Name in Control ---------------------------------------------------------------------- BEGIN BEGIN BEGUN BEGUN ENROL ENROL ENROLLED ENROLLED RESIGN RESIGN RESIGNED RESIGNED PREPARE PREPARE PREPARE_INFERIORS PREPARED PREPARED CONFIRM CONFIRM CONFIRMED CONFIRMED TRANSACTION_CONFIRMED CANCEL CANCEL CANCEL_TRANSACTION CANCEL_INFERIORS CANCELLED CANCELLED TRANSACTION_CANCELLED CONFIRM_ONE_PHASE CONFIRM_ONE_PHASE HAZARD HAZARD CONTRADICTION CONTRADICTION SUPERIOR_STATE SUPERIOR_STATE INFERIOR_STATE INFERIOR_STATE REQUEST_CONFIRM CONFIRM_TRANSACTION REQUEST_STATUSES [1] REQUEST_INFEROR_STATUSES INFERIOR_STATUSES [1] INFERIOR_STATUSES REDIRECT REDIRECT ---------------------------------------------------------------------- [1] - REQUEST_INFERIOR_STATUSES can be sent to any transaction tree node. Whether it replies is its choice, and whether it has any inferiors can be inferred from the replying INFERIOR_STATUSES. (both this, and REQUEST_STATUS are really "management" messages, and how the Status_Requestor got hold of the address, and which one it really is, is out of our scope). ---------------------------------------------------------------------- The following do not have their names changed: REQUEST_STATUS, CONTEXT, CONTEXT_REPLY, STATUS, FAULT ---------------------------------------------------------------------- Align the xml definitions with the changes above, but keeping a single schema and namespace for the messages. ========================================================================= Supporting Material:
Issue 80: CONTEXT_REPLY unnecessary for CONTEXT/cohesion ========================================================================= Description: There appears to be no requirement derived from "checking" for a CONTEXT_REPLY to be received if the CONTEXT was for a cohesion. CONTEXT_REPLY for an Atom is to ensure that all attempted enrols for the atom worked, and avoid risk of an "orphan" inferior that the coordinator doesn't know about when it confirms. If there were such, the atom could apparently confirm when work has been done in the atom that isn't known about - the rest of the atom confirms and this orphan will (probably) eventually cancel. To prevent this, checking rules apply - until the CONTEXT_REPLY comes back, confirmation is not allowed. But with a propagated *Cohesion* CONTEXT, there is no reason why Inferiors can't be missed out. The Terminator will determine the confirm-set on the basis of which Inferiors are enrolled - if it has an acceptable set, but there is a late-arriving ENROL, that would-be inferior just gets missed out. There is a possibility that something that tried to ENROL in a Cohesion but failed to contact the Superior might want to send CONTEXT_REPLY/repudiated back towards the application initiator to say that there was a problem. CONTEXT_REPLY for a cohesion may also be needed in the one-shot case (see Issue 84 on one-shot). ========================================================================= Proposed solution: Further details are in draft 0.9.0.4, in particular in the related group text for CONTEXT & application message and CONTEXT_REPLY & ENROL. Accept the concept as proposed - for a CONTEXT/cohesion, there is no requirement to ensure that all the propagations of the CONTEXT are "counted back" with either CONTEXT_REPLY/completed or CONTEXT_REPLY/related and successful enrollment. An Inferior attempting to enrol with a cohesive superior shall have the ability to ensure its enrollment by sending CONTEXT_REPLY/repudiated if its ENROL fails. If using ENROL/no-rsp-req, sent with CONTEXT_REPLY, it can achieve the same effect by setting CONTEXT_REPLY/related; CONTEXT_REPLY/completed & ENROL/no-rsp-req means the failure of the enrollment can be ignored - this is only to be allowed if the CONTEXT was atomic.
Issue 82: ENROL related to application message ========================================================================= Description: We don't currently state that an ENROL message can be related to an application response. One ought to be able to have an application where the context (almost certainly a CONTEXT/cohesion) is made available, but the first specific application message is sent from the inferior-side to the superior-side (i.e. this isn't client-server at all). This would require an ENROL to be related to some application message. ========================================================================= Proposed Solution: Allow ENROL to be related to application messages. As with CONTEXT and application messages, the meaning of the relation is application-specific. Details are in section "CONTEXT_REPLY & ENROL & application message (& PREPARED)" in draft 0.9.0.4 , where the meaning is defined as Meaning: the relation between the BTP messages is as for the preceding groups, The transmission of the application message (and application effects implied by its transmission) has been associated with the Inferior identified by the ENROL and will be subject to the outcome delivered to that Inferior. In the SOAP binding subsection "Mapping for BTP messages related to application messages", the related messages are stated as CONTEXT and ENROL. ========================================================================= Supporting Material: The ID and REF stuff has been removed in 0.9.0.4, but the main text is unchanged from 0.9.0.3 The proposed resolution of the issue affects the SOAP binding in so far as any reference to CONTEXT becomes CONTEXT or ENROL as the messages that can be related to application messages. As for CONTEXT, the precise meaning of the relationship to application messages is application specific.
Issue 83: BTP message related to *part of* application message ========================================================================= Description: In the SOAP bindings, any and all application message in the SOAP-Body is related to the appropriate BTP messages in the SOAP-Header. It is possible to conceive of applications where a compound *application* message has parts that are intended to be in one BT, some in another (almost certainly atoms within the same cohesion). A relationship between a particular BTP message (CONTEXT or ENROL) and part of an application message could be indicated using the ID and REF mechanisms of XML. There would be significant implications for the application at each end, which has got to sort out which BT applies, but the basic protocol mechanism would be easy to specify. ========================================================================= Proposed Solution: Do NOT specify a mechanism to support this - leave it to the application to determine how such multiple relationships are represented. But allow multiple CONTEXTs and ENROLs in a SOAP Header, without stating any implied semantic. Add a note in the subsection "Mapping for BTP messages related to application messages": Note - An application protocol could use references to the ID values of the BTP messages to indicate relation between BTP CONTEXT or ENROL messages and the application message. This is included in draft 0.9.0.4. ========================================================================= Supporting Material: Premise Only CONTEXT and ENROL messages are related (&) to application messages. If there is only one CONTEXT or one ENROL message present in the SOAP Header, it is assumed to be related to the whole of the application message in the SOAP Body. If there are multiple CONTEXT or ENROL messages, any relation of these BTP messages shall be indicated by application specific means. Note 1 - An application protocol could use references to the ID values of the BTP messages to indicate relation between BTP CONTEXT or ENROL messages and the application message. Note 2 - However indicated, what the relatedness means, or even whether it has any significance at all, is a matter for the application. That puts things back were they were before, with ID's defined in the XML, but not used in general normative manner. Using them requires something special in the application coder/decoder (marshall/unmarshall, whatever), though its an easy enough thing to implement in the BTP part (just build a table of ID -> context mappings, which the application can do lookups into). All the fun part is in the application sorting itself out, but that isn't our problem.
Issue 84: What determines one-shot is used ========================================================================= Description: Draft 0.9 says that one-shot (ENROL and PREPARED with CONTEXT_REPLY on application response) is a specialisation (senders option) of one-wire, because it is specified that the inferior-side decides if it can do one-shot by matching the binding addresses to the address for the application response. There are various problems with this - among them, it assumes the service-side has an address for the application response to match against, rather than just a pending http response. Since application request/response is the most likely use of one-shot, this is rather important. An alternative approach is to assume that the service side knows (by application/configuration) that it should do one-shot replies, regardless of the superior address. ENROL and PREPARED are sent with the CONTEXT_REPLY. A possible complication is that the Superior's address is different from the reply address for the application (or rather the destination of the CONTEXT_REPLY). However, in this case the receiver of the CONTEXT_REPLY (the client-side interceptor/communicator, probably) will know the superior's address (it can/must be assumed to - since it put the CONTEXT there, that is reasonable) and can forward the ENROL and PREPARED to there. This implies ENROL and PREPARED must be related only to the CONTEXT_REPLY for their transaction. ========================================================================= Proposed Solution: This solution assumes the proposed solution for Issue 85 has been accepted and that related groupings and the defined procedures are defined. The decision to use one-shot is determined by the Inferior (server) side, subject to application and configuration constraint. Text to implement this is included in draft 0.9.0.4 , in changes in "Compounding messages" in the abstract message section, and in the detailed specification of the related group "CONTEXT_REPLY & ENROL & application message (& PREPARED)". The answer to the question itself is stated in the last paragraph of the "compounding messages" section: Whether the "one-shot" mechanism is used is determined by the implementation on the responding (Inferior) side. This may be subject to configuration and may also be constrained by the application or by the binding in use.
Issue 85: Relationship by separate container, not containment. ========================================================================= Description: Draft 0.9 specifies that relationship between btp messages is represented by containment of one in another. However, this doesn't fit well with most of the btp:btp related cases - CONTEXT_REPLY, ENROL, PREPARED especially. It also requires the relatedness to have a polarity, which isn't always easy to define. All that is actually needed is to define what processing or other semantic implications there are in relating particular types of message, and have a minimal way of expressing that the messages are related. ========================================================================= Proposed Solution: These changes are included in draft 0.9.0.4 available on the BTP web site. Check that document for further details. This proposal is also related to the proposed solution to issue 80. Change the first part of "Compounding messages" to define the term "group" for a set of related (&) messages, "bundle" for a set of unrelated messages (i.e. the combination has no semantic significance). State that groups have defined semantics, that only certain combinations of messages can be &-grouped, and that the addressing of such follows specific rules for each group. Bundles are created as desired under the constraint only that the binding address in the target addresses match. Add a new section "Groups - combinations of related messages" at the abstract message section to define the possible related combinations, and what the particular processing is - i.e. what the semantic significance of the relatedness. Define a syntax for the names of the groups to indicate that some messages may not be present (this just reduces the number of procedures that have to be defined) Groups are: - CONTEXT & application message - CONTEXT_REPLY & ENROL - CONTEXT_REPLY (& ENROL) & PREPARED / & CANCELLED - CONTEXT_REPLY & ENROL & application message ( & PREPARED) - BEGIN & CONTEXT - BEGUN & CONTEXT Define a new XML element "relatedgroup" to be the container for groups. Use this in the examples of SOAP binding. Define the meaning of the relationship between CONTEXT & application message as: 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. Allow CONTEXT_REPLY & ENROL with both reply-requested and not for the ENROL. Specify the rules to ensure that if the enrol fails, the transaction won't commit (see also proposed solution of Issue 80). 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. ======== end orig ============== 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
Issue 86: Reply address on CONTEXT, target address on CONTEXT_REPLY ========================================================================= Description: There appears to be a need for a reply address on CONTEXT as an abstract message, to be the target address of CONTEXT_REPLY. For one-way application messages and a CONTEXT/atom, the CONTEXT_REPLY must be sent back somewhere. When CONTEXT is sent in relation to an application request in a request/reply protocol, there normally won't need to be a reply address on the CONTEXT, as the CONTEXT_REPLY will be sent on the application response. ========================================================================= Proposed Solution: Add reply-address to CONTEXT and target-address to CONTEXT_REPLY. In abstract message definition of CONTEXT, add "reply-address" as new parameter, with explanation reply-address the address to which a replying CONTEXT_REPLY is to be sent. This may be different each time the CONTEXT is transmitted, it refers to the destination of a replying CONTEXT_REPLY for this particular transmission of the CONTEXT. Add "BEGIN and BEGUN" at end of the penulitmate paragraph of CONTEXT definition, (this is just a correction, not directly related to the issue). In abstract message definition of CONTEXT_REPLY, add parameter "target-address", with explanation: target-address the address to which the CONTEXT_REPLY is sent. This shall be the "reply-address" from the CONTEXT. Add the reply-address to CONTEXT and target-additional-information to CONTEXT_REPLY as optionals in XML definitions.
Issue 57: XML Schema applicable to more than SOAP ========================================================================= Description: The XML schema for the messages is given under the heading 'XML Schema for SOAP Bindings'. This would seem to suggest that this XML schema is tied to this particular binding and there could be other XML schema for other bindings. I do no think that is what is intended. I therefore propose that an 'XML Schema' section is added following the specification of the message in abstract form and that this sections (and any other bindings that use the XML schema) reference the one XML schema specification. ========================================================================= Proposed Solution: This is included in draft 0.9.0.4. Delete the word "XML" in the first line of the binding profoma section. Change the BTP message representation in the proforma text to: BTP message representation: This section will define how BTP messages are represented. For many bindings, the BTP message syntax will be as specified in the XML schema defined in this document, and the normal string encoding of that XML will be used. Delete "for SOAP bindings" from heading "XML Representation for SOAP bindings".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC