Michael, I'm sorry, I didn't mean to confuse people with new terminology.
The terms "horizontal" and "vertical" have been used in the workflow and process management industry (to my knowledge) for well over a decade to distinguish between two kinds of situations: a) The flow of work across an organisation (or between organisations) in multiple steps and from one person to another. This is called "horizontal" workflow. Because multiple human (or business) participants are involved, these workflows are usually long lived and often can not be automated completely. b) The rules and sequence for completing each individual step of a longer running horizontal workflow. Normally, each step involves multiple tasks and these are completed by a single participant and in a relative short period of time. This is called "vertical" workflow and can usually be entirely automated. Consider a company selling physical goods and allowing customers to order over the telephone. A horizontal workflow process might be defined for "sell items" and would involve individual steps of order entry, warehouse stock picking, order assembly, packaging and delivery. Each of these steps would be performed in a different location and by different people. Physical handling of goods is required and the entire workflow might take hours or days to complete. A vertical workflow process would also be defined for each of the steps in the "sell items" workflow. For example, the "order entry" step might involve a single telephone customer-service agent performing the tasks of customer identification, order creation, warehouse stock checking, customer credit checking and order acceptance before handover to the warehouse for fulfilment. A well- run company would typically embody these tasks and the associated business rules (which can be quite complex) in an automated computer system and aim for fast completion in a matter of seconds or minutes. Now, I'm not saying that SOA has absolutely no relevance to horizontal workflow. Many industries are very focused on automating such workflows both inside and outside the organization (viz. the concepts of "straight-through processing" in financial services and "flow-through provisioning" in telecoms) and SOA can obviously make this easier. But in most cases the "human gap" remains and the design and management of such workflows is therefore primarily about human and physical issues such as skills, training, language, culture, health and safety, geography and so on. The need for human involvement is why I say that a different approach and set of technologies is required to address horizontal workflow properly. On the other hand, vertical workflow is ripe for automation and SOA is an ideal way to make the implementation of such workflows easier. As we have already discussed, the vertical workflow can simply be defined as a composite service consisting of a set of business rules and associated calls to underlying services representing the individual tasks. Of course, whether the composite service is defined using a BPEL tool or hand-coded in Java/C++ is merely an implementation decision. Regards, -Mike Glendinning. --- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > 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 <stefan.tilkov@> 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. >
