• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Session Facade

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I want to know the significance of session facade and when to and when not to session facade.
Thanks in advance!!
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
 
Tejpal Singh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Tejpal Singh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

are there overheads to the EJB approach...


Come again. Sorry I did not get you.
 
Tejpal Singh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


Yes. Is there any specific you feel that it may not work?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.)
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1561
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Message accidentally edited by the bumbling bartender. Sorry.
[ August 29, 2003: Message edited by: Chris Mathews ]
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tejpal Singh:
Pradeep, I havent tried this but does EJB support threads?


See this thread.
 
Tejpal Singh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you should search the appserver-specific forums for a resolution (this sounds like a configuration issue).
 
Tejpal Singh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe your right Lasse, it is the configuration issue...
Thanks...
dont you guys ever sleep...
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Keep it up...
Anyways cant have a good sleep in software business...

there are always issues to resolve...
Cheers!
 
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Author
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
https://coderanch.com/t/98414/patterns/bean-or-not-bean)
Thanks.
 
Author
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The correct URL for Dan's reply (see above) is:
https://coderanch.com/t/98414/patterns/bean-or-not-bean
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic