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

Similar Messages

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

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/]

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.

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.

Business Delegate & Session Facade

1 What is the need of Business delegate? For controlling the interactions between the presentation tier and business tier, session facade pattern can be used.
2 Can a session facade have all the facade related methods. (i.e. entire application has only one session facade). In the pattern documentation, it is stated as this stratergy inefficient. Why is so?

1 What is the need of Business delegate? The delegate provides a client-side business abstraction and acts as a proxy for the business service. Note that it is a proxy, not a facade. In other words, it is a "stand-in" for the biz service, but it is not aggregating several method invocations into one and controlling the processing flow. So, the delegate is not providing a higher-level interface to some underlying system, as would a facade.
So what's the need, if it's just a proxy? Obviously, it adds a layer, so one must consider its benefits versus the drawback of writing, maintaining, and interacting with this extra layer. In a sophisticated system, the benefits are many and will usually outweigh the drawbacks. Following are some of the benefits of using a delegate in the web container as an access point for invocations to the business tier:
- It hides the underlying implementation details of the business service (ie: lookup, creation, access details of EJB...The delegate may use the Service Locator pattern to achieve this goal).
- The delegate translates exceptions as necessary. Service-level exceptions, such as java.rmi.Remote can be intercepted by the delegate and translated into application exceptions. This also helps shield web container clients, for example, from EJB and network-related implementation details, which they should not need to worry about.
- The delegate can attempt retries/recovery efforts transparent to its clients, such that this code can be localized and reused, instead of being duplicated in numerous clients.
- The delegate can also manage a cache of resources/results, limiting unecessary remote roundtrips
- The delegate can be used as a control point for multi-threaded access into the business tier. For example, stateful beans are not to be invoked by multiple client threads simultaneously. The delegate can serialize access, or, as mentioned above, handle exceptions/retries, as necessary.
For
controlling the interactions between the presentation
tier and business tier, session facade pattern can be
used.If you decide to use a delegate in your system, based on considering its benefits, as described above, then you'll typically create a one-to-one mapping between a delegate and a session facade. The delegate is not controlling the processing flow per se, but rather serving as a single access point and proxy as described above. The facade acts as a controller, though, aggregating the interfaces of underlying components and subsystems into a higher-level interface. If you find that your using the delegate more as a facade, we recommend pushing this control code from the web container (where the delegate lives) back to the session bean in the ejb container, so that the logic can be reused across clients.
>
2 Can a session facade have all the facade related
methods. (i.e. entire application has only one session
facade). In the pattern documentation, it is stated
as this stratergy inefficient. Why is so?Having a single facade for the entire system would prove to be quite a maintenance and manageability headache for a non-trivial application. Imagine that every time something changes in any subsystem of the service layer, developers are all making changes to the same file and the same class...Not desirable and not very elegant. At the same time, one does not want to go the other way and create too many facades by having a one-to-one mapping of session facades to use cases, for example. We recommend aggregating a group of related interactions into a session facade, so that it provides highly course-grained access and control to underlying components.
Thanks,
Dan

HOWTO: Session facade

