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 [email protected], "Rob Eamon" <rea...@...> 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? >
