DEAR ALL, is there any way to distinguish between client and server patterns in the context of the question.because im preparing to have SCDJWS exam and it has 6 design patterns 1)business delegation,proxy,service locater 2)session facade,command ,service broker
i cant distignuish exactly between session facade,service locater and business delegation they have a lot of commons like reduce network traffic... please help me to slove this dilemma..
the 3 patterns can be used together, they might seem similar but have different characteristics/features:
ServiceLocator: used by clients to locate services (e.g. if SessionBean needs to use an EntityBean, will perform a jndi lookup/creation via the ServiceLocator). Main objective of the pattern is to abstract/hide lookup/creation of services.
BusinessDelegate: used to hide details of the service implementation, for example lookup and access details. Very useful to map RMI exceptions into application-defined exceptions.
Facade: encapsulates complex interactions with many business services (EJBs). For instance one call from the client triggers n calls to different EJBs (reduce network traffic).
I typically would have 1:1 relationship between BusinessDelegate and Facade, where the ServiceLocator is used by DB to look-up the EJB facade.
This is only my quick sum-up, I suggest to read Sun Catalogue to get more precise definitions and details.
see the following... Service Locator: As it named, locates enterprise services and caches (if it can), to reduce network call and make client code simple (relieved from locating resources). For example : Look up of ejb using jndi name and caching the home reference is a job of service locator. The following are the adnvantages you can see from this example... 1. Writing code related jndi look up is knocked off. Provide jndi name to service locator, it will get back to you with Home reference. 2. Caching of Home reference helps in reducing further network call...
Session Facade: Yep , this also reduces network calls(in some cases ). See the following example... If a customer wanted to book a flight (last stage), the following steps to need to be performed.. 1. send a request to transmaster to pay.. 2. if point one is successful, send a request inventory/ update flight database for booking confirmation.. 3. Send a mail to customer for successful booking. same incase of failure.. FACADE from core patterns ....
This sort of workflow is required to contact multiple ejbs which means direct network calls.... If you make a stateful session bean responsible to call these ejbs and make them call using local interfaces... This reduces a lot of network calls as well as easy to maintain workflow level transactions....
Business Delegator: This simplifies the job of client while invoking a service. Business delegator is an interface over your service implementation class(like an api). Client calls delegator as a local service (as client knowledge, business delegator will provides the whole functionality). Its delegator responsible to locate necessary services and fulfill client request. It is like PROXY pattern from core patterns.
typical calling hierarchy may look like the following... <code> Client--call--> BusinessDelegator --call--> Service locator(to get Facade) BusinessDelegator --call--> SessionFacade (for service) SessionFacade--call--> ServiceLocator(for rest of services) </code> It doesn't mean that all applications will follow the same structure... Hope this may help...
all the best....
Joined: Sep 06, 2006
Thanks a lot .things now become more clear to me. the last thing is there any keys words that i can use to distinguish between client patterns and server patterens (just these) client patterns:business delegate,service locater server pattern:session facade. to eleminate the wrong choices in the context of question? (i used to depend on client key word even though it used with session facade)