Martin Chapman wrote:
Message
Conceptually cpa is interesting, but does it
actually work with wsdl based web services?
The CPP/A TC is addressing this issue; my understanding from a reliable
source is that the TC feels this is not a difficult problem.
Also don't both parties need to have a CPA
defintion? If so, isn't this a huge overkill for the simple clients
invoking a bpel process?
The CPP represents the capbilities of one party; the CPA represents the
agreed-to capabilities to be used by two parties in a collaboration.
Very roughly speaking, the CPP is equivalent to WSDL, while the CPA is
equivalent to two WSDL docs associated by a partnerLink. Very roughly
speaking.
Surely all that is needed in this case is a
very simple "requires/supports" type mechnism advertised by the process
(or wsdl), found in ejb, and not a complicated negotiation process.
We have two very different cases when we discuss exposing a service
within the intranet, and exposing one to partners over the internet. A
CPA is a very useful thing in the context of a B2B trading partner
agreement, while it certainly is overkill (and very annoying) for
internal services. We ought to support both styles, preferrably in a
fashion that does require explicit incorporation of them into the
standard.
We can largely get by with the argument that these are "deployment
details", and shouldn't affect a process model founded on an abstract
messaging model. I say largely, because there is the case where, for
business reasons, messaging QoS requirements may be part of some
activities in a business process definition. How do we accomplish this?
Or do we want to avoid modelling such aspects of a process in the BPEL
language?
-Ron
Martin.
David,
I like it. Those loosely-coupled specs in the ebXML suite certainly
enhance reusability -- something we should keep in mind in our efforts
here.
BPSS includes some simple mechanisms to specify QoS, in a fashion
similar to what I sketched below. Perhaps we can do a little borrowing,
point at CPP/A in a non-normative way, and we can declare victory. :-)
Cheers,
-Ron
David RR Webber - XML ebusiness wrote:
Ron,
EXACTLY! This problem has already been solved by the CPA team!!
Why re-invent this? The partner role stuff in BPEL is weak compared
to CPA - so makes sense to upgrade here.
Using your CPA you can point at the BPEL process and specify the
QoS in the CPA. I've also very successfully templated this for
CPA - so that the delivery options and combinations are simply
drag-and-drop options within the CPA wizard UI.
Makes sense for us to liaise with the CPA team to ensure that
a CPA can define BPEL processing adequately.
Looking at it they already have the means provided to point at
a BPEL script. The BPEL engine may need to query the CPA to
determine lowerlevel functionality - and that we may need to
ensure there are the right "slots" for within the CPA schema.
Probably an excellent exercise to go thru anyway - to quantify the
details that are relevant for BPEL.
Thanks, DW.
==================================================================
Message text written by Ron Ten-Hove
These could be used by the deployer when selecting or creating the
appropriate bindings for the abstract operation "acceptPayment".
This still wouldn't help the interoperability problem -- two deployers
for two different engines that must interoperate must "exchange notes"
to assure compatible bindings are chosen. This starts to become a very
CPA-like exercise.
-Ron
<
|