web services uber alles? [was] Re: [ebxml-dev] RE: ebXML deliveries

[James Bryce Clark <jamie.clark@mmiec.com>]

> <nickull>
> One thing that would be very useful is a web services to build a CPA and
> Context Rules Message from the binding of a Business Process Schema to
> two or more CPP's.  The CPA is essentially a Service Level Agreement
> (SLA) that could also define further web services. * * *

Duane, your concept of the CPA seems to bear more
content than would mine.   
I think of a 'service level agreement' as an agreed set of boilerplate
economic deal terms beyond the semantic scope of a CPA.  When we
bury economic terms in the CPA (or MSG) layer, they are unexposed to the
semantic tools at the BP collaborative layer, so they can't be strung
together with conditionality to create robust series of
transactions.

In the larger scheme, I think of the CPA as a binding agreement
constrained to cover roughly three things:  the parties'
manifestation of identity, their modem handshake (so to speak) of
communication loci and protocols, and their mutual designation of one or
more business processes to be shared.  Those business processes are
defined not in the CPA, but in a BP schema to which the CPA
points.   

(A key user-level business requirement for automated transactions is that
the user needs to be able to take their eyes off the system, once a known
process has been initiated.    Essentially, the user
reposes business confidence in the determinacy of the BP that the
CPA invokes.    The more transformations and operations
conducted on the BP specification, from outside itself, the less
certainty and replicability.)  

If we want people to model collaborations, there shouldn't be too much
invoking of one-off services from the CPA, no?   Or do you
envision a shared, binding taxonomy of available services, driven from
elsewhere than a business process specification?  (That's the
'architecture' you, not the 'XML Global' you.)   Or am I
envisioning 'services' poorly?

Best regards   Jamie