OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[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]