Among various approaches to implementing session facades, I am leaning towards
SLSB (Session Facade)
L___POJO (Business Object)
| L_____POJO (DAO)
L___POJO (Business Object)
L_____POJO (DAO)
1. Is this setup suitable for CMT?
2. Can I use JDBC / Hibernate in my DAOs interchangeably (as in, for one deployment I'd use JDBC and for another one Hibernate)

1. Is this setup suitable for CMT?Yes, why not.
2. Can I use JDBC / Hibernate in my DAOs
interchangeably (as in, for one deployment I'd use
JDBC and for another one Hibernate)Yes. BTW JBoss has useful Hibernate integration features.
http://www.jboss.org/wiki/Wiki.jsp?page=JBossHibernate

Service Locator and session facade pattern

What are differences between Service Locator and session facade pattern?
For me it seems one and the same.
Please explain me in detail. Expecting kind help.
Thanks,
Rahul
Edited by: rahulb1 on Feb 26, 2008 5:07 PM

rdoekes wrote:
The ServiceLocator Pattern is a singleton which hold a map of used DataSources. The idea is that you perform a lookup once and use the cache afterwards. The session facade is just one DataSource lookup.huh? Those J2EE patterns are not really reduced to datasources and the SessionFacade has actually nothing to do with datasources.
Session Facade
It has Facade in it and a Facade is usually used to give a simple entrypoint by providing a standartized interface. The same is now with the Session Facade. You have a Session bean that represents a high-level business component that interacts and calls lower-level business components.
Imagine having client a accessing 5 business objects with the remote calls, which is not an efficient way (network latency) or accessing the SessionFace and the session face is doing all the work through local access.
Service Locator
As J2EE components are using JDNI to lookup for ejb interfaces,DataSources, JMS components, connections etc. isntead of writing all the lookup in many code piecess across the project, you write a service locator that gives you a centralized place to handle the lookup's. It's easier to maintain and to control such a setup.
As you can see there's quite a big difference ;-)
cya,
Nail

Business Delegate and Session Facade 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!!

It depends on your design goals. One of the forces driving the use of patterns is the desire to tier an application and abstract the internals of each tier away from the other tiers. One (normal) benefit of this methodology is that the application should become more portable. Now, if you are using PL/SQL, BMP and CMP, you are mixing and matching portable versus proprietary. This is okay. But you should abstract away whether you are using PL/SQL, BMP or CMP from the business layer (or domain model). Ideally, you could completely swap database technologies (say from relational to object) and only have to re-write your integration tier (your DAO's).
Session facade is simply a glorified Facade pattern. It abstracts the lower-level details of what you are persisting and instead forces you to think in terms of objects. You can use a facade without even remotely touching EJB's. It just so happens that, historically, EJB containers made a mess out of scalability when it came to entity beans. The "session" facade refers to a facade pattern implemented in session beans (that have fewer scalability problems) communicating with the entity beans which do have scalability problems.
So... to make a long story short, use whatever persistence mechanism you desire. Remember that you should be able to completely switch your persistent store from one type or another and simply re-write your DAO's (or CMP deployment descriptors). Using a facade pattern can help towards this end, but don't make it a straightjacket.
- Saish
"My karma ran over your dogma." - Anon

Session Facade Pattern without EJB

All of the session facade pattern examples that I can find are heavily emphasized on EJB. I am planning on implementing a system without EJB's, and am interested in the advantages of using the Session Facade pattern.
Are there any good examples of using the Facade pattern outside of EJB to build a java server system? If there aren't, is there a better way to implement this type of strategy in a non-EJB system?

What is the best way to allow the client to
interact
with Entity objects, without exposing them. ShouldI
implement Value objects that are easily serialized
for transfer across the network?
If you are not using EJB or a distributed
architecture, you do not need DTO's or VO's. They
are an odious construct used to obviate the
shortcomings of remote method calls over anetwork.
I strongly disagree.
They are an obvious and easy model used when the
following characteristics of a system exist.
- Different layers.
- Related data items that are moved throughout the
layers.
- Different usage of the related data items by
different layers.
Yes, I agree. Note the qualification 'if you are not using a distributed architecture'.
None of that has anything to do with remote method
calls over a network. Point of fact the first time I
used them was in a stand alone application with no
network traffic except that needed by the database
driver itself.
Simply create your domain model objects as POJO's
s (plain ole Java objects). Persist and retrieve
your objects via DAO's (data access objects).Your
service layer (facade) will sit on top of thedomain
model, encapsulating method calls into logicalunits
of work.
And how exactly do you move the customer
name/customer address from the DAO to the GUI level?I am assuming the dedicated remoting product the OP specifid, Hessian, will handle moving between the tiers, or at least between the controller/view and the business tier.
- Saish

Session Facade design and TopLink objects

Hi, we are just about to start using Toplink as our ORM tool. Ideally we want to wrap all business logic behind stateless session bean facades. So instead of BMP entity beans we are thinking of encapsulating the relevant Toplink objects in each facade and querying, updating that object when the session facade bean is instantiated.
We are using Weblogic 70. Example code:
e.g. MySessionBean implements sessionbean...
     MyTopLinkObject myObject = null;
     public void populateObject(String myID) throws java.rmi.RemoteException {
          try {
               MyTopLinkObject myObject = new MyTopLinkObject(myID);
          catch (Exception e) {
     public void setMyTopLinkObjectsName(String name) {
     //persist this change via the toplink object...
     myObject.setName(name);
Then in MyTopLinkObject:
public class MyTopLinkObject {
     private String myID;
     private String myName;
public MyTopLinkObject(String myID) {
          build(myID);
public void build(String myID) {
          //read TOPLINK cache and populate this MyTopLinkObject name etc
public void setName(String myName) {
     //persist this change...
     this.myName = myName;
// more gets sets
I will then want to update MyTopLinkObject data in for example in calling. MySessionBean.setMyTopLinkObjectsName("my name") from the remote interface on the client.
So what I want to know is how do I can I do this efficiently. I'm too too versant with TopLink caches etc. For example to read the cache do I have to pass thru a TopLink client/server Session to each Session Facade bean so the cache is available for that read, update etc?
Any other tips is using this design would be appreciated!
Thanks in advance,
J

Don, thanks for ur advice yet again.
I think now I am getting a better grasp of how TopLink should be used. However there is very little doco out there in terms of using TOPLInk in as EJB session facade scenario.
After your advice my thoughts are to provide something like the TOPLInkFactory object as you say which will encapsulate the ServerSession TOPLink API and provide more fine grain access to the TOPLInk API. e.g. instead of having to create a ClientSession in each client call b4 getting a UnitOfWOrk, this factory class would provide a method to do this directly:
public final class TOPLinkFactory {
     private static ServerSession serverSession = null;
     private static final String TOPLINK_CONFIG_FILE = "C:\\test.xml";
     private static final String TOPLINK_SESSION = "toplink";
     public TOPLinkFactory() throws Exception {
          super();
     private static ServerSession createServerSession(ClassLoader cl) throws Exception {
          try {
          Project builderProject = XMLProjectReader.read(TOPLINK_CONFIG_FILE, cl);
     serverSession = (ServerSession)builderProject.createServerSession();
          serverSession.login();
               return serverSession;
          catch (Exception e) {
          return null;
     public static UnitOfWork getUnitOfWork(ClassLoader cl) {
          try {
               return createClientSession(cl).acquireUnitOfWork();
     public static ClientSession createClientSession(ClassLoader cl) throws Exception {
          try {
               if (serverSession == null) {
serverSession = createServerSession(cl);
ServerSession s = (ServerSession)SessionManager.getManager().getSession(TOPLINK_SESSION, cl);
               return serverSession.acquireClientSession();
          catch (Exception e) {
          return null;
Then in my Session EJBs I could write a method like this where Thing is a TOPLInk object mapped to the thing table:
     public boolean setThingStatus(String thingID) {
ExpressionBuilder builder = new ExpressionBuilder();
Expression expression = builder.get("THING_ID").equal( Integer.parseInt(thingID));
ClientSession s = TOPLinkFactory.createClientSession(this.getClass().getClassLoader());
Thing thing = (Thing) s.readObject(Thing.class, expression);
UnitOfWork uow = TOPLinkFactory.getUnitOfWork(this.getClass().getClassLoader());
Thing thingClone = (Thing)uow.registerObject(thing);
thingClone.setStatus("WITH JASON");
TOPLinkFactory.commitAndReleaseUnitOfWork(uow);
return true;
Now if the above looks OK and there are no Thread/Session issues that you could make me aware of (or perhaps you would encourage using a full Singleton pattern instead).
I have another question in relation to ClassLoaders. In this architecture I have been passing around the ClassLoader (as above) to the TOPLInkFactory methods to create the unit of works etc... Is this necessary? Or could I avoid it?
Also I think some people in my team are thinking its a good idea for all TOPLink business objects to extend an abstract base class that contains this behaviour and provides these TOPLinkFactory methods. I no expert on TOPLInk but I would have thought this code should not be coupled with the TOPLink business objects for reasons such as:
1) Why should a TOPLink Person object (attributes name, age etc) e.g. extend a class with TOPLink API methods and attributes - I just don't see the logic there as I thought TOPLink was to be non-intrusive. For example a Person object should not encapsulate a ServerSession object and nor does it need to. To this end they are then coupled and if for example we wanted to move these Person objects to work with another persistence framework then they would have to be rewritten to remove all TOPLInk attribute/method references
2) I would have thought accessing the TOPLInk API is only necessary when the client code needs to invoke calls to the database for reads and updates. i.e. that's where you start getting your sessions, unit of works etc. Like in the setThingStatus Session EJB method (i.e. the client code) above and NOT in your business methods of for example the TOPLink Person object?
Please tell me if I am mistaken!
If you could clear some of this up it would be great.
Regards,
Jason

Business delegate and Session facade design patterns

Does any one tell me, what is the difference between business delegate and session facade 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 ?

Transaction Problem in Session Facade Design Pattern

Hi
Well Sorry for giving wrang title to the topic, coz of which I have not received and reply.
I am using session facade design pattern.
I have Action class calling session facade method "getData" . This method calls "findByPrimaryKey" method in BMP.
Method "getData" has transaction attribute as "RequiresNew" and "findByPrimaryKey" has "Required".
This combination does not assign identity to BMP hence I can not use setter getter method for retriving data(throws nullpointer exception when getter method accessed) I have made sure that I am accessing table and getting data in to BMP but as BMP is not ablle to hoild any identity its not allowing me to use BMP's getter method in session facade.
I have Used Same transaction attribute for create method called by "addNew" method of session facade bean.
Transaction method for "addNew" is "RequiresNew" and for "create" is "Required".
It works fine and gives identity toBMP hense I can use Setter getter method defined in BMP bean.
How can I avoid this and get BMP an identity?
Thanking in Advance,
Chintan.

Sorry, how is this related to JSF?
There's an OO/patterns forum out. Consider reposting the question over there with formatted code.

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 ?

What is meant by session Facade design pattern

please give me

cripes
http://www.google.com/search?q=what+is+meant+by+session+Facade+design+pattern
Who'd have thought it? ;-)
kind regards,
Jos

Session facade vs Command object pattern

Similar Messages

Maybe you are looking for