In other words, service interface is separate from service implementation? This is the core SO principle.
I'm still bearish on the notion that a service implementation can be swapped out for another with zero consumer impact. I've never seen a meaningful implementation of anything be swapped out without significant effort. Some low-level technical components can and have been swapped out but that's not the level we're addressing here? -Rob --- In [email protected], A W <ashra...@...> wrote: > > Usually service functionality is defined to serve any kind of consumer, if > we fellow the best practice. > let's take an example. > So, we have a service that does reporting some thing like credit report. > (business servcie that implementted in IT) > We design a service to run the report in the provider side. > The report service, from its contract, can be distributed to consumer either > by web consumer, email client, or printer. the input to the report is the > same for any consumer. > The service functionality (the report itself) is run and produce the result > that could be delivered to any of the consumers mentioned above. > The report itself doesn't know any thing about the consumer. > If there is a need to add a new consumer mechanism such as a hand-held > device, so we can and another wrapper and access components without modify > the service implementation at all. In addition, if we want to change the > implementation itself, it will never affect the consumer at all. > It is the almost same concept as of the strategy/adapter pattern, but the > business people don't like this terminology of course. Just of explaination. > > > *By encapsulating service access*, the provider gets the flexibility to > change implementations over time or offer multiple implementations based on > SLA requirements. > > > All the best > > > Ashraf Galal > > > > On Sun, May 10, 2009 at 5:19 AM, Hitoshi Ozawa <htshoz...@...> wrote: > > > > > > > Question: Should services initially be designed for all consumers and > > restriction on usage placed during deployment of a service or should service > > restriction be considered during the service design. ;-) > > > > H.Ozawa > > 2009/5/10 Michael Poulin <m3pou...@...> > > > >> > >> > >> HI Hitoshi-san, > >> > >> I do not distinguish between external/public and internal consumer > >> audience in this case, maybe because I always worked for large corporations > >> and with cross-departmental services. In general, there are the notion of > >> service description - what service offers and how to reach its offer - and > >> agreement between service consumer and provider on how to use the services > >> - > >> the service contract. Real service orientation is in ability to solve > >> external problems using internal resources (services, in this case). > >> > >> A service contract may be explicit and implicit. > >> > >> If we deal with a business service, i.e. the service that can affect > >> business RWE, it is highly recommended to consumers to perform explicit > >> negotiation with providers to make sure they do not have something in the > >> services that can screw the consumers. For example, a business service > >> which > >> has its UI exposed to the end-user might need to obtain results of special > >> calculations and engages related service (within the same company or even > >> division). It may be a mistake if the engagement is done blindly because > >> the calculation service may be using data from a database with low > >> availability while the initial business service promises high availability > >> to the end-users. That is, the calculation service can compromise the > >> contract in its SLA part. > >> > >> If we deal with infrastructural service like security service, the > >> contract may be implicit because security must be applied irrespective to > >> the consumer's preferences, here is nothing to negotiate about. > >> > >> Now, if we limit services by 'the perspective of providers and consumers > >> as defined by a contract', we are getting into situation where we have to > >> have special 'service' for each consumer. Services in SO are developed and > >> offered based on expectations of categories of consumers, not individual > >> ones (though some of them can contribute into defining the service > >> functionality at the beginning). The offer of the service is in the Service > >> Description, the customization of service capabilities are in the Service > >> Contract. > >> > >> If we accept that SERVICE=INTERFACE, all my explanations do not matter: > >> interface is only what it is, it is self-describing but it does not provide > >> any business functionality or RWE by itself. If we want to make any > >> progress, we have to stop using 'Esope' language (saying 'service' when > >> meaning 'interface') > >> > >> - Michael > >> > >> *From:* htshozawa <htshoz...@...> > >> *To:* [email protected] > >> *Sent:* Thursday, May 7, 2009 11:59:12 PM > >> *Subject:* [service-orientated-architecture] Re: JP on defining SOA > >> > >> Hi Michael, > >> > >> Back from another assignment. :-) > >> > >> --- In service-orientated- architecture@ yahoogroups. > >> com<service-orientated-architecture%40yahoogroups.com>, > >> Michael Poulin <m3poulin@ .> wrote: > >> > > >> > However, I have some problems with proposed SOA definition, in > >> particular with "focuses on design of systems from the perspective of > >> providers and consumers as defined by a contract. SOA-based designs > >> introduce agility by enabling interchangeability of service providers > >> without requiring process changes in the consumers." As we know, when we > >> design SO architecture, we do not (cannot) anticipate the service consumers > >> and scenarios where the services will be used. This means, we cannot talk > >> about 'contracts' because the sense of this word assumes an agreements > >> between parties; if one party is unknown, what the agreement may be? > >> > > >> True if we are talking about providing services for general audiences, but > >> in most cases users want to limit who can use their services and only a few > >> limited services are offered to general audiences. > >> > >> H.Ozawa > >> > >> > >> > > > > >
