On 15/01/2008, Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > > > > > > What the picture talks about if not about relatinsip between the layers? It > has nothing to do with > implementation, as Steve suggested, or internal view (where it came from?)
The idea that process is "above" service is purely an implementation thing. After all if you take 4 processes and wrap them up into a service then clearly the service is the higher order element. > > The diagram shows that to access a data, the service deals with Data > Service, not the data > directly; if a process needs a data, it uses either service or data sarvice. What if I want to implement a service using processes? Why can't a service deal directly with data, or indeed retain its own data? From the perspective of a consumer of the service why does it need to know how it gets the data? > In this context, I am > saying that as a process can/may deal with the service, a service may deal > with the process > (internally or externally - does not matter). This latter one is not > reflected on the diagram ( I would > accept even a connector line going from the service to the process :-( ). My question is why can't a service be implemented using processes, I ask this as I've been doing this for years and it works very well. It only makes sense to split process and service if you have an application server that doesn't enable you to effectively implement services using processes. Steve > > - Michael > > > ----- Original Message ---- > From: Sebastian Stein <[EMAIL PROTECTED]> > To: [email protected] > Sent: Monday, January 14, 2008 6:24:59 PM > Subject: Re: [service-orientated-architecture] service vs. process in the > David S. Linthicum diagram > > > > > Michael Poulin <[EMAIL PROTECTED] com> [080114 19:08]: > > In the diagram, represented in Wikipedia > > (http://en.wikipedia .org/wiki/ Service-oriented _architecture) and > referred > > to David S. Linthicum, a process/orchestrati on layer "sits" on the top of > > the service layer. Plus, the diagram shows possible inclusion of a service > > into the process. > > > > All looks OK until... you have a service whose implementation is a process > > managing other service invocations. How to squeeze > > > > it into the diagram? I think, relationship between 'service' and 'process' > > in SOA is not linear but it is similar to a famous Korean symbol - > > everyone includes every another one. > > In addition to what Steve said, it doesn't matter how the service is > implemented. It can be done by an orchestration or ordinary software > engineering. But that's not relevant in the picture, because it doesn't talk > about the internal view. > > Sebastian > -- > http://sebstein. hpfsc.de/ > > > ________________________________ Never miss a thing. Make Yahoo your homepage. > >
