Terms "vertical" and "horizontal" in the context of Stefan's message are not clear to me. What the relationship between them and long/short-living service? Why a composite service is always vertical and short-living? It is the meaning of 'composite' appears orthogonal to "living" which, in turn, is orthogonal to "vertical/ horizontal".
Composite service in SOA is a service composed from other services. What is wrong with such simple definition? The SCA's composite does comprise multiple components but it is not a service, it is a composite. I do not see any conflicts between composite service and SCA composite - they are different animals in spite of very similar terminology. I, probably, misunderstood Stefan but curious to ask: why a long-living composite service raises doubts if it belongs to SOA? As of necessity of a process engine in SOA, I am totally with Stefan - it is NOT "must have" infrastructure element, especially if talking about composite services. - Michael naren_chawla <[EMAIL PROTECTED]> wrote: "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. > > > > > > > --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.
