aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Controller + BD + S. Facade Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Controller + BD + S. Facade" Watch "Controller + BD + S. Facade" New topic
Author

Controller + BD + S. Facade

Rudi Vaum
Ranch Hand

Joined: May 02, 2003
Posts: 59
Hy,
can you tell me how to display a combined Contoller + BD + S. Facade in UML?
Examples somewhere on the web?

How do you intent to support multiple clients?
thx
Rudi
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
Can I ask why you want them all combined? There are sufficient differences between them( controller, BD and S.Facade) and you may want to consider depicting them separately.


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Avianu Sud
Ranch Hand

Joined: Jan 20, 2002
Posts: 55
A Controller is typically a entity(class) that receives message from multiple clients and decides which action to call. In web design, it is used mostly to get requests from the web clients, such as submit button on web pages.
ie. Controller handles requests from multiple sources(belonging to multiple features or domains)
A Business delagate on the other hand, transfers the user request to a business request on the service layer, and encapsulates EJB calls for example. So the Business delegate is a 'client' for the Session Facade.
A Session Facade manages use cases, and call EJB's to perform business logic.
To Answer your question, controller & BD can sometimes be combined if the BD does not do additional tasks(such as EJB calls), or if the system is fairly simple.
Similarly, some EJB's can act as Session Facades is the domain does not have complex relations.
These 3 layers are extended or condensed based on the complexity of the system, flexibility needed, and separation of logic for maintenance.
Rudi Vaum
Ranch Hand

Joined: May 02, 2003
Posts: 59
so, supposing i had a ejb layer, with a session facade in front of it, as central access point (actually 2 or 3 such SLSB acting as facades for this layer).
for each session facade, i would have a business delegate, delegating it's functionality, making lookups and caching data between calls over the network.
now, i would have a web app, accessing this ejb layer, and i would have a standalone client, also accessing the ajb layer. both would use the delegates.
THE QUESTION: do i need a controller in front of these clients, or not?
or would the controller be included in the web-app itself (as some servlet, for instance), respectively in the standalone client?
if so, would that not mean that i am duplicating the functionality included in the controllers?
am i beeing wrong here?
Anil Vupputuri
Ranch Hand

Joined: Oct 31, 2000
Posts: 527
Yes the Controller should precede Dispatcher (aka., Business Delegate), in J2EE context Controller can be Servlet which delegates request to Dispatcher which in turn can access Session facade or Helper layer to perform business logic (EJB)
According Service-to-Design Pattern, the flow something looks like,
Client -> Controller -> Dispatcher -> Session Facade -> Business Service (EJB)

Cheers,
Anil


SCJP 1.5, SCEA, ICED (287,484,486)
Avianu Sud
Ranch Hand

Joined: Jan 20, 2002
Posts: 55
Rudi,
I agree with Anil. Your servlet is the controller. In Struts for example the framework provides controller, which is a mapping file with user actions corresponding to action classes (thus the controller implementation is actually multiple classes, but managed in a central file).
Rudi Vaum
Ranch Hand

Joined: May 02, 2003
Posts: 59
okay guys,
but what should i do when i also have a standalone application, using the ejb layer?
should i also use a servlet controller?
there is something like this described in "Designing J2EE Apps" for SUN, but i would rather directly connect to my ejbs from the intranet (for the stanalone app).
the question is: having one web-app and one standalone app. (the latter connecting directly to the ejb layer), where comes my controller?
remeber, i have some session facade SLSB with corresponding BD.
i'd be very very gratefull for anyone to get this right
thx guys
bor
Greenhorn

Joined: Dec 26, 2002
Posts: 11
Dear Rudi,
I think that you already know j2ee, design pattern and UML.
Think about these:
To use a standalone app as ejb-client, will you use a controller on you web tier?
To use a web-app as ejb-client, will you use a controller for its web-client?
You have to consider the practicability of using a standalone app or web-app as ejb-client by your project situation.
- location of the standalone application
- firewall
- capability of client
- client-container
- security and scalability
Sincerely,
Hayes Sprint


bor
Larr Goneg
Greenhorn

Joined: Jul 02, 2003
Posts: 23
Originally posted by Anil Vupputuri:
According Service-to-Design Pattern, the flow something looks like,
Client -> Controller -> Dispatcher -> Session Facade -> Business Service (EJB)

Cheers,
Anil

But in this case, what's the benefit of BD(dispatcher), since every BD only deal with one Session Facade, actually both BD and session facade has the exactly same methods, why not call session facade directly from controller?
thanks!
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
Originally posted by Larr Goneg:

But in this case, what's the benefit of BD(dispatcher), since every BD only deal with one Session Facade, actually both BD and session facade has the exactly same methods, why not call session facade directly from controller?
thanks!

Use of BD decouples your clients from the enterprise tier and hides details such as JNDI lookups for the session facade(ServiceLocator) and in some implementations, can actually store the home reference to the session facade. BDs are also very handy if you have non-web based clients. In such a scenario, you may not have the controller which is typically a Servlet. Bundling BDs with stand-alone client jars is a very popular practice.
BDs normally have the same set of methods as the SFacade, but nothing precludes you from adding more behavior to BDs. For instance, a BD can act as a "business controller" and selectively choose an appropriate facade to service the requiest. For instance, a BankingServiceBD can look at the request parameters and select either a TellerFacade or a CustomerFacade to service the request. In this case, although the BD exposes just one method to the client, there is some business intelligence involved in how the request is processed and such nuances are neatly hidden from the clinet.
Hope this helps,
Larr Goneg
Greenhorn

Joined: Jul 02, 2003
Posts: 23
First, Thank you very much for your helpful reply.
Originally posted by Ajith Kallambella:

Use of BD decouples your clients from the enterprise tier and hides details such as JNDI lookups for the session facade(ServiceLocator) and in some implementations, can actually store the home reference to the session facade. BDs are also very handy if you have non-web based clients. In such a scenario, you may not have the controller which is typically a Servlet. Bundling BDs with stand-alone client jars is a very popular practice.

if I have non-web based clients, for example, using RMI to access EJB tier directly, can I still reuse the same business delegator?


BDs normally have the same set of methods as the SFacade, but nothing precludes you from adding more behavior to BDs. For instance, a BD can act as a "business controller" and selectively choose an appropriate facade to service the requiest. For instance, a BankingServiceBD can look at the request parameters and select either a TellerFacade or a CustomerFacade to service the request. In this case, although the BD exposes just one method to the client, there is some business intelligence involved in how the request is processed and such nuances are neatly hidden from the clinet.
Hope this helps,

So, in an application, the number of BD should always less than the number of session facade. normally there should be only one BD, for ext., in this Banking applicaiton, there maybe only one BD that is BankingServiceBD, am I right?
thanks again!
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782

If I have non-web based clients, for example, using RMI to access EJB tier directly, can I still reuse the same business delegator?

That's a good question. The way to solve this is to define the service access methods in the BD as abstract and provide different implementation classes - in this case RMI and plain JNDI lookup. You will then bundle the RMI BD implementations with non-web clients and plain JNDI BDs with web clients.

So, in an application, the number of BD should always less than the number of session facade. normally there should be only one BD, for ext., in this Banking applicaiton, there maybe only one BD that is BankingServiceBD, am I right?

It is hard to put it in black and white. There could be more or there could be less. I was just trying to illustrate that BDs can access more than one SF and don't just act as dumb delegators.
Hope that helps.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Controller + BD + S. Facade
 
Similar Threads
SCEA Part II - Design Question
ServiceLocator provides reference to SLSB
How to maintain SFSB ShoppingCart reference
Which one between Session Facade and Business Delegate ?
General design questions