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