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, 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
