Here is my answers:
>-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.
what I have done in my situation is that Session EJB will use the declarative
transactions and Simple Java Object (if required) will make use of JDBC
Connection Object transaction handling explicitly (by calling commit or rollback
in the code). This is one of the disadvantge as the code will require double
maintenance!
- How about manageability? This solution could be used in some
infrastructure layer, but not in an application layer. Otherwise, complexity
would increase!
What do mean by infrastructure layer? The code is simply a wrapper for any
service that can be implemented as a Session EJB. So this is basically a front
end for services. Can u explain a bit more? May be I am unable to understand u
clearly!
- Thirdly, the programmer will be required to keep "distribution" and
"clustering" in mind while programming! This is possible - but requires more
testing effort!
Yeh! this is one of the disadvantages I also need to document. Thanks for
pointing out!
Fareed Ahmad
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Syed Fareed Ahmad/PK/ABNAMRO/NL)
Subject: Re: Session EJBs vs. Java Objects
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".
_________________________________________________________________________
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".
