Service interfaces are supposed to be the insulation to implementation change. All service interfaces are facades. I'm not sure there is value in pointing out a "facade pattern" in the context of SO.
-Rob --- In [email protected], A W <ashra...@...> wrote: > > The facade is very important concept in distributed applications because we > look forward for extensibility. > One of the primary objectives of the session facade pattern is to minimize > network traffic. > For example, suppose that we have a Java application that supports only Java > clients. > > > > If we need to support .Net clients at some point, we can create a Web > service deployment for the business object, that has a Facade and all other > functionality remains the same. > > If we change our data storage mechanism, we can do so without affecting any > other tier. > > The layering concept used here provides us insulation against change. > > The Facade is a very important concept in achieving such extensibility. > > Without it we will not be able to support such changes. > > > All the best > > > Ashraf Galal > > * * > > > On Tue, May 12, 2009 at 4:21 PM, Michael Poulin <m3pou...@...> 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.wil...@..." <l.wil...@...> > > *To:* [email protected] > > *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<service-orientated-architecture%40yahoogroups.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? > > > > > > > > > > > >
