Subject: minutes of 11/29/2000 TP con-call
Marty Sachs Dale Moberg Chris Ferris Jenny Xu Rich ? - IpNet Karsten Riemer Scott Hinkelman Nicola Stojanovic Agenda - Karsten on status of BP specification metamodel - restructure of CPA DTD - Dale's CPP proposal - Marty put out single list of major tags in CPA/CPP so that we can focus more on what's there and what's missing Notes Karsten: BP specification metamodel is a subset of larger BP metamodel. All information can be used to drive behavior of the software. Karsten worked with a number of folk in Tokyo to arrive at this proposal. Jim Clark and Tony (?) have submitted a counter proposal to the BP team. See the documents sent to the ebxml-tp list yesterday. Scope is what BP would like to "go out" with early infrastructure release in March '01. High-level choreography is a series of interactions between two parties. A series of "business transactions' which is equivalent to 'commercial transaction' in BP speak. Each exchange is defined as a 'business transaction' requesting message and one or more possible response messages. In execution of runtime, you'd only get one of the responses. One is flagged as success and others are exception outcomes. Chaining 'business transactions' is achieved using concept of a transition. May be either conditional or concurrent or (un)successful completion of the chain. 'guard' is precondition to a transition, either successful or unsuccessful outcome of a previous business-transaction. How it maps to CPA ... Karsten & Chris worked yesterday for about an hour mapping the two proposals (BPM and CPA) issue that Karsten's BPM does not have notion of 'disable' an Action as currently exists in CPA. Q&A Marty: it is unclear as to whether explicit 'disable' is needed. Depending upon an outcome, it might be necessary to reflect that something may or may not be able to be 'run'concurrently. Scott: how do you handle synchronization (join)? Karsten: yes, it should support that Dale: is there a notion of order or is there a set? Karsten: it is a set. an attribute of the commercial-transaction is a startpoint (equivalent to 'start-enabled' in CPA) Karsten: current model, everything is modelled at commercial transaction. Has both sides of the exchange described. Fine for CPA, but possibly a problem for CPP (one-sided profile). Can be inferred, but there is no explicit means of defining it as one-sided in the BPM. Is this a problem? Scott: need explicit 'end-state' so that resources can be released, etc. Scott: are you going to model the CPP? Karsten: issue of having to support association of a delivery channel with a specific message. Marty: even if it is out of scope, how do we do it? Karsten: could identify delivery-channel(s) with a service and then enumerate the exceptions... commercial transactions will need to be identified by a URI. Chris: not clear that you need to specify a specific channel within a choreography. CPP could list commercial-transactions and the delivery-channels through which they can be reached and the BPM identify the choreography. Scott: let's keep clear the distinction between CPP and CPA. A CPA is the agreement as to how the collaboration will be carried out. CPP is just a list of capabilities. Marty: goal is to have CPA composed of CPPs without human interaction. Scott: where are the use cases? Karsten: they don't exist yet (sheepish grin) Dale: if we make this too detailed for matching purposes, we'll never get a match (automatically). Let's add a level of realism to this and have coarse-grained CPP matching be useful in the field for (manual) construction of a CPA from two CPPs. Marty: what is in the CPA/CPP spec which refers to the BP specification metamodel/XML spec? Karsten: BP will put out a spec which defines how the XML is generated, etc. Chris: have initiated MSH "service interface" discussion off list, will widen the audience to get more input/discussion Marty: everyone should provide feedback/comments on what has been discussed here so that we can have a fruitful discussion with the BP team next week during the face2face. ---- Dale's CPP proposal detailed mapping of MIME packaging for purposes of matching to ensure interoperability at the technical level. Chris: maybe this should be called out as a set of profiles with 2-3 which MUST be supported and a few others which MAY be supported, leaving the door open for others to be defined. Scott: concerns that if we need to expose this level of complexity that none of this may fly. Dale: experience in the field suggests that this level of detail is needed. May be due to poor implementations. Having these packaging profiles explicitly defined may help to ensure interoperability. ---- Some further discussion on service interface (app->MSH) Much consensus that we may indeed need to take a cut at this...
begin:vcard n:Ferris;Christopher x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;;;;; version:2.1 email;internet:firstname.lastname@example.org title:Sr. Staff Engineer x-mozilla-cpt:;0 fn:Christopher Ferris end:vcard
Powered by eList eXpress LLC