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 <[email protected]> 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 <[email protected]> > >> >> >> 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 <[email protected]> >> *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 <m3pou...@.. .> 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 >> >> >> > >
