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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

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


Subject: proposed charter


At the face-to-face models meeting we had in London on the 3rd of April I promised to put together a charter for this subcommittee and send it round for others to see and suggest modifications if required. Here it is:
 
The goals of this subcommittee as far as I see them, and as per the discussions we had on the 3rd are (comments in []):
 
(i) to produce a set of use cases for business (web) transactions. All of these use cases may not necessarily be addressed by the final BTP submission, but we hope to have a protcol that can meet the requirements of the most common subset (as defined by this subcommittee). [Can anyone who has a use case(s) please email them in ASCII or Word to Savas Parastatidis (savas@arjuna.com) and he'll collate them into a single document?]
 
(ii) we shall identify the actors ("participants") within a business transaction, and produce a Definition of Terms, which will allow us (and others) to talk about what it means to execute and participate within a business transaction. We can also then use this to define exactly the scope of our work such that we can say which actors we do and do not consider in the submission. [We already have a good starting point in the latest document send by Choreology and discussed at some length on the 3rd, and have an initial set of actors that we believe are the most important to consider in the limited time frame.] Any actors that we believe are important but which we do not have time to take into consideration should be pointed out.
 
(iii) map some of the most common use cases into the actors defined in (ii) and describe in these terms what is going on (trying to steer clear of implementation specifics at this point).
 
(iv) using the actors selected from (ii) define a protocol that can be used to address the requirements of the use cases from (iii). We should attempt to describe *what* is required from the protocol as much as possible rather than *how* these requirements are provided, in order to allow vendors the freedom to implement the protocols in the ways they think best. However, interoperability is extremely important in this loosely coupled arena, so we will have to prescribe a minimum protocol which may include at least the format of the propagation context, how the context is propagated, the coordination and control interfaces (e.g., how messages are produced by the "coordinator" and sent to "participants", and how "results" are collated to produce a final outcome or another message).
 
(v) illustrate the use of the protocol defined in (iv) with several of the use cases. In order to do this we may have to define certain other actors (e.g., demarcation API) simply in order to talk coherently about the business transaction, but we will make it clear that these actors are not a mandated part of the specification.
 
Mark.
 
----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203
 
 


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


Powered by eList eXpress LLC