I've just finished reading Marc Fleury's article Why I love EJBs and its certainly an interesting read.
I think the title 'Why I love J2EE' would have been better, since in the whole document he barely talks about EJBs (server side Java Beans) but instead talks mostly J2EE services, caching and interceptors. For me the core messages of this paper were
- caching information locally is a great way to boost performance
- colocating your services in your web tier can boost performance (i.e. not using server side EJBs and instead using POJOs)
- using interceptors to add services like transactions is a good thing
- that CMP is good
Barely is there a mention of EJBs themselves as server side components. Indeed the paper actively encourages the use of POJOs and to try avoid using remote EJBs.
I pretty much agree with most of the above points. I'm suprised that Marc didn't cover the power of messaging via JMS. Store and forward, publish and subscribe and asynchronous messaging very powerful tools (coupled with clustering, load balancing and fault tolerance) for caching and remoting when building scalable distributed systems.
One area I disagree with Marc is on CMP. CMP is one way of implementing persistence for sure though JDO, TopLink, ObjectBridge, Hibernate and so forth are others which are good too. Persistence is one of those complex areas with lots of ways to do it that I don't think there's ever going to be a one-size-fits-all clear winner, It very much depends on your requirements. Certainly CMP and JDO are the leading standard APIs to persistence. The most important aspect isn't which API you use for persistence but that you can use an efficient caching mechanism.
Caching
Caching is vitally important to building any kind of scalable system. It has 2 primary benefits
Reduced latency. Caching typcally greatly reduces latency and CPU usage at the client side (for example in the web tier) and helps to promote an efficient and scalable SEDA style archicture. The less time waiting for remote data to arrive from some back end system, the quicker you can finish processing the current request and get on to to the next one. i.e. your web tier can handle more load on less hardware and provides a snappier response.
Reduced load on back end services. When a cache is used there's no need to hit an expensive back end service (database, EJB/CORBA service etc). Typically caching takes a massive load off the back end servers which can directly result in significant hardware and software licence revenue cost savings for most enterprises.
As you can probably tell by now, I'm pretty keen on caching which is why I've been a long time proponent of the JCache JSR and am also the architect of a commercial JCache product, SpiritCache. Incidentally its been nice to see both Apache and JBoss showing a keen interest in the JCache initiative. I expect JBoss to start touting the power of JCache soon.
Going forward
I'm glad to see that the JBoss folks get it, that its the services inside J2EE rather than EJB per se thats important.
What I think we need to do is to move away from EJB and get back to writing POJOs again and just use AOP and interceptors to implement remoting when we actually need it - which is rare, since mostly we can colocate back end services with the web tier.
If we need to communicate with remote services we have lots of choices. If clients and servers are both Java we can reuse EJB as a possible remoting engine. If we wish to support store and forward, publish and subscribe or just asynchronous messaging then JMS is a great choice. Or we can use other remoting engines like Axis or Glue or AltRMI. Which implementation we choose should depend on the system in question and be configured at deploy time via deployment descriptors and interceptors.
So I think the future of building enterprise Java applications is going to be to take an XP approach. Start with the simplest possible approach, a POJO approach (rather than EJB), then we can use those services from J2SE and J2EE as we need them (JCache, JMS, transactions, persistence, remoting etc). This coupled with an AOP approach to deploy most of these services invisibly via interceptors will allow us to build distributed systems effectively without wasting time grokking specifications and things we don't need.
12:03:28 PM 
|
