[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: TC May 24 con call minutes
May 24, 2004 OASIS Business Transaction TC
* Details
Thanks to Choreology for hosting this call.
Dial in: +44 208 322 2500
Access code: 558076
* Agenda:
- Minute taker
- Call roll
- Vote on previous minutes
- General
- Issues
* Attendees
Mark Little no
Bill Pope present
Sazi Temel no
Tony Fletcher present
Martin Chapman present
Robert Haugen present
Alastair Green present
Peter Furniss present
Alex Ceponkus leave-of-absence
Doug Bunting present
Meeting was quorate.
* Vote on Previous Minutes
Voted and accepted
* General
** Next conference call
Alex is not available at the usual date and time for this
call or for the next two calls. It was discussed that Alex
was an important part of resolving the last two issues. The
chair will try to establish a date and time when Alex and a
quorum of the TC can meet.
* Issues
** Closed last meeting
- Issue ex-7 and Issue: ex-3
- Issue maint-7
** Closed this meeting
- Issue maint-11: Allowing repeat cancel
- Issue maint-12: Address priority attribute
- Issue - ex-9: participant identification in context reply
- Issue - ex-10: acknowledgements for Long Running Transactions
** Open issues
- Issue - maint-13: CONFIRM_ONE_PHASE report-hazard default
- Issue - ex-8: BTP-aware web-services need to declare their
BTP-awareness
* Actions
1. Peter: issue ex-8. Investigate possibilities for policy
expression. See extra issue 8 discussion below.
2. Bill: next meeting. Establish date/time when Alec and a
quorum of the TC can get together to address final two
issues.
** Issues Votes and Discussion
*** Issue maint-11: Allowing repeat cancel
Proposed: Peter; Seconded: Tony;
PROPOSAL PASSED UNOPPOSED.
Under discussion at close of last meeting.
**** Submitter: Alex Ceponkus
**** Description:
The existing state tables insist that an Inferior that has
cancelled must immediately go to a state where there is no
knowledge of the transaction (z) and respond to a repeated
CANCEL with an INFERIOR_STATE/unknown message. In reality,
an iimplementation is likely to still hold state which
would allow it to reply CANCELLED again, for some time -
eventually it will probably forget the cancelled
transaction completely. Forcing immediate ignorance is
unnecessary - implementations should be allowed, but not
required to send a repeat CANCELLED if a repeat CANCEL is
received.
**** Proposal - Peter Furniss
Add additional state z2, entered on sending CANCELLED
where this currently transits to z. If an imbound
message is received, transit to a new query state (y3),
which is exitted by resending CANCELLED, reverting to
z2. Disruption (loss of volatile information) should
cause a transition to existing z. (Thus the current
behaviour can be treated as a disruption I.)
*** Issue maint-12: Address priority attribute
Proposed: Tony, Seconded: Alastair
PASSED UNOPPOSED
**** Submitter: Alex Ceponkus
**** Description:
Main body of spec mentions an address priority attribute,
but this attribute is not found in the XML.
**** Proposal: Alex Ceponkus
- Add: priority="...value..."? attribute to
btp:some-address element on line 3452 (of BTP 1.0 PDF.)
- Add: "The lower the value, the higher the priority." to
address description on line 3466 (of BTP 1.0 PDF.)
- Add: priority? attribute to superior-address elemment in
CONTEXT abstract xml. line 3496
- Add: priority? attribute to inferior-address elemment in
ENROL abstract xml. line 3600
- Add: priority? attribute to new-address element in
REDIRECT abstract xml. line 3819
- Add: priority? attribute to decider-address element in
BEGUN abstract xml. line 3844
- Add: priority? attribute to inferior-address element in
BEGUN abstract xml. line 3847
- Add: <attribute name="priority" type="positiveInteger"
use="optional" default="1"/> to address type in schema
(line 57?)
*** Issue - maint-13: CONFIRM_ONE_PHASE report-hazard default
DEFERRED
**** Submitter: Alex Ceponkus
**** Description:
CONFIRM_ONE_PHASE report-hazard has a default, and is not
consistent with report-hazard found on CONFIRM_TRANSACTION
and CANCEL_TRANSACTION.
**** Proposal: Alex Ceponkus
- Remove "Default is false." from report-hazard element
description found in section 7.7.11 CONFIRM_ONE_PHASE.
- Remove bold style from "false" in confirm-one-phase
abstract xml. line 3741
- Remove: minOccurs="0" default="false" from report-hazard
element in confirm-one-phase (line 346 of schema.)
**** Discussion
Peter: This is wrong. CONFIRM_ONE_PHASE should not have a
report-hazard parameter.
*** Issue - ex-9: participant identification in context reply
Proposed: Peter; Seconded: Tony
PASSED UNOPPOSED
**** Submitter: Peter Furniss
**** Description:
CONTEXT is commonly sent in association with an
application message, propagating the business
transaction and telling the receiving application that
work performed as a result of the application message
should be part of the business transaction. However,
with cohesionss, there is a need in some applications
to identify a particular inferior (participant) as
being responsible for some piece of application
work. For example, an invitation (say request for
quote) may be 'broadcast' (in some way) with an
associated context for a cohesion. Responding
applications can submit as many quotes as they wish,
each corresponding to a separately enrolled
inferior. The initiating application then chooses the
successful quote(s) and confirms only those. To do
this, the initiating application of course needs to
know which inferior (as visible to it, via the
coordinator) corresponds to which quote.
There are already several ways that this can be done
with BTP, but they are all rather
application-specific. At present, one could:
a) set the inferior name qualifier on the enrol to a
field that is present in the application response
(such as the quote number)
b) put the inferior identifier as a field of the
application message
c) send the ENROL message in the header of the
application message (using the one-shotting
optimisation - if the carrier supports it, and it
is appropriate for the configuration).
None of these could readily be supported by generic
software in the way a propagated context could be in
the opposite direction. There should be some general
way.
**** Possible resolutions: Peter Furniss
A possibility would be to allow an inferior identifier
to be placed in the CONTEXT-REPLY, which would have
similar semantics to having an
CONTEXT-REPLY&ENROL&application message related group
as far as association was concerned.
Alternatively, the presence of an inferior name
qualifier on a CONTEXT-REPLY could be defined as
having the similar meaning.
Note that both of these are essentially using
CONTEXT-REPLY as just the standardised carrier of this
information, rather than invent another message
(REVERSE-CONTEXT ?) just for this purpose.
**** Proposal: Peter Furniss
Allow a CONTEXT-REPLY to contain an inferior identifier
and define an additional related group CONTEXT_REPLY &
Application Message, whose meaning is defined as (this is
modified from the CONTEXT_REPLY & ENROL & Application
Message text at 7.9.4):
This related group applies only if the CONTEXT_REPLY
message contains an inferior identifier value. In this
case the transmission of the Application Message (and
application effects implied by its transmission) has been
associated with the Inferior whose identifier is in the
CONTEXT_REPLY and the effects will be subject to the
outcome delivered to that Inferior.
(The rest of the text for the related group is left to the
editing process).
*** Issue - ex-10: acknowledgements for Long Running Transactions
Proposed: Peter; Seconded: Tony;
PASSED UNOPPOSED
**** Submitter: Alastair Green
**** Description:
Ability to support long-running transactions is a
design goal of BTP. In practice BTP does not support a
useful feature that prevents idle network chatter
during long (and expected) pauses in a conversation.
This arises from product implementation experience.
Any protocol message that will (in theory, subject to
implementation level administrative or deployment
overrides) be resent indefinitely until a state-moving
message is received "in reply", should be
capable of receiving a receipt-acknowledgement, whose
reception can be interpreted to mean: I would prefer
you not to resend the message I have just received. I
will reply in my own good time, and I estimate that
this time will be no less than X seconds away.
Absent such acks, it is very difficult to obtain the
appropriate balance between fault-tolerance and good
network citizenship. Customers don’t like excess
network traffic.
The recoverable nature of all retriable conversations
ensures that the use of a receipt-ack will not
terminate the conversation prematurely or
wrong-headedly.
The SUPERIOR_STATUS/prepared-received message might be
used as a model or basis for the syntax of such a
message.
**** Proposal: Peter Furniss
I think the additional messages would be:
INFERIOR_STATUS/prepare-received
INFERIOR_STATUS/confirm-received
INFEIROR_STATUS/cancel-received
and
SUPERIOR_STATUS/confirmed-received
SUPERIOR_STATUS/cancelled-received
the superior_status messages would only be used when the
inferior had made an autonomous decision, and the superior
didn't know the proper decision yet.
None of these would cause a state change. There is no need
for a "response-requested" version of these - normally the
receiver will be in the state corresponding to having just
sent the message. In the few cases where it is possible
for the receiver to have moved on, the receiver could
resend the new message (e.g. after sending CANCEL, receive
INFERIOR_STATUS/prepare-received : could resent CANCEL).
Sending the expected time (X) till decision is made would
seem to be an item for a qualifier.
Add the new parameter values to *_STATUS proposed above.
Add a new standard qualifier "expected time till state
change" that can be sent on any message to give an
indication of how long the sender thinks it might be
before it does something interesting.
The message and the qualifier are informational - they do
not cause state change, they do not forbid the sender from
changing state much earlier, they do not commit the sender
to changing state at the time stated, they do not change
the persistence/recovery requirements implied by BTP.
*** Issue - ex-8: BTP-aware web-services need to declare their BTP-awareness
**** Submitter: Peter Furniss
**** Description:
There is currently no specified or recommended way for
an application that supports BTP, e.g. a web-service
that requires a BTP context to be present in the SOAP
headers of an invocation, to state that it has this
requirement.
There should be a means at least for application
interfaces defined using WSDL to state that they
require a BTP context and will return a BTP
context-reply.
**** Discussion
***** Peter's original email:
I believe there at least three ways of doing this, though
I'm not sure of the details offhand:
a) define an alternative wsdl binding, based on normal
soap/http (say) with the header requirement (stated as
requiring btp:messages, or as btp:context, as desired)
b) define the context (etc.) as a message part, and the
(regular) binding states that that part goes in the header
c) define assertions that can decorate the wsdl. ws-policy
would seem to be a way of doing this. I would imagine it is
possible to define an assertion (which is essentially just
a uri:specification text linkage) that could be used in
ws-policy *and* could be used in ws-wsdl-decoration.
Choreology have done some work on a), defining such a
binding (takes about a page and a half) but not put it out
in public yet.
a) and c) are both ways of passing flags to tools to tell
them to include "interception" in the processing of the
soap messages.
***** Doug:
OASIS WSPL in XACML is a possible alternative to
WS-Policy.
***** Martin
WS-RM, WS-Reliability TC
Features and properties from WSDL 2.0, added a compositor.
***** Peter
Can we do this in a grammar independent way, just indicate
what we want to say and leave it up to the various
grammars to determine the syntax of saying it. Possibly
done using a URI.
Peter will take an action item to follow up on these
various specifications and see how this might apply.
William Z Pope office: +1 603 373 0598
zpope@pobox.com mobile: +1 603 502 4490
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]