You've brought up a good point - the cost. Is it better to be design a very flexible service from the start or to design a service so that more flexibility can attained in the future? :-) I think most of us share a common concept of what SOA should be, but I think the difference lies on when and how to get there.
H.Ozawa --- In [email protected], A W <ashra...@...> wrote: > > The ability to reuse services is one of the principal benefits for adopting > SOA in an enterprise. > This statement will remain a promise for development efforts unless some > foundational concepts are practiced. > There are several practices for increasing the likelihood of achieving > service reusability including decoupling of transport, message and interface > standardization, encapsulating horizontal cross cutting concerns (security, > logging, audititng,..etc) , and validation of service contracts to avoid > interoperability issues. > > For example, you might initially have a simple lookup for a string input > against a single system. > > Over time, you might want to add a query against a search engine, or > multiple applications etc. > > The standard interface will keep this evolving complexity out of sight from > your consumers. > > If the interface remains the same, there is no need to change the > consumer(s) at all. > > This why we emphasis designing a generic interface that we try to keep it > stable to all service consumers, current and who are expected in the future. > > If we don't do that we will never recognize the ROI benefits of SOA and the > cost will be very high because we need to modify every consumer. > > > All the best > > > Ashraf Galal > > > > > > > > > On Tue, May 12, 2009 at 3:39 AM, Michael Poulin <m3pou...@...> wrote: > > > > > > > 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 <ashra...@...> > > *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<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...@yahoo. com <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...@gmail. com <htshoz...@...>> > >>> *To:* service-orientated- architecture@ yahoogroups. > >>> com<[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 <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 > >>> > >>> > >>> > >> > > > > > > >
