Brian O'Neill's Blog

J2EE Archives

Is J2EE Dead?

I recently presented at the Philly JUG. In my presentation , I asked the question, "Is J2EE dead?", half-kidding, but mostly serious.

I've spent the last six months developing in Ruby (some on Rails). It quickly went from just a past time, where I was developing a silly little beer review site called liquidMirth to serious business applications (at the day job: rVooz). And now I have to admit, the compile, build, deploy cycle of a standard J2EE application seems unbelievably daunting. Combine that with the cumbersome and seemingly never ending twiddling of meta-data and deployment descriptor files required by the libraries and frameworks (e.g. Spring & Hibernate) that are supposedly helping the problem and you have an incredibly unproductive environment for web application development.

I'd emphasize that this is unproductive for web applications, because web applications need to be especially responsive to user requirements. J2EE simply isn't agile enough. There is a fantastic video by someone out at NASA JPL that does a fantastic job comparing the latest web application development frameworks. He does a great job emphasizing this point.

Now, all that said, J2EE != Java and Java's present sweet spot is in SOA, and business process integration, where things need to be transactional, and message-oriented/event-driven. Web frameworks are having trouble in that area, where things don't fit into a nice request/response interaction. On the "back-end" you need a bit more rigor, and typically you need to integrate with systems that won't conform to convention.

So, IMHO -- let more flexible languages accommodate the fickle nature of users. Use Java, with specifications like JBI and SCA, to implement an ESB on the back-end to do the heavy business process lifting, systems integration, and B2B style interactions.

And if you do that, you'll quickly realize that you don't need much (if any) of the J2EE spec to get-r-done. Instead, OpenESB in J2SE, ServiceMix, or Mule fill the bill quite nicely.

just two cents, and here is another nickel's worth of similar sentiment.

Web Services & SLEE -- Whats the best fit?

The word "web" in "web services" is misleading. Web services do not in any way shape or form depend on the "web". They are not tied to any specific protocol or means of invocation. Very generally, a web service is simply a service made available to other loosely coupled systems via an interface that is usually described using the web services description language (WSDL).

In WSDL, the actual means of invocation (binding and port) are implementation details. Their could be multiple bindings because the service supports multiple means of invocation, RMI, EJB and SOAP for example. One can envision a day when HTTP is not the primary protocol via which a service receives and responds to invocations. This lead me to thinking about SLEE.

SLEE is the perfect platform on which to build generic event-driven applicaitons that provide services to external entities. Via the resource adapters, the application achieves the necessary abstraction layer away from the underlying protocols. In a SLEE container, I can develop my service without tying it to any particular protocol or invocation method.

Beautiful, but how does one do this? The question that is open for debate (and to which I don't have an aswer) is how does one develop a traditional web service in a SLEE container? Is it possible? Is it suggested? Do I have to first develop it in J2EE then tack on a SLEE mechanism to expose it via other means? That seems like the wrong solution.

So, I would like to propose an HTTP adaptor for the SLEE container. For some reason, I've "heard" this is frowned upon. In my opinion, this is the cleanest way of building services in the future.

Call me silly but I want to develop my service in a Service Logic Execution Environment (without thinking about J2EE), and whether or not it gets invoked via HTTP requests or someone tapping out morse code, is only an implementation detail.

How does one make this happen?

A Communications Services Framework to fuel IP telephony deployment?

I've started the snowball rolling for a Communications Services Framework. (CSF)

IP telephony deployment has been slowed by some major hurdles, and we have yet to see the "enhanced services" that will really drive the market. I think a web services environment, hosted on Java.Net, through which enhanced communication capabilities could be delivered, combined with a client side API that allows developers to take advantage of these capabilities could solve the problems found in current IP telephony deployments and provide impetus for migration.

One of the first problems I'd like to tackle with the CSF is that of identity. Currently, there is no way to automagically discover a persons contact addresses given one of the set; SIP address, phone numbers, email address, AOL screenname, etc.

This causes many problems. If I am on a SIP phone, dialing a phone number, it will go out through a gateway to the publicly switched telephone network (PSTN). If the person I was dialing happened to be available via SIP as well, the phone call will still travel out to the PSTN, and back in through another gateway because there is no way to discover that the person I was trying to call is available via IP. There is no way to keep from traversing the PSTN. How inefficient? This needs to be remedied.

What if there were a web service, an Aggregate Directory Service (ADS), that given a users contact address, phone number for example, would return the set of contact addresses via which that user is available? It would solve the problem. A SIP Proxy Server could then utilize this web service to determine if it can keep the call on the IP network, before blindly passing it to the gateway. How beautiful? Lets build it.

Because this is not the only such service required by these next-generation communications networks, it makes sense to house the ADS in a larger more general framework. This is the Communications Services Framework.

Bingo. we have a plan. I just started working on the complete specification for the CSF and the Aggregate Directory Service. If you would ike to get involved PLEASE contact me.

This work is licensed under a Creative Commons License.