They are not following the best practice for defining the service as I think. if you define the service as a totally business function without sticking it to any technology you will have a reusable service. Most properly the people fall on the mixing between technology and business function. Please revisit the original post in this thread, he provides a good examples. All the best
Ashraf Galal On Mon, May 11, 2009 at 2:23 PM, Rob Eamon <[email protected]> wrote: > > > 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]<service-orientated-architecture%40yahoogroups.com>, > 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]<service-orientated-architecture%40yahoogroups.com> > > >> *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 > > >> > > >> > > >> > > > > > > > > > > >
