aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Session Facade Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Session Facade" Watch "Session Facade" New topic
Author

Session Facade

Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Hi all,
I want to know the significance of session facade and when to and when not to session facade.
Thanks in advance!!


"When work, commitment and pleasure all become one and you reach that deep well where passion lives, nothing is impossible."
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html


Groovy
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Thanks for the link, but my issue is dosent the session facade pattern increase the complexity of development considering the different business/session layers we need to implement it.
Also, stateful beans don`t provide pooling, so if you have 1000 users on your server, you have also 1000 session beans instances running !
and if a session facade consists of more than one session beans interfacing entity beans we have n times the instances.
How to solve this issue of multiple instances....
Thanks,
:roll:
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

You can have a stateless session bean as a session facade. The link above talks about how to implement session facade as SLSB and also SFSB and compares the two approach.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks for the link, but my issue is dosent the session facade pattern increase the complexity of development considering the different business/session layers we need to implement it.


Session facade does not complicare development but hides the underlying complexity from the client. The advantages are many.
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Thanks for the link, but my issue is dosent the session facade pattern increase the complexity of development considering the different business/session layers we need to implement it.
I think most of the design patterns add complexity to the development process. You add more layers, more services, etc (data transfer object, service locator, facades, business delegates, you name it). But when you get to the point of maintaining, improving and existing your architecture/application, then you'll see the benefits of using patterns.
my $0.02


I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Thanks again...
Ok, so patterns help in abstracting complexity and blah blah...
so why is it we have to think before inplementing EJB's in our architecture, why cant we just make it a design stratgy for all our applications, instead of just few...
are there overheads to the EJB approach...
Regards,
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

are there overheads to the EJB approach...

Come again. Sorry I did not get you.
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Ok Pradeep...
I mean, is the EJB design stratgy applicable to all kind of applications or depends on other factors such type of application, users, server, etc.?
Can we use EJB for all types of intenet applications...
Are there any constraints to the EJB stratgy?
Regards,
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Can we use EJB for all types of intenet applications...

Yes. Is there any specific you feel that it may not work?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
If your application doesn't need the services an EJB Container provides, you could implement the same logical, easy-to-maintain structure for your application using plain old Java objects.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Can we use EJB for all types of intenet applications...
hmm.. we've got to be very careful when generalizing... That's the reason we have to check/state the requirements in a proper way. Otherwise we might end up in big trouble.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Andres Gonzalez:
Can we use EJB for all types of intenet applications...
hmm.. we've got to be very careful when generalizing... That's the reason we have to check/state the requirements in a proper way. Otherwise we might end up in big trouble.

Where do you think the trouble will be?
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Originally posted by Pradeep Bhat:

Where do you think the trouble will be?

in the whole architecture. As Lasse said, there's no justification in using EJB when you can just use servlets/jsp. I think that all depends on the requirements (transactions, concurrent access, etc.)
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Lasse Koskela:
If your application doesn't need the services an EJB Container provides, you could implement the same logical, easy-to-maintain structure for your application using plain old Java objects.

Just to add to what Lasse said... for a vast majority of J2EE Applications, EJB is unecessary.
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
BTW, you're also right:
Can we use EJB for all types of intenet applications...
Of course we can, I just wanted to point out the consequences.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Chris Mathews:

Just to add to what Lasse said... for a vast majority of J2EE Applications, EJB is unecessary.


JDO/Toplink wouyld be better bet for persistence I guess.
BTW, Chris isnt it very late night for you right now?
:roll:
[ August 29, 2003: Message edited by: Pradeep Bhat ]
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Message accidentally edited by the bumbling bartender. Sorry.
[ August 29, 2003: Message edited by: Chris Mathews ]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Pradeep, I havent tried this but does EJB support threads?

You are not supposed to use threads.
From spec

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread; or to change a thread´┐Żs priority or name. The enterprise
bean must not attempt to manage thread groups.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
BTW, Chris isnt it very late night for you right now?

Pradeep, bartenders don't need sleep. We are able to refill our physical and mental batteries by means of telepathy (we have outsourced sleeping to other people).
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Tejpal Singh:
Pradeep, I havent tried this but does EJB support threads?

See this thread.
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Originally posted by Pradeep Bhat:

You are not supposed to use threads.

So does this mean the EJB model may not work in a threaded environment?
What if i refer a EJB class from another synchronized method of my simple java class that extends Thread class?
How would the bean instance be served to multiple threads?
Will there be multiple instances of the EJB or one instance would be used?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Pradeep Bhat:
BTW, Chris isnt it very late night for you right now?

Yes, but people will go to great lengths to avoid work. Right now I am trying to avoid packing for our impending move on Saturday.
Originally posted by Lasse Koskela:
Pradeep, bartenders don't need sleep. We are able to refill our physical and mental batteries by means of telepathy (we have outsourced sleeping to other people).

Shh... you've said too much.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Suppose I use threads in EJB class is the container going to throw RuntimeException.
I have never used it so the question ?
Yes, but people will go to great lengths to avoid work. Right now I am trying to avoid packing for our impending move on Saturday.
quote:

Saturday.. are you from Australia?
Lasse, I know it is morning for you.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Tejpal Singh:
Will there be multiple instances of the EJB or one instance would be used?

EJB Containers have the option but is not required to pool EJB instances. This is always done (in other words I have yet to see an EJB Container that doesn't) for Stateless Session Beans, Entity Beans, and Message Driven Beans. It is technically possible to pool instances of Stateful Session Beans but it doesn't make much sense and the context switch would kill performance.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Pradeep Bhat:
Saturday.. are you from Australia? Lasse, I know it is morning for you.

No I'm in the US, so Saturday is still two days away... there is just a lot of stuff to pack.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

It is technically possible to pool instances of Stateful Session Beans but it doesn't make much sense and the context switch would kill performance.

Doesn't pooling stateful session bean violate SFSB life cycle.
When the client invokes create the Class.newInstance method gets invoked. If pooling is done the newInstance() method does not get called. My question is life cycle violation acceptable?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
So does this mean the EJB model may not work in a threaded environment?
What if i refer a EJB class from another synchronized method of my simple java class that extends Thread class?
How would the bean instance be served to multiple threads?
Will there be multiple instances of the EJB or one instance would be used?

The client can use threads, the EJB bean class can't (shouldn't).
When multiple EJB stubs (on the client-side) send an invocation request to the EJB Container, the container takes care of serializing the calls or picking up enough bean instances to serve the requests. The container guarantees that only one thread is accessing a bean instance at a time.
This is a different issue than the use of threads by the EJB itself. The EJB should not use threads because they can be a very limited system resource that should be left for the container to manage. A lot of people would like to see a thread pool facility in EJB 3.0, a lot of people feel that's just bundling too much into the EJB spec... We'll see if that'll happen or not.
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
From the thread:

Using JMS obviously causes some overhead when compared to "just launching a thread" but the benefit is that the client can proceed without waiting for the response. From the container's point of view, asynchronous communication is easier to "optimize for performance" as the response time is (usually) not an issue and the asynchronous processing may be scheduled for a lower priority thread.

Chris, i have an implementation where the data is submitted from a form and to a servlet...
The servlet calls my session bean "X" that refers an entity "A" that persists data to the database.
The servlet also calls another JMS class "Y" that calls the same session bean "X" to persist data using another entity "B" to another table.
The above model works for upto 100 simultaneous submits... however if the form is programatically submitted using a java class and using the same EJB and JMS objects, the system hangs due to the long queue of JMS data and eventually the connection is refused.
My other option is to conventinally submit data directly to database using a simple DAO object.
So how would you recomend me to do the same with JMS and EJB?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Doesn't pooling stateful session bean violate SFSB life cycle.

That's exactly the point. The container has to implement pooling without conflicting the "logical" lifecycle. That's why the container is forced to switch context (pick a bean from pool, load the correct state from a data store, serve the request, store the state back into the data store, return bean to pool) and that's why the reference to "killing performance".
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
The servlet calls my session bean "X" that refers an entity "A" that persists data to the database.
The servlet also calls another JMS class "Y" that calls the same session bean "X" to persist data using another entity "B" to another table.
The above model works for upto 100 simultaneous submits... however if the form is programatically submitted using a java class and using the same EJB and JMS objects, the system hangs due to the long queue of JMS data and eventually the connection is refused.
...
So how would you recomend me to do the same with JMS and EJB?

Aren't you already using JMS and EJB? Or did you refer to something else than Entity Beans with "entity"? The fact that the too long JMS queue makes your system hang is something that simply should not happen. How long does the JMS queue get and how many MDBs do you have processing those messages (what's the pool size you configured for the MDB)?
My other option is to conventinally submit data directly to database using a simple DAO object.

If this works, by all means do it like this. This would be the more simple way and thus preferable over the more complex, although more scalable, asynchronous model. Also, whether it matters when the data ends up into the database affects the choice of implementation approach between synchronous and asynchronous.
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Originally posted by Lasse Koskela:

Aren't you already using JMS and EJB? Or did you refer to something else than Entity Beans with "entity"? The fact that the too long JMS queue makes your system hang is something that simply should not happen. How long does the JMS queue get and how many MDBs do you have processing those messages (what's the pool size you configured for the MDB)?

entity = A Entity Bean.
I am not sure of the pool size, its the default!!
I have one TopicPublisher JMS bean that publishes a message.
Mostly the simultaneous JMS messages do not exceed 100 mark but for certain cases the data to be submitted is very large, in that case the JMS messages sent are upto 800-900.
The problem occurs then...
The server log shows rigorous activation and passivation and then the socket exception and connection not found.
Most probably it is the available memory/pool size issue....
the process works fine using conventional DAO objects...
Just thought if can make it work with the existing JMS and EJB objects too...
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I think you should search the appserver-specific forums for a resolution (this sounds like a configuration issue).
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Maybe your right Lasse, it is the configuration issue...
Thanks...
dont you guys ever sleep...
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

You can post the problem in app server specific forum.
Thanks...
dont you guys ever sleep...

Lasse and Chris do not sleep so that other java ranchers can have a nice sleep.
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Keep it up...
Anyways cant have a good sleep in software business...

there are always issues to resolve...
Cheers!
Faisal Khan
Ranch Hand

Joined: Jun 29, 2003
Posts: 285
Originally posted by Chris Mathews:

Just to add to what Lasse said... for a vast majority of J2EE Applications, EJB is unecessary.

Chris,
I have never used EJBs and was considering building them into the application I work on, do you think I shouldn't because we have not felt any need for doing so. How can I determine whether I would need EJB for an app - is it matter of experience in architecting.
Thanks.


The secret to creativity is knowing how to hide your sources.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Requirements and resources available can help you to decide.
Read this intresting artcile
http://www.theserverside.com/resources/article.jsp?l=Is-EJB-Appropriate

Originally posted by Faisal Khan:

Chris,
I have never used EJBs and was considering building them into the application I work on, do you think I shouldn't because we have not felt any need for doing so. How can I determine whether I would need EJB for an app - is it matter of experience in architecting.
Thanks.
Dan Malks
Author
Greenhorn

Joined: Jul 21, 2003
Posts: 10
Hi All,
In responding to Maria in the OO, Patterns, UML forum I touched on some related topics, so I thought you might be interested.
Here's a link to the thread
http://www.coderanch.com/t/98414/patterns/bean-or-not-bean)
Thanks.


<i><b>- Dan Malks</b></i><br />Co-Author of <a href="http://www.corej2eepatterns.com" target="_blank" rel="nofollow">Core J2EE Patterns: Best Practices and Design Strategis</a>
Deepak Alur
Author
Greenhorn

Joined: Aug 25, 2003
Posts: 10
The correct URL for Dan's reply (see above) is:
http://www.coderanch.com/t/98414/patterns/bean-or-not-bean


- <b><i>Deepak Alur</i></b><br />Co-Author of <a href="http://www.corej2eepatterns.com" target="_blank" rel="nofollow">Core J2EE Patterns: Best Practices and Design Strategis</a>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Session Facade