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

Similar Messages

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

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

Using DAO ,TO Pattern without EJB

Hi,
I am developing a web application without EJB. I understand those patterns need not use EJB framework. However, it smees to me that without EJB, the role of TO may be simpler.
In my design, the meaning of TO is to separate the layer between business tier and data access tier. Upon doing some back-end enquiry, the DAO create related TO which can be translate to the business / veiw objects. And the caching will be done on Web tier but not TO layer instead.
Am I right? Would you please give some comments? Thanks a lot.

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 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.

=== SESSION FACADE v/s BUSINESS DELEGATE ===

Hi
Can anyone help me with my design here - I am not sure whether to use a Session Facade or a Business Delegate in the following scenario:
[Our application is pure J2EE and does not use EJBs]
PRESENTATION-TIER
I have a Command and Control strategy employed in my presentation tier where requests are intercepted by a controller and processed by helpers delegating to appropriate commands and dispatch appropriate responses.
PRESENTATION-TIER - COMMANDS
The Commands will invoke appropriate Business Methods in the business tier to retrieve data (mostly).
BUSINESS-TIER
Now - most of my business methods use the DAO pattern to retrieve data and are effectively dealing with Data Beans (Value Object beans) - passing them back to commands.
I can clearly see the use of a generic Interface at the Business tier - i.e., rather than expose the Buiness Methods direcly leading to increased coupling between presentation and business tiers.
BUT THE CONFUSING PART IS - DO I USE A SESSION FACADE OR A BUSINESS DELEGATE TO INTERFACE WITH MY COMMANDS??? What is the difference? I have looked at Sun's J2EE blueprint and cant make out the clear cut difference between the two.
Can anyone help?
thanks
Aswin

I agree with you, Business delegate and Session facade are quite alike.
I believe that you could use the Business delegate pattern as a facade. Possibly, you could argue that the Business delegate is an extension of the Session facade pattern. However, I think that SUN thinks that a Business delegate should be a singleton while a Session facade is a session EJB. My firm belief is that you could create a business delegate that is a session EJB instead.
But, you could also use both pattern as some one else suggested.
In your case when you do not use EJBs, I would suggest that you use a facade which could be design like a business delegate. However, as there aren't any EJBs, you will not need a service locator. In this way, you will have a design that can be extended (without any impact on the the presentation tier) to use EJBs in the future.
Remember, SUN's core J2EE patterns assume that you use EJBs. If you don't, they have to be adapter a little bit.

Error while calling local session bean from session facade

Hi Everybody,
I was to execute example of session facade pattern. All the files compile properly, but when ejbc command is run, i get the following error:
ERROR: Error from ejbc:
     In EJB *MANAGER, method create() exposes local interface types or local home interface types through the remote home interface of the bean. This is not allowed.
ERROR: Error from ejbc:
     In EJB *MANAGER, method remove(java.lang.Object) on the home interface does not throw java.rmi.RemoteException. This is a required exception.
     In EJB *MANAGER, method create() on the home interface does not throw java.rmi.RemoteException. This is a required exception.
ERROR: Error from ejbc: In EJB MANAGER, the home interface be.telenet.sso.servicelayer.ebiz.ManagerHome must extend the javax.ejb.EJBHome interface.
ERROR: ejbc found errors
Thanks
Amit

If you are looking a local interface up through JNDI, try using the "java:comp/env" namespace. Also, if you post these questions here about EJB, say what vendor you are using because this stuff is pretty new and there will be differences/bugs/etc.

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

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

[HOWTO] JSF + Session Facade + Entity Bean (EJB3)

I'm trying to find a tutorial that shows the advisable way to use JSF with EJB 3 entity beans using the Session Facade pattern (?), but the only tutorials around show very basic usage of JSF (validation, conversions etc.).
The only thing that is close is this: http://forum.java.sun.com/thread.jspa?threadID=5122284 but still not what I'm looking for.
Is there any documentation available out there..?
Message was edited by:
HakelRausd

Hi,
I updated the online doc in blueprints solutions catalog with a small explanation of using JSF with EJB Session Bean at https://blueprints.dev.java.net/bpcatalog/ee5/persistence/ejbfacade.html
I will add an image soon too. The basic idea for JSF and EJB3 programming model is
JSF Page --> JSF Managed Bean(backing bean) --> Session Bean --> Java Persistence Object.
In general, ther would be several JSF pages,and several JSF Managed Beans, and several Java Persistence Objects, but fewer Session Beans. The Session Bean would be expected to be shared and accessed by several managed beans with with Session Bean serving as a facade to the Java Persistence Objects, so there would be few Session Beans.
The Session Bean would usually be a local Session bean and would only be remote if-and-only-if you wanted RMI-IIOP access. Usually web components like Servlets and JSF Managed Beans use local access to the Session Beans and the access is within the same VM, no remoteness.
Most of the time, the Session Bean would be a Stateless Session Bean, and would not be a Stateful Session Bean.
hth,
Sean

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 ?

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 ?

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

(ejb 3.0) stateful session facade?

Hello,
(1) Would you consider stateful session facade (whose client is a servlet) a bad design?
(2) How to have a stateful session facade referenced in a servlet? I am using Sun Application Server Platform Edition 9.0 and trying to make an injection:
@EJB(name="ejb/KOGSessionFacade")
protected KOGSessionFacade sessionFacade;
but then I get this error in deploy-time: "A stateful session bean can not be injected into a servlet. Please refer to EJB 3.0 Persistence API Specification section #5.2 for further information."
Thanks.

Using a Stateful Session facade from a Servlet is not necessarily a bad design. In some cases, you may want to do some cleanup work on completion of a transaction. Stateful Session beans provide a convenient way (By implementing SessionSynchronization interface) to do this.
In the servlet programming model, Servlets are not designed to be single threaded. So if you inject a StatefulSessionBean (SFSB) references then multiple threads could be possibly be invoking the SFSB concurrently. In this case, the EJBContainer (as required by the specification), will throw a well defined exception.
What you may want to do is to place this SFSB reference into you Servlet session.

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.

Session Facade Pattern without EJB

Similar Messages

Maybe you are looking for