While I agree with AW for the most part of the post, I would be VERY accurate with the statement "In addition, if we want to change the implementation itself, it will never affect the consumer at all". I know many examples (and I wrote about them several times) where a change in the implementation significantly affected consumer (not the consumer code directly involved into service interface communication). SO is more than service invocation.
- Michael ________________________________ From: A W <[email protected]> To: [email protected] Sent: Sunday, May 10, 2009 10:25:22 PM Subject: Re: [service-orientated-architecture] Re: JP on defining SOA 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...@gmail. com> 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...@yahoo. com> 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...@gmail. com> 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, 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
