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 LINKS
__,_._,___
