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 () 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 ()
Transactions Architect, HP 
Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203