--- In [email protected], Stefan Tilkov <[EMAIL PROTECTED]> 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. 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. 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". Regards, -Mike Glendinning.
