Ashraf, Facade is taken term, it means transition between INTERFACES. J2EE Session Facade does the same thing - it substitutes interfaces (and invocations) of multiple Session Beans by an interface of one Session Bean, it did not decouple Session Bean from its own interface. What EJB Contained did, it exposed the EJB interfaces at its own ones and intercepted requests before that reached the EJB, it worked as an invisible intermediary, not as a Facade.
You see, I am upset with the use of word 'facade' because unusual usage of it is confusing. It is the same matter as what the authors of SCA did - they renamed messages into events and started sending and receiving events, which sounds somehow crazy to me. - Michael ________________________________ From: A W <[email protected]> To: [email protected] Sent: Wednesday, May 13, 2009 3:22:35 PM Subject: Re: [service-orientated-architecture] Re: JP on defining SOA 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...@yahoo. com> 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...@btinternet .com" <l.wil...@btinternet .com> 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" <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? >
