[Opensource] Architectural Question

[Michael Rimov]

At 03:20 AM 8/15/2002 -0700, you wrote:
>In the middle of designing classes, using Expresso as
>the framework, please comment on the following
>architecture design:
>
>(1)
>JSP--ExpressoController--MultiEntityBean--StoredProcedure
>(2)
>JSP--ExpressoController--SessionBean--MultiEntityBeans--StoredProcedure
>
>- Notice the difference between the 2 methods is
>Session Bean in method(2). Do we need to have a
>Session Bean to act as the facade to multiple Entity
>Beans? So that we can improve on scalability using
>Session EJB on Weblogic? Or ExpressoController in
>Method (1) is also good to handle scalability problem?
>If so, how it handles scalability, say if I form a
>cluster of weblogic servers?

Make yourself a test case.  Try storing objects in a PersistantSession 
object and make sure that they get replicated properly across the various 
servers (it SHOULD, but you should test this before you finalize a design)

If it works, then I'd recommend #1 since you have 1 less inter-VM call 
between the servlet container and the EJB server.  Just make sure you do 
NOT use DBObjects except in a ReadOnly capacity.  Cache and NextNumber will 
NOT work across multiple virtual machines.  However, if you are using read 
only methods, then this does not become a problem, and using EJB for your 
read-write access, you should be fine that way.

If PersistantSession doesn't work properly, then you have one of two options:

-Debug PersistantSession and figure out why it isn't working properly and 
submit it as a bugfix so it can be integrated back into the Expresso source 
tree.

or

-2 Go with Design #2, so Controllers become STRICTLY stateless.multiple

- If we decide to use ExpressoController, how is it
>comparable to Session Bean, as in what features
>ExpressoController has, which Session Bean doesn't
>have and vice versa.

The ExpressoController will work great in that it is multi-threaded (It's 
designed more to be the equiv of a StatelessSessionBean), and 
PersistantSession can be used to store session data.

Note that since PeristantSession requires objects to be Serializable, it's 
quite possible that things will scale across the clusters for you, I'd make 
a test case for storring objects in the PersistantSession and making sure 
that it gets properly replicated between the servers. [Again,either way, 
stay away from use of DBObjects in a read-write manner, but using the 
EntityBeans, I'd say that your architecture is already geared towards that]

>- And how does ExpressoController behaves like the
>stateful and stateless Session Bean? Does it use
>PersistentSession object?

It acts as a Stateful Session bean in that you CAN store objects in the 
session, but it is operating like a Stateless Session Bean in that it in 
itself has no state variables, you have to use the PersistantSession object 
(gleaned by calling request.getSession()) and explicitly use that to store 
anything in the HttpSession.



>- We intend to user Stored procedure to improve the
>performance since we'll be sticking onto Oracle.

Again, by using the EJB's at the back end, you're successfully avoiding any 
issues of Expresso and clusters.  So I'd say it seems like you're on the 
right track.

HTH!
                                         -Mike