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


Subject: [business-transaction] Jan 30 BTP Conference call




*** We need a host for the calls on February 13th and February 27th. ***


Details for this call:
  Thanks to Geoff Brown and Oracle for hosting this call.

  Noon eastern time, January 30th

  From inside the USA: 888-397-1171
  From outside the USA: 415 228 4655
  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 ...

Voice votes will be taken on the solutions proposed for the following issues
  Issues 6, 8, 17, 18, 52, 74, 77, 78, 82

A useful reference for issues 77 and 78 is the IETF RFC on URI syntax 
http://www.ietf.org/rfc/rfc2396.txt


William Z Pope
zpope@pobox.com 

BTP Issue 6 : Should the informative appendices be in the spec
Jan 29, 2002

=========================================================================
Description:

Should the informative appendices be re-instated in the spec, or left for
incorporation in the intended primer. (They were dropped between 0.6 to 0.9 as
part of the removal of explanatory and tutorial material - in consequence, the
list of authors was modified, dropping the appendix authors) 

=========================================================================
Proposed solution: 

The Glossary Appendix remains part of the specification (to be updated as
called for in issue 4). The appendices on 'Examples and Use cases', BTP and
Business Process Management' and 'BTP and Security' are omitted from the BTP
specification.  



BTP Issue 8 : Deaf Clients
Jan 29, 2002

=========================================================================
Description:

Desire for clients which can initiate transaction, and invoke application
service(s) in transactional context and terminate transaction, but cannot
listen independently because of firewall or other restrictions or policies.  


=========================================================================
Proposed solution: 

Given the ability to do RPC over request/response carriers (see Issue 7 on
SOAP RPC), this can be supported using features in the 0.9 specification.  The
Factory/Decider can be made a remote but within-the-firewall
service. (Server-side transactions).  No need to modify specification.  

BTP Issue 17 : Use of the word "peer"
Jan 29, 2002

=========================================================================
Description:

Does the word "peer" need a definition?  The first reference is : 
  "BTP recovery requires that the state information for a Superior or Inferior
   is accessible after failure and that the peer can distinguish between
   temporary inaccessibility and the permanent non-existence of the state
   information."  


=========================================================================
Proposed solution: 

Add to the glossary 

    Peer : The other party in a two-party relationship, as in Superior to
    Inferior, or Sender to Receiver  

BTP Issue 18 : Response to CONTRADICTION
Jan 29, 2002

=========================================================================
Description:

What is the response to a CONTRADICTION supposed to be?  Especially a 
CONTRADICTION to a hazard. 

Current text: 
    "CONTRADICTION Sent by the Superior to an Inferior that has taken an
     autonomous decision contrary to the decision for the atom. This is
     detected by the Superior when the 'wrong' one of CONFIRMED or CANCELLED
     is received. CONTRADICTION is also sent in response to a HAZARD message." 


=========================================================================
Proposed solution: 

No change to the existing text.  CONTRADICTION is always the last message.

BTP Issue 52 : Forms of PREPARE 
Jan 29, 2002

=========================================================================
Description:

Page 38, last paragraph before PREPARED, talks about different forms of
PREPARE.  So what form is used for preparing a (sub-)coordinator? 

=========================================================================
Proposed solution: 

Resolved by agreed solution to issue 79 : Normalising the message set. 

BTP Issue 74 : WrongState from CONFIRM_ONE_PHASE
Jan 29, 2002

=========================================================================
Description:

On line 1828 of the word copy of spec version 0.9.0.1 a fault reads:
"WrongState: if a PREPARE has already been received from this Inferior."  
This should be "sent to this Inferior." 


=========================================================================
Proposed solution: 

Make the change suggested - "sent to this Inferior"

BTP Issue 77 : Inferior Identification
Jan 29, 2002

=========================================================================
Description:

An inferior is identified in messages in the outcome (superior:inferior)
relationship by the combination of inferior identified and inferior address,
and in the control relationship (Terminator:Decider) by an inferior
handle. However, in many cases, the inferior handle is also known to the
inferior and it would be convenient to use when available.  

