"At the other end you have the implementation of automated, short- lived vertical workflows, otherwise known as composite services."
As some of you know, there is notion of composite in SCA that comprises of multiple components (running in heterogenous containers). This composite in SCA can include a "long-running" process service. And yes, one can expose this composite as a service. In Stefan's terminology - a "short-lived" vertical workflow is known as a composite service". And that conflicts with "composite service" in SCA terminology. I am wondering if people on this list have view on what is the right terminology around this. Thanks, Naren --- In [email protected], Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > On Apr 27, 2007, at 10:49 AM, Mike Glendinning wrote: > > > --- In [email protected], Stefan Tilkov > > <stefan.tilkov@> wrote: > > > > > > I was in a panel discussion at a conference this week, and was > > > surprised to notice there's still no consensus about whether or not > > a > > > process engine (or rather, support for automated BPM) is a "must" > > for > > > SOA. > > > > Stefan, > > > > when you mention BPM, Workflow and BPEL you are covering quite a wide > > range of concepts and technologies, perhaps too large for your > > question to make any real sense. > > > I know, but I choose not to care ;-) > > At one end of this range you have the definition and management of > > long-lived horizontal workflows, usually human-based and with all the > > attendant business issues of the process re-engineering fad, etc. In > > my view, this is entirely orthogonal to SOA and requires a different > > approach and different set of technologies. > > > I agree this is orthogonal, and this is what I was referring to in my > view above. > > At the other end you have the implementation of automated, short- > > lived vertical workflows, otherwise known as composite services. > > These, I think are an essential part of SOA and its unlikely that any > > meaningful SOA will not find the need for these kinds of services at > > some point. As others have pointed out, composite services can be > > implemented in a variety of ways, for example directly in Java or > > using a BPEL tool (process engine). But this choice is exactly what > > it says - an implementation decision - and is therefore nothing to do > > with the SOA itself since one of the major goals of SOA's "loose > > coupling" is to separate service interface (or contract) from > > implementation: you should not know or care how a services is > > implemented. > > > > Therefore, I think that although a process engine "may" be the right > > way to implement composite services in a SOA, this is definitely not > > a "must have". > This is exactly my opinion (which is a nice coincidence for various > reasons ;-)) > > Stefan > > > > Regards, > > > > -Mike Glendinning. > > > > > > >
