[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