It would helpful to have a compound construct "inferior identification" which
is a choice between (inferior address, inferior identification) and (inferior
handle).  


=========================================================================
Proposed solution: 

The proposed solution for issue 78 : "Addresses used for identification" makes 
the inferior-handle unnecessary.  

- Delete the "inferior handle" as a field of ENROLLED.  

- In the "inferior-list" parameters of various messages, make it a list of
  inferior-identifiers, not inferior-handles. 

- In the last paragraph on the "CONTEXT_REPLY & ENROL & application message 
  (& PREPARED)" group, change the existing reference to "inferior-handle on
  ENROLLED" to "inferior-identifier on ENROL".  

- Change other references to "inferior-handle" to "inferior-identification"
  and adjust unambiguity desriptions appropriately.  

- Align the XML 




BTP Issue 78 : Addresses used for Identification
Jan 29, 2002

=========================================================================
Description:

Many messages have the address of their sender as a parameter, only to
disambiguate the identifier, because the other side already knows the sender's
address.  
There is no protocol need for this to be a set of addresses - it could just be
one, with the rule that a single address matches a set of addresses if it is
the same as any member of the set.  There is some text on this already, but it
needs checking.  


=========================================================================
Proposed solution: 

Make Identifier globally unambiguous, rather only unambiguous within the scope
of the related addresses.  Syntactically, make it a URI.  
Drop the disambiguating addresses from messages, and modify the text for the
corresponding identifier.  

CONTEXT_REPLY - delete superior-address 

STATUS - delete responders-address

RESIGN, PREPARED, CANCELLED, CONFIRMED, HAZARD, INFERIOR_STATE - delete
address-as-inferior

REDIRECT will need changing but this can be handled under Issue 29 :
Redirection.  

BEGUN will need changing but this is can be handled under Issue 30 : Assume
that coordinators are potential sub-coordinators.  

TRANSACTION_CONFIRMED, TRANSACTION_CANCELLED - delete address-as-decider 

INFERIOR_STATUSES - delete responders-address 

Replace the text on Identifiers in the XML section, and move it to the
beginning of the abstract message section. New text to be:  

    Identifiers shall be URIs. 

    Note - Identifiers need to be unambiguous over all the systems that might
    be involved in a business transaction and over indefinite periods of
    time. Apart from their generation, the only operation the BTP
    implementations have to perform on identifiers is to match them.  

In the XML, remove the fields corresponding to the removed abstract parameters  

In the section on abstract messages, addresses (line 1051 in 0.9.1) delete the
sentence "In cases b) and c), the identifier is to some extent redundant,
although interoperation requires that it always be present."  

In the model, state the identifier : address relation. In summary (to be
revised to fit with the rest of the model):  

    An Identifier is a globally unambiguous identification of the state
    corresponding to one of Decider, Superior or Inferior. Where a single
    actor has more than one of these roles (at the same node in the same
    transaction), the Identifiers may be the same or different, at
    implementation option - they are distinguished by which messages the
    Identifier is used on. (A Superior has only one superior-identifier,
    although it may be in multiple Superior:Inferior relationships, each with
    a separate state in terms of the state table).  

    The state identified by an Identifier can be accessed by BTP messages sent
    to any of the addresses supplied with the Identifier in the appropriate
    message (CONTEXT, BEGUN, ENROL), or as updated by REDIRECT. An Identifier
    itself has no location implications. (An Identifier that happens to be a
    URL is treated as an opaque value by BTP)  

    Identifiers are specified as being globally unambiguous - the same
    Identifier only ever identifies one Decider, Superior or Inferior over all
    systems and all time. In practice, an Identifier could be re-used if there
    is no possibility of the colliding values being confused. However
    implementations are recommended to use truly unambiguous Identifiers
    (e.g. URI's using UUID).  




Issue 82: ENROL related to application message
Jan 29, 2002

=========================================================================
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:
 
  This was deferred during the January 16th conference call.

  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. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC