Re: [bcm] Web Services and Process definitions

["David RR Webber" <david@drrw.info>]

Neil,

I also realized upon reflection that the webservice definition
in the PDF is highly idealized - what people think webservices
should be like.

I think in reality there a significant gap.  For example - BPEL
can hardly be seen as loosely coupled!  Not to mention the
fact that in a BPEL based interaction both parties have to
have compatible BPEL process engines to make it work -
and be able to support the BPEL steps - between the two
ends of the process.

BPEL also introduces some pretty gnarly concepts - such as
compensation handlers - that participants may need to
support.

As always - when you look at the Burger advert on TV it
looks great - but when you un-wrap the silver foil and
lift out a soggy limp wad of mystery contents - the delivery
somehow does not match the glossy photographs ; -)

DW

----- Original Message ----- 
From: <nwasserman@adaptiveservices.com>
To: <MIKE.LUBASH@DFAS.MIL>; <bcm@lists.oasis-open.org>
Sent: Tuesday, June 15, 2004 4:58 PM
Subject: RE: [bcm] Web Services and Process definitions


I think it's important to distinguish web service, as a technical means to
capture loosely coupled, encapsulated interactive components, from business
services or business service components, which can be delivered with a
number of different vehicles (automated on the web, outsourced, human).
Since web service has become embedded as a term of art for the automated
vehicle, I don't think it's wise to change its usage.

For the technical web service, loose coupling works.  But for the business
service interaction, it may be useful to think of the service in terms of
"rich coupling", by which I mean that the service can respond to a complex
set of information characterizing the needs of the service recipient.
There may be differing degrees in the "richness" of the coupling.  Using a
biological metaphor, not all organs have to be equally adaptive to the
outside environment.  Likewise, some service components may be specialized
to support interaction with complex service recipients like human beings.
Other service components can get by with less rich interactive
capabilities, such as those that deal with standard databases, and
communications protocols.  In between these poles would be service
components such as semantic brokers.  Not to make things too complicated,
maybe there is a spectrum of interactivity with "process" at the procedural
end and "service" at the service-recipient-oriented end.

Neil


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/bcm/members/leave_workgroup.php.