This is the matter of words: "service interface is separate from service implementation". To me, this does not mean that we can take whatever interface out-of-the-blue and stick it onto the implementation. The statement means that in SO the implementation should not expose its internals as interfaces (like Java did with WSDL generated from the signatures of the Java class). However, it is the business functionality of the service which dictates informational model for the interface, the rest is defined for service consumer audience and communication channel.
Since business functionality exists in the implementation only, we cannot say that interface is independent from the functionality, it IS separate. -Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Monday, May 11, 2009 7:23:47 PM Subject: [service-orientated-architecture] Re: JP on defining SOA 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 service-orientated- architecture@ yahoogroups. 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:* service-orientated- architecture@ yahoogroups. 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 > >> > >> > >> > > > > >
