Another new feature that’s being discussed in the EJB 3.1 expert group is the of a no-interface view for session beans. This means that your bean classes do not have to implement and publish an interface.

public class StockTrader {
   public void buy(Stock stock, int quantity) {...}
   public void  sell(Stock stock, int quantity) {...}

The default case, with no additional metadata would publish the StockTrader class as a local view on this stateless bean, so, a client would either receive injected or jndi looked up referenced to the StockTrader class.

@ EJB StockTrader trade;

StockTrader trade = (StockTrader)jndi.lookup("StockTrader/local");

The idea behind this new feature is to reduce the number of artifacts needed in simple applications.

Callback/injection issues

The side effect of this new feature is what do we do about public callback and dependency injection methods?

  1. Don’t allow callback methods to be public. Not having callback methods private does make it harder to unit test these type of methods. The SessionSynchronization interface also poses a problem for this approach. Do we not allow SessionSynchronization interface to be placed on no-interface view SFSBs?
  2. Don’t allow DI setter methods to be public. You have the same unit testing issue with this approach as #1.  Also, setter methods would seem very useful as a business method for SFSB and Singleton beans.
  3. Throw an exception if a public callback method is invoked at runtime.
  4. Throw an exception if a public setter method is invoked at runtime. Again, setter methods as part of the business interface would be very useful for SFSBs and singleton beans, but weird for SLSBs. maybe only throw an exception for public setters on SLSBs?
  5. Allow callback methods to be public and callable from the no-interface view
  6. Allow DI setter methods to be public and callable from the no-interface view.  Although very useful for SFSBs and Singletons, would have weird consequences for SLSBs.


Remote no-interface views?

Should we allow remotable no-interface views? IMO, this is bad practice as you making business logic available to a possible untrusted client. Yeah, I know we had this feature in JBoss AOP Remoting, but maybe it is a bad idea? Or should we just let the app developer decide if it is a good idea or not?  Web services already allows a no-interface view, but this view is usually translated to WSDL which is then compiled to a generated Java interface anyways.  A remote view would still be using the business object.

I’m begging for feedback

Any feedback is extremely useful, even a +1, -1 comment.