[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bcm] Web Services and Process definitions
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]