Some quick comments:
- How does this perform with transactions. It's perhaps okay with completely
bean managed transactions. But how about transactions with declarative
transactions. In this case, the logic needs replication.
- How about manageability? This solution could be used in some
infrastructure layer, but not in an application layer. Otherwise, complexity
would increase!
- Thirdly, the programmer will be required to keep "distribution" and
"clustering" in mind while programming! This is possible - but requires more
testing effort!
Regards,
Subbu
----- Original Message -----
From: "Syed Fareed Ahmad" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 22, 2000 4:07 AM
Subject: Session EJBs vs. Java Objects
> 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".
>
>
===========================================================================
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".
