beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McCulloch" <amccu...@gmail.com>
Subject Re: EJBControl for EJB 3.0
Date Wed, 19 Jul 2006 02:47:59 GMT
Kenneth,

Thanks for the input!  Yesterday when going through the possible use cases
for this control I came to much the same thought...  What would be the value
add for an EJBControl on top of EJB3 Session Beans?  Basically I have come
up with a couple of minor points.  First is consistency.  Users who
currently use controls for accessing almost every resources may want to
continue that model with EJB3.   This is a very minor point and by itself
may not warrant this development effort.  The second issue may just be a
misunderstanding of the spec on my part, but, I will mention it anyway.
Does the JEE 5 spec require the @EJB injection to work from every
container?  If not, it may be worth having the control to hide the jndi
lookup users would be required to do if they access an EJB from the web
container.  This simply hides a few lines of code that could also be
abstracted into helper classes by the user.  This would mean that #4 in my
original e-mail may be moot.  So these two points by themselves are probably
not worth creating a EJB3 control, but coupled with any work involving my
first task below may make it a trivial amount of additional effort, I am not
sure.  I also need to investigate further to see if there are any additional
featured introduced in EJB3 that would be worth exposing in an EJBControl,
perhaps surrounding transactions or security.

As far as entity beans go...  I have not gotten to the point where I
understand the changes from 2.1 to 3.0 enough to comment on any possible
value add here.  I hope to get to a more knowledgeable point on the subject
this week.

Thanks,
--Andrew

On 7/18/06, Kenneth Tam <kentaminator@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message