Enabling the architecture to be flexible later may be very costly, but what about flexibility of a single service? Even in a single service, there are several aspects to flexibility - flexibility of function supported by the service, flexibility of service usage, and flexibility of modifying the service. The degree of flexibility aspects should differ depending of the type of service (e.g. core process service, supporting service). In an actual project, a budget is tight and it is getting much tighter in the current economy. Deciding on where and when to spend the budget is very important to successfully get the project started-)
H.Ozawa 2009/5/14 Michael Poulin <[email protected]> > > > Adding flexibility later (to a monolith) is very similar to adding > security later: it is either impossible or extremely costly. > > - Michael > > ------------------------------ > *From:* htshozawa <[email protected]> > *To:* [email protected] > *Sent:* Wednesday, May 13, 2009 12:23:13 AM > > *Subject:* [service-orientated-architecture] Re: JP on defining SOA > > 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 service-orientated- architecture@ yahoogroups. > com<service-orientated-architecture%40yahoogroups.com>, > 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:* service-orientated- architecture@ yahoogroups. > > > com<service-orientated-architecture%40yahoogroups.com> > > > *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 > > > <[email protected]<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<service-orientated- > architecture@ yahoogroups. > com<service-orientated-architecture%40yahoogroups.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 > > >>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > >
