EJB 3.1: No-interface view feedback


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.

EJB 3.1: Immediate feedback on EJB Singletons and concurrency needed


Well, its that time again. Time to work on the next version of Java EE and that means EJB 3.1. Since the EJB 3.1 list is a private one, I intend to regularly converse with the community through this blog to tell you what’s going on and to obtain valuable feedback.

One new thing that is being circulated in the expert group is the idea of a singleton EJB much like what we already provide in JBoss EJB 3.0 implementation through @Service beans. Singleton EJBs would be a single EJB instance, created at boot-time, with the same functionality as stateless and stateful beans (remote, local, and web service interface, transactions, security, injection ,etc…)

Singletons and concurrency

There’s a couple of debates going on within the expert group on singletons and their concurrency with multiple invocations. Should only single-threaded singletons be allowed? Since servlets can either ben single or multi-threaded, seems reasonable to allow the same thing in EJB land. But, what do you think? If we support both models, what should be the default? Again, your feedback is needed!

Convenient concurrency

Another idea being proposed is to expand the concurrency model even further and provide convenience annotations over the java.util.concurrent library, for instance

public class MyBean {
   @ReadOnly public int getStuff() {...}
    @Write public void setStuff(int i) {...}

Basically the @ReadOnly and @Write annotations would manage a read-write lock that is implicitly associated with the single instance and managed by the EJB container.

So, if we’re gonna do basic concurrency, what about transactional concurrency as well? Should read/write locks be transactional as well? Held for the duration of a transaction?

If all this is gonna happen, how do we declare the default concurrency? Here’s one idea:

enum ConcurrencyMode {
   READ_WRITE,  // use a readwritelock, but read is the default access if no annotation provided
   WRITE_READ, // use a readwriteock, but write is the default access if no annotation is provided
   TRANSACTIONAL_READ_WRITE, // same as READ_WRITE but transactional
   TRANSACTION_WRITE_READ // same as WRITE_READ but transactional

public class myBean {...}

Feedback needed

Any feedback in the comments section of this blog. Even a simple +1 or -1, or +1 on @Singleton, -1 on concurrency are all valuable feedback!

%d bloggers like this: