BD-SLSB-SFSB

[paul ms]

Hi,

My current design as

Business Delegator - > SLSB(Session Facade) - > SFSB - > Entity Beans
|
Entity Beans


I have
a) 4 Business Delegator(based on modules)
b) 4 Session Facade(Stateless SB) (one - one with BD).
c) 2 Stateful session Beans
d) 5 Entity beans

I wanted to have SFSB behind Session Facade, since i decided to maintain state in EJB layer rather than web layer.

My question is that

a) Should I put all the methods into 1 SLSB (Sesssion Facade). I basically don't wanted to do it since session facade will grow with more methods
b) Each of the methods in facade interacts with the Stateful Session Beans and Entity beans to accomplish tasks.

Does the above design decision makes sense.

Please let me know ur input guys

Regards
Paul

[Ricardo Ferreira]

Hi Paul,

I understood your design, and i think that you could improve a lot it. Remember that, one of the major things that you will be evaluated, is about the non functional requirements about your application.

Because this, also remember that, entity beans and stateful session beans has passivation, and SLSB are maintained in pool. Since performance is an clear non functional requirement for the travel reservation system, you could impact you solution with too much overhead.

Let me explain better. The passivation process made by the ejb container, is expensive. Consumes to many machine resources (CPU, I/O). If you agree with the use of a primary layer for fa�ade using SLSB, it's ok, no overhead for this. But a second layer with SFSB accessing a thirdy layer based on entity's, there could be a problem.

This is based in the fact, that the ejb container will have the passivation task for many enterprise beans (each client in the web application will have an bean in the ejb tier).

My sugestion is: remove the SLSB layer from all or a feel modules of your project. An SFSB can act as an fa�ade too, accessing a complex system (in this case, the entity beans tier).

Your design could be like this:

<ApplicationController> --> <BusinessDelegate> --> <SFSB Facade> --> <EntityBeans>

and remember: the facade portion of your design must define remote interfaces (distributed architecture), and, in the ejb tier, the facades are going to access the entity beans using local interfaces (local architecture). Since they will be in the same JVM, you can access beans by copy and not by reference. This approach will improve system performance, another non functional requirement.

So, you can maintain your customer's state in the ejb tier, using the SFSB, and do not compromise so much the application performance.

Good Luck!

[paul ms]

Hi Ricardo,
Thanks for your reply.
I thought about it a lot and below are my inputs
Let us consider the flow
BD - > SFSB(Session Facade) - > Entity Beans
In the above case
a) Session Facade(SFSB) will have more methods(not a good
idea)and one that will be difficult to maintain
b) This SFSB must have remote interface
c) The basic responsibility for a facade would be to
1) Manage worlflow
2)Manage conversational state
I decided to maintain session state in SFSB since it is J2EE blue prints best pratice. So the state is shifted to SFSB behind SLSB
d) I don't want to have say 4 SFSB as session facade based on modules(again considering the number of instance based on concurrent users) but would appreciate your valuable inputs, since i am

In the apporach
BD - SLSB(Session Facade) -> SFSB - > Entity Bean
As I stated there are 4 SLSB based on modules and all these are accessed via remote interface
The reson for having session facade as SLSB is based on the pet store approach but slightly different
In petstore Business Delegator calls processEvent method on EJBController thru it remote interface. EJBController calls corresponding EJBAction class. EJBAction class actually does the business processing(Work flow).

As i stated above Session Facade should
a) Manage workflow

So taking pet store approach does not jusity, since EJBAction class does the business processing(Work flow) whereas facade acts as factory
to call appropriate EJB Action class.

So I decided to go for SLSB (Session Facade)and as I said I have 4 Session Facade based on modules. The methods in this session Facade does business processing(Work Flow) calling SFSB and entity bean to accomplish task.

But regaring passivation and activation current App servers has the best approach to provide performance mananging SFSB instance utilized effectively. But even then ...

Let me know your thought guys

Regards
Paul