Hi Eric, My view is that a high-level service needs to meet the requirement that its implementation can be changed without affecting its consumers. This includes exchanging an internal service provider for an external one.
For this to work, the only dependency has to be explicit and must only rely on the service's public interface. If one service can only work because it can count on some other service's side effects, something is wrong. Please note that there are obviously many exceptions to this rule (which I believe applies to high-level services only, anyway); still, I think it's a solid reason against the one-operation-service pattern. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ On Jul 13, 2006, at 4:15 PM, Eric Newcomer wrote: > > Hi Stefan, > > This is a confusing topic and probably Todd put it best that the > right answer is the simplest one that meets the needs of the > business. Certainly one can go either way with it. > > What's confusing is that in the case of SubmitInvoice, for example, > this is a very "large grained" service that probably needs to > request the execution of a bunch of other services to complete. So > is this "one service"? Technically, a single interface is > presented to the requester, but in the execution of that service it > is composed of multiple services. > > Again, I think the question that came up was more of a modeling > question than an implementation question. The Credit Suisse folks > chose to expose a single service "unit" (I think the term operation > is also confusing here because a service is not really the same as > an operation) - and for this I believe it's better to think in > terms of a single "message" more so than a program, queue, method, > operation, etc. > > I think what they were saying - and again I am not sure I > understood this in sufficient detail since it was a brief part of > the conversation - is that from the point of view of assembling a > system of reusable services that multiple requesters might invoke, > it was simpler and easier for them to model those services as a > singleton. > > Obviously this is not a case where one size fits all, and it may be > simpler and easier for others to model their service interfaces as > consisting of multiple message exchange patterns, but I also > believe there's a strong case to be made for modeling a service as > a single MEP. Of course behind the interface there may be many > other services etc. > > Eric > > ----- Original Message ---- > From: Stefan Tilkov <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, July 13, 2006 6:33:53 AM > Subject: Re: [service-orientated-architecture] Re: SOA Book & > Discussio > > On Jul 13, 2006, at 9:54 AM, Mike Glendinning wrote: > > > Consider an invoicing system, let's say SAP R/3. A service for a > > company's suppliers called "SubmitInvoice" will typically store the > > invoice details in the database and kick off a series of internal > > processes/workflow to process the invoice and pay the supplier. To > > be useful, an information retrieval service > > called "GetInvoiceDetails" must also be able to access the data > > previously created by "SubmitInvoice" . That is, both services are > > dependent on the shared SAP R/3 database. > > That's why, IMO, these would be two operations of the same service. > They are much too closely related to be two services. > > I believe the concept of autonomous, independently evolvable services > usually requires having more than one op per service, with a single- > op-service being a special case. > > Stefan > -- > Stefan Tilkov, http://www.innoq. com/blog/ st/ > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
