minutes of 11/29/2000 TP con-call

[Christopher Ferris <chris.ferris@east.sun.com>]

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:chris.ferris@east.sun.com
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard