But the reality is many people are using existing implementations (Mainframe apps, packages, etc), to provide some or all of the business functionality of new services.
Where the service interface has been defined 'top down' for example using some canonical modelling approach, then typically some 'intermediary' of some kind is needed to marry it the implementation. Sometimes the intermediary can be very simple, other times complex (such as aggregating functionality and information from several existing systems to support one new service). I am not suggesting all services should be implemented like this, just that it is a useful pattern for some scenarios. The important thing to me is that is looks like a service to the consumer, and that the provider/consumer contract is based on the behavior offered at a service endpoint. But what happens behind that endpoint, how the service is implemented, is largely irrelevant (to the consumer) as long as the contract is met. If the provider chooses to build a facade, or use the capabilities of an ESB product to interface to existing non-service systems , or build a nice new component that is an exact match for the service interface, then so what? There are many, many different ways to provide the functionality required to provide the behavior exposed via the service. I wouldn't like to see the definition of service or SOA being dependent on a particular implementation style. Lawrence --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > I, personally, hate 'to isolate the service from changes to the > implementation'. Service is a business functionality implemented in the > service body. You can call it implementation if you want. Separation business > functionality from its implementation is absurd. It is the service which > defines its interfaces based on the business functionality and execution > contexts. It is another absurd (in SO world) to say that interface is > implemented somehow meaning that the implementation is the service itself; it > is up-side-down exercise. > > Loose-coupling between service (functionality/implementation) and its > interfaces is a quite valid point but it is the business of the service to > decide how 'loose' it should be. I accept an intermediary like a conciliator > component between the service interface and main service body ( the > conciliator belongs to the service body any way) but take an ESB (under the > authority of somebody else ) as a conciliator for my service - no way. The > ESB has its own interface and, if provider wants to communicate with > consumers via ESB, the latter MUST be included into service description with > its own interfaces while the actual service interfaces have to be hidden from > the consumers. An ESB cannot be between my service and interface of my > service (IMSO - strong) > > - Michael > > > > > > > ________________________________ > From: "l.wil...@..." <l.wil...@...> > To: [email protected] > Sent: Wednesday, May 13, 2009 3:51:27 PM > Subject: [service-orientated-architecture] Re: JP on defining SOA > > > > > > Perhaps I used the wrong term, sorry... > > But if the intention is to isolate the service from changes to the > implementation, then some form of 'intermediary' is useful. Call it facade, > wrapper, what you will. > > Often the 'intermediary' can be something like an ESB, where most ESB > products can host the service endpoint, and act as the intermediary to the > implementation, providing the transformation and mapping technologies to > marry the two together. > > More often than not, this is exactly what we find many of our clients faced > with when providing service interfaces on top of existing implementations. > > But equally, given that change is a constant, it seems a good pattern to > adopt when implementing any service. > > Lawrence > (everware-cbdi. com, cbdiforum.com) > > --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin > <m3poulin@ .> wrote: > > > > Please, tell me the secret: why we need a facade between interface of the > > thing and the thing itself? > > > > It is interface, to the interface, to the interface... > > > > Definition of facade is not an intermediary between things, it is an > > intermediary (according to GoF) between INTERFACES, from coarse- to > > fine-grain ones. SO does not require decoupling between interface and the > > service body but loose-coupling. That is, you should not expose service > > body internals as interfaces, that's it. Preservation of interface > > immutability (partial) does not require an intermediary such as facade, it > > may be a proxy/stub of the service functionality or a conciliator component. > > > > - Michael > > > > > > > > > > ____________ _________ _________ __ > > From: "l.wilkes@ ." <l.wilkes@ .> > > To: service-orientated- architecture@ yahoogroups. com > > Sent: Tuesday, May 12, 2009 10:04:46 AM > > Subject: [service-orientated -architecture] Re: JP on defining SOA > > > > > > > > > > > > I think we are more bullish on swapping service implementation, but that's > > a consequence of > > 1. telling people they have to "design for change". The more you make your > > service a reflection of an implementation, the harder it will be to swap it > > for another. You have to work hard at decoupling the interface from the > > implementation. It isn't a given just because it it uses XML and a Web > > Service... > > 2. We have a long history of doing the same thing in Component Based > > Development (we are CBDI Forum after all...). Again we saw that replacement > > not reuse was often the goal. Hence we defined CBD standards and guidelines > > to facilitate that - separating interface from implementation > > 3. we also encourage people to take a facade type approach. Use a facade to > > act as a 'broker' between the service interface and the implementation. No > > one expects that a new implementation will have no impact, but if the 'hard > > work' is done behind the facade, it should still have no impact on the > > consumer. > > > > Lawrence > > (everware-CBDI. com, cbdiforum.com) > > > > --- In service-orientated- architecture@ yahoogroups. com, "Rob Eamon" > > <reamon@> wrote: > > > > > > In other words, service interface is separate from service > > > implementation? This is the core SO principle. > > > > > > I'm still bearish on the notion that a service implementation can be > > > swapped out for another with zero consumer impact. I've never seen a > > > meaningful implementation of anything be swapped out without significant > > > effort. Some low-level technical components can and have been swapped out > > > but that's not the level we're addressing here? > > > > > >
