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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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


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


<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


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC