Session Facade and Business Delegate Pattern

Hi!
The only way to use the Session Facade Pattern, is if I use EJB for Persistence.
Is valid to do this?:
I use Ejb for simple update, insert querys. From my business delegate I call the Session Facade Layer, and from this I invoque Entyties for persistence.
But if I have complex querys, is correct to make PL SQL Procedures and do the following:
From my business delegate I call to the Dao layer, and from this via JDBC I call the Procedure.
Please explain me the best form to do this, having complex querys for reporting and simple querys for inserts/update.
Is valid to combine the use of CMP (for simple persistence cases), BMP (for complex persistence cases), and JDBC for complex select querys with multiple result rows.
Thanks!!

The session facade is borrowed from the facade pattern, so you could have a facade to almost anything.
A session facade is usually against other beans...for example if you
(Not deployed as CMR)
1. Address bean
2. Phone Bean
3. Customer bean
as entity beans then you can build a session facade such as
CustomerFacadeBean which will CreateReadUpdateDelete(CRUD) address and phone as well when a customer is CRUD ed.
In your case you said you have very complex sql's so one way would be
Business Delegate -> Session Facade -> (Bean Managed) Entity Bean -> DataAccessObject.
If you think this is a overkill then, write a custom pattern such as DataDelegate
DataDelegate -> (Bean Managed) Entity Bean -> DataAccessObject.
In the above scenario you should be quite sure that the system will not evolve into a case mentioned above such as when customer is deleted a phone and address object are also thrown away.
You said this scenario
Business Delegate -> DAO..
I don't think this is a good idea because, a business delegate is a proxy against business objects....and usualy in J2EE business objects are session beans. Entity and DAO objects are data objects not business ones.
Besides if you do the above scenario you will end up wiring all the transactions, etc etc in your DAO which is not a good idea.
Although you could use BusinesDelegates against entity beans it will lead to a misnomer.

Similar Messages

Difference between session facade and business delegate patterns

Hi,
How the session facade and business delegate patterns differ from each other, as both of them have similar and almost same forces to be addressed.
Please address.
Satya.

BTW, in J2EE Core patterns :
When the Business Delegate is udes with a Session Facade, typically there is a one-to-one relationship between the two. This one-to-one relationship exists because logic that might have been encapsulated in a Business Delegate relating to its interaction with multiple business services (creating a one-to-many relationship) will often be factored back into a Session Facade.[I/]

Difference between Session Facade and Business Delegate??

Hello,
I am currently working on design patterns and I am confused what the difference is between the Session Facade and Business Delegate pattern. They look identical.
What's the difference?
Balteo.

We implement Business Delegators (BD) as follows:
1. The client always talks to the BD.
2. The BD then talks to either our Session Facade, Session EJB, or Java Class, etc, etc directly.
This allows the client end code to never change whilst allowing our BD to swap between different providers of the service we require.
It's the good 'ole "layer of indirection" thingy.

Difference between Session Facade and Business Delegate design patterns

Can someone tell me the differences between Session Facade and Business Delegate design patterns

1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
2. SF reduces network overhead while BD reduces maintenance overhead.
3. In SF any change in Session bean would make client code change.
While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
Anybody pls suggest more differences ?

Difference between Proxy pattern and Business Delegate pattern

Hi All,
Can any one please tell me what is the difference between Proxy pattern and Business Delegate pattern.
Thanks in advance.
Basak

The books they were first reported in, and the expressed intent, I guess. Arguably, the Business Delegate pattern is a special case Proxy, with more specific details about what resource is being proxied

How to combine Session Facade and Transfer object?

Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
Thank you!
Astghik

Astghik wrote:
Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
I would simply recommend establishing a service tier. Your services should be stateless. You can go the extra mile and have a session facade, but in the majority of cases, coding to an interface for your service accomplishes the same goals.
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
The idea of the transfer object is very similar to the Command pattern. I think if you investigate that pattern, it will be more obvious. The transfer object reduces network latency by consolidating all the parameters into an object, ideally, this also consolidates multiple method calls. If you combine a transfer object (or command object) with a service tier, you get the best of both worlds. The service can delegate calls to helper objects (or other services or components) using the data in the transfer / command object.
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
The is your domain. It will vary from application to application. The principles above are more general (e.g., patterns and architectural tiers) and should apply to most domains. However, your actual use case may require something different.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Consider using something like iBatis or Spring's JDBC templating to make your life easier with JDBC.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
Versioning is a separate issue. Generally, the more coarsely grained your transfer / command object is, the more changes are likely to impact dependent objects.
Your command or transfer object does not have to be a vanilla JavaBean, where you are basically creating a bean that has data from other objects. You can simply use your command / transfer object to encapsulate already existing domain objects. I see no need to map to a JavaBean with what you have described.
Generally, a method signature should be understandable. This means that many times it is better to pass the method, say, two coarsely grained objects than a signature with a dozen primitives. There are no hard and fast rules here. If you find a method signature getting large, consider a transfer / command object. If you want one service to delegate calls to a number of other services, you can also create a transfer / command object to furnish the controlling service with the data it needs to invoke the dependent services.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
This is a large, open-ended question. If you are going to display it to a user on a screen, I do not see how you avoid a network transfer with the data. The general answer is to not pass the data itself but rather a token (such as a primary key, or a primary key and a start and stop range such as you see on a Google search result). You do want to limit the data over the network, but this comes at a cost. Usually, the database will receive additional load. Once that becomes unacceptable, you might start putting things into session. Then you worry about memory concerns, etc. There is no silver bullet to the problem. It depends on what issues you are trying to address and what trade-offs are acceptable in your environment.
Thank you!
AstghikBest of luck.
- Saish

Help me Developers on sessionFacade and Business delegate

Dear All What is the difference B/w sessionFacade and Business delegate pattern .I have gone through the tutorial.

hi,
quickly, interface describes (methods/functions of) Objects which implements it, while abstrat class contains 'working' methods/functions. If you have severals Objects that have the same methods/functions what all are implemented different ways, use interface. If some methods/functions do the same thing use abstract class.
simple example:
public interface Pet{
public String getName();
public String familly();
public abstract class AbstractPetImpl implements Pet{
private String name=null;
public AbstractPetImpl(String name){
this.name=name;
public String getName(){
return this.name;
public class Dog extends AbstractPetImpl{
public Dog(String name){
super(name);
public String familly(){
return "I'm a dog";
public class Cat extends AbstractPetImpl{
public Cat(String name){
super(name);
public String familly(){
return "I'm a cat";
public class Test{
public static void main(String args[]){
Pet a=new Cat("Kitty");
Pet b=new Dog("Rex");
System.out.println(a.getName());
System.out.println(a.familly());
System.out.println(b.getName());
System.out.println(b.familly());
hope this helps.

Business Delegate Pattern?

What is the real use of Business Delegate pattern in a J2EE architecture design?
I know it is to decouple the Presentation and Business Logic tiers. But all I can see is it just contains one method which basically accepts data (say Value Object) from Presentation tier (in an example I am looking, it is a Command class) in a method and the method in turn just calls a Session Facade Bean from the Model tier. So, why do we need a Business Delegate class in this scenario? And what are the drawbacks of calling the Session Facade Bean directly from the Command class?
Thanks for helping me understand it better.
Rgds,
Tappori

Business delegate typically is a presentation-tier object. It serves to shield the presentation-tier from business-tier implementation details. A Business Delegate can encapsulate business services from one or many Session Facade and could also delegate processing to web services as well.
Here are some fancy links that talk about the Business Delegate guy-
http://forum.java.sun.com/thread.jsp?forum=425&thread=535855
http://forum.java.sun.com/thread.jsp?forum=425&thread=548634
http://forum.java.sun.com/thread.jsp?forum=425&thread=523520
http://forum.java.sun.com/thread.jsp?forum=425&thread=495578
And what are the drawbacks of calling the Session Facade Bean directly from the Command class?You tie the presenation-tier object (Command) to business-tier implementation. The Command class should not have lookup code in it and it should not know that it is calling a remote object. Say you want to replace the EJB implementation with the XYZ implementation. Would you then have to recompile all of the Command classes and/or subclasses?

Business Delegate pattern - need some advice

Hi. First let me apologize for the long post. I could see no other way. I�m building a system that quite large and I need some advice. The system is a type of transaction system, let�s suppose a shopping cart. I�m using struts taglibs and tiles for presentation, struts proper for controller, and POJOs for business logic. Also I�m using OJB for my data tier.
Now I�ve been reading Pro Jakarta Struts (Apress), which BTW is a recommended read to anyone with novice experience in struts and related technologies. I�ve assimilated most of the techniques and patterns described in the book, and most of them make sense to me. However, I�ve hit a snag while reading the Business Delegate and Service Locator patterns.
The way I had though of building my application before reading the book, was to have a wrapper class, such as the following:
public class ShoppingCart {
private IAuthenticationService authenticationService;
private ITransactionService transactionService;
public ShoppingCart() {
     authenticationService = new DBAuthenticationService();
     authenticationService = new DBTransactionService();
public login(String username, String password) {
     String sessionToken = authenticationService.logon(username, password);
     return sessionToken;
private boolean isValidUser(sessionToken) {
     bolean validUser = authenticationService.isValidUser(sessionToken);
     return validUser;
public performTransaction(sessionToken, TransactionVO) {
     if (!isValidUser(sessionToken) {
          throw new AuthenticationException();
     transcationService.performTransaction(TransactionVO);
public editPreferences(sessionToken, PreferencesVO) {
     if (!isValidUser(sessionToken) {
          throw new AuthenticationException();
     authenticationService.performTransaction(PreferencesVO);
}My idea was that my wrapper class would isolate all the business logic and could perform login service in case my application was ever to be used with other presentation layer than struts (standalone client, web services). However I believe that this overlaps the Business Delegate pattern and maybe even totally implements it. The way I understand the code I�m reading in the book, they suggest having a BD for each major service such as AuthenticationServiceBD, TransactionServiceBD, etc� However this would break my single point of entry for authenticating users. I really need some advice on my design and how it fits with the BD and SL patterns (or others). I would also like to know what you think/recommend of my authentication strategy.
thanks in advance
Raphael

Thanks for your reply. This however, I understood. My concern is regarding my application in regards to business delegate pattern. You see I have this class (simplified for clarity):
public class ShoppingCart {
   private ILoginService ls = new DBLoginService();
   private ITransactionService ts = new DBTransService();
   // and so on for all services I offer.
   // then I mirror all the calls of my private interfaces
   // and pass them through internally
   public String sessionToken login(String username, String password) {
        ls.login(username, password);
   public boolean addToCart(sessionToken, itemNo) {
        // check session
        ts.addToCart(sessionToken, itemNo);
   // and so on
}Multiple questions for this one:
1) Am I not already implementing the Business Delegate pattern with my ShoppingCart class since all interfaces are private and all calls are mirrored from the wrapper class (ShoppingCart) to the private interfaces? All services are implemented as POJOs and I am not using JNDI at the present so I don't use the ServiceLocator pattern.
2) I store a reference to the wrapper class (ShoppingCart) in the ServletContext so I can grab it from my Action classes. What do you think of this approach?
3) How many BDs should an application contain. In my case I use just one. What is the advantage of using more?
4) I create my own session tokens in case I ever want to use to business code in a non-web applications where sessions are not available readily. This brings about the problem that I can't pass the interfaces directly to the Action classes because the login session needs to be checked before any calls to services. So all methods include a sessionToken parameter which I use to check the session. This way, if I want to expose some of the services through web services, I can still use a login. What do you think of this approach.
5) Any other remarks are very welcome...
I really need help with this from an experienced programmer. Most things I can handle on my own but with this type of design issue, books just don't cut it. I need experience. I would really apreciate some feedback.
Raphael
ps: I would give all my Duke dollars for this (I only have 30), but I'm not sure how. If you want them I can create a dummy question and give them to you.

The business delegate pattern in petstore

hello
who can tell me which class in the petstore implement the business delegate pattern.
otherwise,who can tell me which website provide sample code for the j2ee design psttern.
thank you very much!

Session beans are usually an application of a Business Delegate pattern.
Web Browserable source
http://java.sun.com/blueprints/code/jps131/src/index.html
Other J2ee stuff.
http://java.sun.com/blueprints/code/jps131/docs/index.html

Business delegate pattern doubt

Hi,
One of the reasons for going for Business delegate pattern is because the business components is vulnerable to changes.
Suppose if the business component has a method
getAccountInfo( int Accountnumber)
The business delegate pattern may have a method
getAccountInfoFromBusiness(Accountnumber int)
return businesscomponent.getAccountInfo(Accountnumber);
and the presentation tier components will have code containing invoking to getAccountInfoFromBusiness method.
Now suppose if business component method signature changes then the signature of business delegate class will also change. This turn in requires changes to presentation tier components. I really dont understand why business delegate pattern is needed.

Hi,
One of the reasons for going for Business delegate
pattern is because the business components is
vulnerable to changes.Abstraction is your first tool to reduce a projects exposure to change.
Secondly filling you code with getter and setters is a bad idea, it's procedural not OO, Objects should express themselves.
So instead of :
Suppose if the business component has a method
getAccountInfo( int Accountnumber)consider
     Account account = getAccount( AccountID accountID ) ;          // or
     Account account = findAccount( AccountName accountName ) ;
     ... AccountInfo = account.toString( FULL ) ;          // or
     ... AccountSummary = account.toString( SUMMARY ) ;     // or
     ... AccountBalance = account.balance() ;This abstracts the Account's identification, from an int, makes your code robust to change, and more flexible, and easier to understand.
The business delegate pattern may have a methodThis is not good, the naming is particularly specific and relies on assumptions about the architecture, it looks like a a global function, yet should be a method of businesscomponent, which is also badly named.
getAccountInfoFromBusiness(Accountnumber int)
          return businesscomponent.getAccountInfo(Accountnumber);
}Instead consider the following. I've used abstraction to hide the implementation details, and the relations model real life, and I can handle my objects polymorphically.
     class Account { ... }
     class DayBook {
          Hashtable accounts ;
          public Account getAccount( AccountID accountID )
               accounts.get( AccountID accountID )
     class MyApp
          DayBook salesDayBook = new DayBook() ;
          DayBook purchaseDayBook = new DayBook() ;
          Account account = salesDayBook.getAccount( theAccID ) ;
          Account account = purchaseDayBook.getAccount( theAccID ) ;
          }Here DayBook is a collection of Accounts, I've two instances, one for my sales one for my purchases.
and the presentation tier components will have code
containing invoking to getAccountInfoFromBusiness
method.
Now suppose if business component method signature
changes then the signature of business delegate class
will also change. This turn in requires changes to
presentation tier components. I really dont understand
why business delegate pattern is needed.The Business Delegate is not really a pattern as such, it is an appliction of the Proxy pattern abstracted into Business language/terminology.

Session facade vs Command object pattern

Hello,
I am debating using the Command pattern as my primary strategy for implementing my J2EE enterprise app business logic and would like some advice.
The general idea is to have only a few types of abstract commands (such as a ReadComand, an UpdateCommand -- I might have a slightly finer granularity than this, I don't know) and implement each use case as a command instance. For example, I might have a command called GetOrderItemsCommand which is a ReadCommand and returns the list of order items (i.e., has a getItems() method) when execute()'d.
The result of my design will be a very small set of stateless session beans with an execute() interface. No entity beans (will use Hibernate) and may very well eventually implement a Message bean interface with a similar executeAsynchronously() type method, if eventually necessary.
I guess the popular alternative (or, more correctly, the norm) is to implement session facades for this.
However, I am attracted to the Command pattern because of its simplicity, it's rapid application development angle, its disconnected-ness from EJB (e.g., a modification to a command does not mean touching any EJB at all, just the command class), and the ability for implementing cross-cutting features (such as transactions or security, although I also plan to use an AOP solution at the POJO level). At the same time, it works as a delegate of an EJB, so it's accessible for all kinds of network clients.
I am also familiar with it's drawbacks (e.g., maintainability for large numbers of commands, per the literature, such as the Marinescu 2002 EJB Patterns book).
So, very few types of stateless session beans (though there may be many instances) -- mainly there for remote client acceessibility and the ability to leverage application-level transactions if needed.
Nevertheless, I have never tried the command pattern approach and was curious if others had feedback or case studies.
Best regards --

You normally use Command to decouple your controller from the view and model tiers. Your take on making command objects 'polymorphic' is interesting, and an angle I had not thought of. In general, I implement command objects rather like the Action class in Struts.
Each command has implements an execute() method declared in the ICommad interface. The constructor of the command object ensures that a given command has all the variables and data required to execute properly. I also create a likes() method that returns a boolean. That way, I can add all my commands to a handler and iterate until on returns true on likes().
- Saish

BUSINESS DELEGATE PATTERN AND DAO

Culd anyone explain me then with an example?
Thanks in advance.

SubjectDelegate subjectDelegate = new SubjectDelegate();
//This is an example which shows that the form values are set in to a transfer object
//and then through the delegate it calls the createSubject() method from ejb's
// subjectVO.setSubjectName(createSubjectPMTLForm.getSubjectName());
// subjectVO.set ........so on....
subjectDelegate.createSubject(subjectVO);
# This will call the method in the delegate(SubjectDelegate)...which will further delegate it to the next level.
public void createSubject(SubjectVO subjectVO)throws Exception {
     try {
          getFacadeInstance();
          subjectFacade.createSubject(subjectVO);
     } catch (Exception e) { }
# here facade is the stateless session bean which can be used to call entity bean to crete the record in database or a DAO
I hope i did not confuse u much.........
Some client----------> Delegate-------->Facade(Session bean)--------->EntityBean or DAO
Reply with ur mail ID if u still did not understand how to use the delegate.
Regards,
Aru

Session Facade and Access to a Non SQL Based Persistent Data Store

Hi,
We are currently using jDeveloper 10.1.3.5 and Oracle Application Server 10.1.3.5. We develop all our applications as Java portlets using Oracle PDK and they are exposed through Oracle Portal.
In our environment, the persistent data is stored on a combination of an Oracle database and a non SQL based persistent data store.
The way we access the non SQL persistent data store is by posting a URL and receiving an XML document back in response. This mechanism is used both for enquiry and update of the persistent store.
We have to create a new XML schema for each entity that we need to access and there are software changes on both our environment (Java) and the non SQL based persistent data store.
In an attempt to shorten development times we are looking to start using ADF faces and EJB3.
We have downloaded the SRDemo tutorial and made it work but there are some challenges.
1. The SRDemo seem to have a very minimal implementation of a business layer. From what I can see, it is essentially some straightforward wiring between database attributes and their viewable representation. Is there a demo/tutorial containing a bit more meat in the business layer that you are aware of?
2. Given our non SQL based persistent data store, how would you go about implementing EJB3 for such scenario. Is it recommended at all? How would you go about integrating the rest of the application (business layer and representation layer) to data arriving from such source?
3. SRDemo is not intended to be exposed as a portlet. Is there a tutorial that we can use incorporating JSR168, ADF Faces and EJB3 in the same application? I also understand that there is a JSF-JSR168 bridge available. Can you provide some pointers here? Where can we find it? Would we be able to use it in jDeveloper 10.1.3.5?
Regards

Matt,
The only way to associate an "x-axis" with a signal in the Write Data VI would be to feed it waveforms, which are constrained to use time as the x-axis unit. There is really no way around this, so in my opinion, the best solution for you would be to use the "rows are channels" conversion and write the frequency and amplitude values to the file independently. Then when you read the file in DIAdem, take the two channels and build a graph out of them there.
Regards,
E. Sulzer
Applications Engineer
National Instruments
E. Sulzer
Applications Engineer
National Instruments

Business Delegate and Session Facade usage.

Hi guys.
I am new to JavaEE and I recently learnt the Business Delegate and Session Facade design patterns. The tutorials from Oracle did gave me a basic idea of what they are and why they are used, but the example didn't really answer all my questions. So I decided to use a real life scenario here and put my question in to it. Any help is appreciated.
Assume I want to create a search employee page for my company, the employees are categorized by his or her department and the province he or she is in. I have in the database a look up table for department and province. (as shown in the image below)
http://oi46.tinypic.com/idvpsl.jpg
So I create three JPA entities, one for each table. Now I am stuck with what is the proper way to design the session facade design pattern. I know that I will need the to access all three entities in my page. (to get the drop down list for Provinces and Departments, and to retrieve list of Employees based on the selection) So should I create a Stateless Session Bean as session facade to access all three JPA Entities or should I create three separate Stateless Session Bean to manage one Entity each?
I came up three component diagram in the below picture.
The first one has one Stateless Session Bean as session facade and manages all three Entities.
The second one has a session facade to manage the relationship between business objects such as ProvinceManagerEJB and DepartmentManagerEJB which will manage the corresponding Entities.
The last one has three Stateless Session Beans that will manage one Entity each, all three Stateless Session Beans can be looked up via the Business Delegate pattern.
http://oi46.tinypic.com/10pqets.jpg
Please let me know if any one of them is the proper way to use business delegate and session facade. or none of them is correct. (which I assume might happen)
Again, thank you so much for your help.
Cheers
Edited by: 992005 on 05-Mar-2013 18:15
Edited by: 992005 on 05-Mar-2013 18:17

Well I can't access any of your diagrams from here so can't comment on them. For dividing the functionality into separate classes, think about
1.) Quantity - Are there many enough service calls to require splitting up or will one application service class be enough? The size of the system is important here.
2.) Are you duplicating logic in the services? e.g save person, delete person in one service and save department, delete department in another e.t.c is better factored into one service with save entity, delete entity calls because the JPA entity manager doesn't know about the type anyway and it's easier to apply common logic (e.g logging auditing) around the calls.
3.) Will each service makes sense on it's own or do you always need the other functionality to completely describe the service? Here it is important not think about entities but about the business use cases. Process1Service is better than Entity1Service, Entity2Service ... EntitynService.Think granule of reuse = granule of release. Only split out individually reusable services. A good way to understand granules of reuse in your system is to think about (or start by writing) test cases for the functionality. Testable code is reusable code.
4.) Will the services change together? At class level you would look at common closure principle (classes that change together should be packaged together). You can apply the closure to the methods as well. Make it easy for future developers to recognize dependent functionality by packaging it together.
These are just general because in enterprise development requirements are king. You can chose to follow or discard any of these rules depending on your requirements as long you understand the impact of each decision.

Session Facade and Business Delegate Pattern

Similar Messages

Maybe you are looking for