Re: [wsbpel] Q: guidelines for reliabilityA

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

David RR Webber - XML ebusiness wrote:

Message text written by Ron Ten-Hove
  

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.
<<<<<<<<

Ron,

If I may say so this is a typical techie view here ; -)

I may be guilty of trying to heighten the contrast a bit between the two cases, but I have plenty of customers who fall neatly into these categories, and they are decidedly business-oriented in their choices. The role of techie they leave for the likes of me. :-)

Most managers of large enterprises would welcome knowing
more formally what is happening at an intra-department level,
and being able to catalogue and manage that.  

Agreed. This is a problem that is being approached in various ways, and you phrase it well. While our standard won't directly address such considerations, it is not unreasonable to regard a BPEL execution system and associated messaging infrastructure as a good source for all kinds of business activity information, easily related to models of the business processes being executed, at least to the level supported by BPEL. Multi-party collaborations will have to wait for something more sophisticated to emerge from the primordial ooze.

Sure for a small deployment CPA in all its glory is a potentially
heavy footprint - but not so heavy as BPEL itself is, eh? ; -)

The heavyweight problem is the negotiation of the CPA itself, which most organisations are not willing to automate (and rightly so). This implies extra steps for implementation (in the business sense) and maintenance of automated business processes. Certainly from both a technical and a business perspective BPEL will be much heavier than existing CPA stuff.

So let's not get confused here.  The approach for intranet 
applications - of having a standard "canned" BPEL config' 
of a CPA - makes the footprint very light IMHO.

This is true; we at Sun have even done "generic CPAs" that allow customers to test their new ebXML MSH installations by registering with a well-known service address, without having to negotiate a new CPA, or alter an existing one. (I suspect this is slightly "out of spec.") This is so light-weight it is invisible to the customer; it is just part of the registration process. So I would support your characterisation of some CPAs as being lightweight.

It also ensures that we "answer the mail" formally for all
the QoS parameters and metrics that CPP / CPA provides
and gives customers the re-assurance that their BPEL
process connections are managed.

Agreed; I did not mean to suggest otherwise. Are you suggesting direct incorporation of CPP/A into WS-BPEL?

As I noted before - if you embed this stuff in a solid GUI - 
suddenly most of it is defaults - and the users really do not
have to provide much beyond obvious eBusiness 
connection related details.

Even reasonable default attribute values in an XML Schema will help, but that is a techie answer, isn't it? :-)

Cheers,
-Ron