Re: [service-orientated-architecture] Re: SOA Book & Discussio

Fri, 14 Jul 2006 08:32:18 -0700

Stefan,
 
Yes, that is an essential goal of SOA, to minimize impact on consumers when changing a service.  When an interface is changed, however, it does impact the consumer, unavoidably, since the interface is a contract between consumer and provider (and the key artifact therefore in any SOA). 
 
Governance and process gives the discipline to when and how an interface can be changed, which consumers it impacts, and under what conditions it's allowed.  This can be a very tricky thing, as I'm sure you know, and it seems like there's always a tension between requests for change and requirements for stability. 
 
In the debate here the impact of change is potentially greater on a consumer when the consumer recieves services in the interface that the consumer doesn't actually consume.  In other words, when the interface definition contains multiple services but the consumer only needs one of them, managing change is more difficult.
 
A consumer may need to use only a single service out of an organization's entire library of services.  A consumer may need to use more than one service, or perhaps a whole bunch of services from the library.  And it is furthermore likely that no two consumers need the same collection of services.  It may be extremely difficult, if not impossible, to design interfaces such that for any given consumer the interface contains only those services required by that consumer.  However if you limit an interface to contain a single service you can achieve this more easily, although of course the number of interfaces grows.
 
Eric
----- Original Message ----
From: Stefan Tilkov <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, July 13, 2006 12:57:39 PM
Subject: Re: [service-orientated-architecture] Re: SOA Book & Discussio

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 <stefan.tilkov@ innoq.com>
> To: service-orientated- architecture@ yahoogroups. com
> 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/
>
>
>
>
>


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to