On 10/07/06, Eric Newcomer <[EMAIL PROTECTED]> wrote: > > Steve, > > I think it's important to underscore where this view is coming from. This is > from actual experience in a production SOA environment. I am not sure it's > really possible to call something wrong that's working in practice.
It is possible to say it isn't SOA. > > The reason for it, as I understand it, is that if you are creating an > application in some proportion from reusable services, you need to be able to > reference the specific service you want to reuse. For different applications > you are going to have a different mixture of reusable services, and it's too > difficult (if I have understood correctly) to maintain and manage artifacts > representing a collection of services when an application only needs one out > of the collection. I've worked with a few clients where this "drive to the bottom" mentality was a problem. This belief (misguided in my view) that by having "lots" that you get more flexibility because you can do everything. Its true that you have a huge amount of choice, but in reality you don't have a great deal of flexibility as you are reducing the problem down to a level where you aren't really getting any benefits. If they are saying that there is no logical service model in their company and everything is a single process, and that this works for them, the so be it. But lets not call it a service, lets call it by its proper name a "process". What they are doing is process oriented architecture as they are holding that ultimate flexibility comes from having individual processes accessible directly. I'm pretty sure that other people in their sector have been successful in creating re-use of services by taking the container approach. I'm impressed that they have made POA work, but that doesn't mean its a good pattern for SOA. > > Eric Steve > > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: [email protected] > Sent: Monday, July 10, 2006 1:21:28 PM > Subject: Re: [service-orientated-architecture] SOA Book & Discussio > > > > > On 10/07/06, Eric Newcomer <[EMAIL PROTECTED] com> wrote: > > > > > > > > Hi, > > > > Yes, this is a very good question. Actually it's been debated long and > > hard, and I bet you will continue to see two definitions for a while. I'm > > sorry the book isn't clearer on a single definition here. > > > > The problem is that some people define a service as a collection of > > operations while others define a service as a single operation. The book no > > doubt reflects this divergence of opinion. > > > > Last week I was in fact discussing exactly this point with one of the SOA > > architects at Credit Suisse in Zurich. He said after a very long debate > > they settled on the definition of a service as a single operation, > > analagous to a single method call on an object. He said there was really no > > other way to define a service usefully for reuse across multiple > > applications. > > > > I have to strongly disagree with that view, if service = operation > then SOA = CICS. I've seen it mainly in organisations that have > started looking at BPM tools. > > Service = operation is a beguiling concept as it makes SOA look huge, > whereas Service as the thing that provides access to capabilities > (operations) adds far too much simplicity for some to stomach. > > Just because some people are divided I think its important to be > definate in our recommendations to others. People who equate service > to operation are... WRONG. Its not a grey area and its not something > open to debate, its exactly the same as people who said that an object > = procedure in OO debates in the 90s. > > Process oriented systems (which is what service = operation in effect > means) are not the same as Service Oriented systems. > > Sometimes we make the mistake of being too nice. > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
