beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth Tam" <kentamina...@gmail.com>
Subject Re: EJBControl for EJB 3.0
Date Tue, 18 Jul 2006 23:00:10 GMT
Hi Andrew,

On 7/14/06, Andrew McCulloch <amccullo@gmail.com> wrote:
> I have been reading up a bit on the EJB 3 spec and I would like to look into
> updating / cloning the current EJBControl to support the EJB 3.0 client
> contracts.  I am looking for a few pointers on what features of the new spec
> the community might be most interested in (it may be too new for this
> feedback).  I would also be receptive to any other thoughts on this topic
> that you may have.
>
> My current plan:
> 1. Determine if the current controls works against EJB 3 beans that use the
> back-compat annotations in the spec to produce the remote interfaces and
> other EJB 2.1 artifacts.

+1

> 2. Determine what would have to be modified on the Session Bean Control to
> use only the Business interface through direct lookups.
> 3. Determine what would have to be modified on the Entity Bean Control to
> use only EJB 3.0 artifacts through direct lookups.
> 4. Determine what would have to be modified on the 2 controls to make use of
> EJB Dependency Injection instead of direct lookups.

Can you describe a few use-cases for these items?  I'm not very
knowledgeable about EJB 3, but it seems to me that the EJB 3 client
model has essentially standardized much of the value-add that the EJB
control offered in terms of simplifying the EJB 2.1 client model, to
the point where I don't really understand how what you're proposing
would make life easier for the developer.

Take a classic session bean use-case:

---

EJB 2.1:

Trader trader = null;
try {
     InitialContext ic = new InitialContext();
     TraderHome home = (TraderHome)ic.lookup("MyTraderBean");
     trader = home.create();
     TradeResult tradeResult = trader.buy(stock, shares);
     return  tradeResult;
}
catch (NamingException e) {
     ...
}
catch (CreateException e) {
     ...
}
catch (RemoteException e) {
     ...
}
finally {
    if (trader != null)
        trader.remove();
}


EJB Control:

@Control
TraderControlBean traderControl;

try {
     TradeResult tradeResult = traderControl.buy(stock, shares);
     return  tradeResult;
}
catch (RemoteException re) {
     ...
}
finally {
    if (traderControl != null)
        traderControl.remove();
}

EJB 3:

@EJB
Trader trader

TradeResult tradeResult = trader.buy(stock, shares);
return tradeResult;

---

Between what the spec has done in switching to an injection model,
removing the need for a home interface (and corresponding
indirection), and removing the need to support RemoteExceptions on the
business interface, I'm at a bit of a loss to see where there's real
value to be added in evolving the current EJB control to make it
easier to work with EJB 3 beans.

My sense is that the value of the EJB control today is in providing
EJB3-style ease-of-use on top of EJB 2.1 beans -- and actually, this
is an area where EJB3 didn't really make huge inroads.  Even though
the EJB 3 client model supports accessing 2.1 beans, there is still
value in what the EJB control does wrt collapsing the remote/local &
home interfaces and managing some of the exceptions.

An ideal result would be the ability to treat an EJB 2.1 remote/local
interface just like an EJB 3 business interface.  Collapsing the
remote/local & home interfaces is the easy part, but there's a tension
between simplifying exception handling and ease of authoring.. since
the remote interface will always throw RemoteException, it seems the
only way to eliminate it would be to author a separate interface
(which is a drag)...

Mime
View raw message