Dear All,
As I laid the base for *When to use EJBs? was:Session EJBs vs.Java Objects *
discussion thread. The conclusion I have from all these discussions is that
there is no hard and fast rules that enables the designers to choose between
simple Java Object and Session EJB. I have come up with solution and require
experts feed back on my solution.
What I wanted to achieve in my situation was a kind of switching between a
Session EJB and Simple Java Object based on requirements of deployment
environment. As we need more scalability - we switch to Session EJB and when we
require less scalability then we can have the simple Java object in place of
Session EJB. The developed system will have the switching capability based on
number of concurrent users, system load or any other business/network/technical
constaraint/requirement
SOLUTION:
As the business interface is very good strategy to decrease the dependency on
Remote Interface & vendor and saves us from deployment time Remote object
generation errors. I have used this strategy as the base for my solution. The
client will use this wrapper class to access the EJB. The client will operate
with the Business Interface only.
Please note that the code for decision about switch between the EJB & Simple
Java Object is made in the *static* block so this means the information about
the switch remains as it is until class is reloaded into the JVM. So you should
place it in a class path directory that is enbale for reloading every time there
is some change in the file. This is usually supported by the Application server
vendors.
// Wrapper Class Used by the client
final class MyBusinessWrapper {
private static Context ctx = null;
public final static MyBusinessInterface create(...)
{
if ( ctx != null )
return createEJB(..);
else
return createSimpleObject(...);
}
private MyWrapper();
private static MyBusinessInterface createEJB(...)
{
// EJB Creation Code
}
private static MyBusinessInterface createSimpleObject()
// Simple Object Creation Code
}
static
{
boolean scalable = false;
// *read configurations settings from a File or JNDI Source, and set
scalable field as appropriate* //
// /* scalable = ? */ // where ? is specfied in the setting //
if ( scalable == true )
ctx = new InitialContext();
}
}
Please note that the Remote Interface of EJB will extend the business interface.
The Simple Java Object will also implement the Business Interface.
Disadvantages
As every solution has the side effects associated with it and no solution can be
ideal we can only choose a solution which fits best within the current problem.
So my solution also have some cons as:
1) The developer need double effort as the business logic will be maintained in
both simple Java Objects and EJB bean class
2) The developer needs to program so that the code fits in both EJB bean class &
simple Java class like static variables are not allowed in the Bean class or Env
vars are avilable only in the EJBs and they are not available in Simple Java
Objects.
Please let me your feedback on this solution!
Fareed Ahmad
_________________________________________________________________________
Disclaimer:
"This message is confidential. It may also be privileged or otherwise protected
by legal rules. If you have received it by mistake please let us know by reply
and then delete it from your system."
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
