EJB3, continued...

More nois e about the new EJB3 spec. I still have to read through it and form an opinion about its state. Right now I'm just an observer.

FUD for BEA?

Could BE A be chocking from the pressure exerted by the likes of IBM, Oracle (and of course, the VC funded open-source JBoss) in the J2EE application server space. Recent industry reports seem to suggest they are losing market share.

Call for comment on EJB 3 call backs.

A call for comments on the possible call back mechanism for the new simpler EJB3 spec.
Personally, I have no problem with the current Interface-defined (current 2.x spec) call backs. I always keep a few abstract base classes providing the implementation of the call-back methods. I have empty implementations, event-based implementations with notification capabilities to subscribers (I use this for clean purposes with anonymous classes).
As for my comment: I would like a number of abstract implementations of the call-back interfaces. So, I suggent a combination of option 2 and 3.

UPDATE: Simplifying object lookup in J2EE

Given time and hand sight, I have looked at what's available for a developer looking for the magical tiger palm to ease the JNDI object lookup blisters.

The first suggested to me is the Service Locator, which I have found to be nothing more than a glorified Façade used to address a shortcoming in the resource binding mechanism (aka JNDI) of the J2EE.

I also read on theserve rside about a light weight EJB 3 proposal. This proposal does simplify the component model to a certain degree. But I would still like to have it simpler, especially with dependency injections. I see no reason why the code should define the semantics of resource lookup when structured configuration could do the job.

For a while I have known about the Inversion Of Control movement but never really understood it until now. I have used frameworks like Avalon, which place an emphasis on inverting control to a lightweight container. This container configures, start, dispatches invocation (performing argument validation to free the code from that), and shutting down the component. In between it provides concurrency management enabling the component to deal exclusively with business domain logic. Now I fully apprehend the IoC concept and I support it. If only the specification over at JCP can reflect this thought pattern things would be great for the enterprise developer community.

Simplifying object lookup in J2EE

Having worked with JNDI and CORBA's naming service (or IOR string object narrowing) in the past, and having experienced the cumbersome nature of simply resolving an object:

• In CORBA's naming service you either have to register your component at startup (preferably using an LDAP based service) and know the compound name for later retrieval. Or use the IOR string by narrowing it into an object. At a previous installation we hade a servlet that served the IOR string based on the name from a request parameter. This is not at all clean; it introduced a troublesome dependency with an unreliable web-based service.
• JNDI I hate also because you still need to encode (albeit you can configure it on your component's descriptor file) it inside your code and perform the lookup with that string name. This code is pretty substantial and cumbersome if you have to use a fair amount of resource objects.

What I would like to have as part of the J2EE specification is the ability to have bean style properties of a resource/component/etc I am writing and configuring this on my descriptor file as simple properties. The JNDI name of the said resource/component/etc will be used on the property value. The Object type translation should performed automatically by the configuration framework.

Consider:

  public class MySessionBean implement SessionBean {
  
    private UserTableEntity mUserTableEntity;
  
    // The rest of the code goes below
    //...
  
    public void setUserTableEntity
                (UserTableEntity pUserTableEntity) {
      mUserTableEntity = pUserTableEntity;
    }
  
    public UserTableEntity getUserTableEntity() {
      return mUserTableEntity;
    }
  }

On the descriptor you then link the entity onto this session bean using the entity's JNDI name as the value. Instead of finding this value from the context (which you currently do and proceed to resolve it and cast it to its class type, hmmm...), all this work will be done for you whenever the object is started/activated or loaded.

This can be easily done on all type of components (servlet, ejb, message beans, etc) that are configurable in a J2EE environment.

Jab: Just another blog!

Well I have also decided to blog about my 50c worth of views regarding the software development field. I have issues, thoughts I think some people might be interested in. I would like to think that I observe pretty interesting stuff in my day-to-day programming. So here it goes.