Brief overview of JSR 343: JavaTM Message Service 2.0

Well, as many of us already know Oracle submitted the JSR for Java EE 7 which is sort of an umbrella JSR for many update in already existing specifications, new versions of some JSRs and some completely new JSRs which will be part of the grand Java EE 7 – JSR 342.

One of these JSRs is the JSR 343 which introduces a new version of JMS into the platform as an evolution of its previous version, JSR-914, and will unify the JMS usage with what added to the platform in the past 8 years.

The following represent some very simple usecases of JMS in the enterprise while complex multiphase transactional usecases are not unusual when MDBs and XA data sources are involved.

  • JMS itself is for asynchronous communication and widely used to communicate some execution instructions from one node or point to another or a set of other points. For example long running queries can be queued using a JMS queue to get processed by another point in the system while the query client is not blocked for the query result.
  • Or it can be used to communicate a common set of instructions to many interested parties which may or may not be around the communication happens, durable subscriptions and persisted topics. For example when clients need to get an ordered set of update messages to update a localcache when they get online after some times. Each client will get its own copy of messages it should receive when getting online.

JMS API provides enough functionalities to realize most of our design out of the specification and the minor features and functionalities not included in the JSR while required by some designs are covered by the vendor specific pack of enhancement and tweaks provided in the broker level and through the vendor specific API.

You may ask if the current JMS API provides all we need, why a new JSR should be put on the table, the answer mainly relies on the theme for Java EE 7 which is making Java EE more cloud friendly and sort of cloud enabled by nature rather than by product.

The details of JMS 2.0 spec goals are listed at the JSR homepage but a brief list can be seen as follow:

  • Community requested features and enhancements.
  • Make the JSR more cloud friendly based on how Java EE 7 will define “to be cloud friendly”
  • Cleanup of some ambiguity in the relation of JMS with other Java EE specs.
  • Make the API easier to use, more annotations and more generics will be involved for the least of the things or maybe reducing number of boxes and lines in the aove figure  could help many to start with the API faster.
  • Make necessary changes to benefit from the JSR-299 or Contexts and Dependency Injection to easier and more unified use of API.

In the follow up posts I will iterate over each one of these bullet points in more details.

I am member of the JMS 2.0 expert group but this post or any other post in my personal blog does not reflect the expert group opinion or the opinion of my employer on the subject unless you could not see this paragraph at the end of the post :-).

 

My slides for Java EE Security session at JavaForum meeting 69

On the 7th of december I presented the “Security in Java EE platform: what is included, what is missing” session in the JavaForum meeting.

Although I arrived somehow late and left  right after the last presentation which was done by Chet Hendrickson but I can say that the athmospher was really friendly and enjoyable. I enjoyed the HTML 5 session and more than that I enjoyed the session presented by Chet, his way of presenting the session was different and pretty fun.

Following album contains some photos from the session.

Four open source Java application servers compared

I was looking at feeds that my email client fetched during the day and I find am interesting one which lead me to an article written by Jonathan Campbell. Article can be found at http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html

Jonathan compared 3 different application server/ servlet container by thier support of Java EE 5 and some other factors. article explained about each feature that he compared application servers based on it. Jonathan did not included GlassFish in his review of "open source Java application servers" and only included 3 application servers/ Servlet containers including Tomcat, Jboss and Geronimo. :-), So I thought I should include some facts here in order to make the comparison fair to all parties.

Including Glassfish into Jonathan matrix will give us the following table: *Notice*

Feature

JBoss 4.2

Geronimo 2

Tomcat 6

GlassFish 2

Java EE 5 compliance

Partial

Yes

No

Yes

EJB 3.0 capable

Yes

Yes

Available

Yes

JSP 2.1 and 2.5 capable

Yes

Yes

Yes

Yes

JavaServer Faces 1.2 support

Yes

Yes

Available

Yes

Custom plug-in support

Yes

Yes

No

?

Business-rules engine support

Available

Available

Available

Available

Hibernate 3.x support

Yes

Available

Available

Yes, based on below description

JBoss Seam support

Yes

Yes

Available

Yes

Clustering support

Yes

Yes

Partial

Yes

Eclipse IDE connector support

Yes

Yes

Yes

Yes

 

Following descriptions further explain some of what Glassfish can provides in relation of the above table

  • GlassFish fully support Java EE 5 with all its related JSRs like JSP 2.1 (JSR 245), Servlet 2.5(154), EJB 3.0(JSR 245), etc.
  • GlassFish support clustering and cluster management out of the box, a cluster can be configured from both CLI and Administration console.
  • GlassFish administration console allows you to configure your load balancer :-), for example you can configure a Sun Java Web Server which works as load balancer to add or add/ remove an instance from its list of servers, either manually or automatically if a new node joined the cluster or removed from the cluster
  • GlassFish allows you to manage resources for entire cluster at once instead of applying them for each instance, for example you can deploy a web application into a cluster of 10 instances instead of deploying it seperately for each instance.
  • GlassFish has a very wide array documentation both from Sun Microsystems (for free) and from GlassFish community.
  • GlassFish installation is as easy as executing 2 commands.
  • Deploying applications into GlassFish or even an entire cluster of glassfish instances is just 2 clicks away.
  • Quality of GlassFish components is out of any question, Metro is well known for supporting new WS-* standards, EJB support uses Toplink Essentials, MQ server is Sun open sourced MQ, etc.
  • GlassFish has very good interoperability with some other open source projects like, OpenESB and OpenSSO which allows you to have what you need to kick start your J2EE application without looking at any additional configuration.
  • Certainly performance is something which everyone should have in mind before considering other feaures, take a look at http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070703-00073.html and http://weblogs.java.net/blog/sdo/archive/2007/07/sjsas_91_glassf.html to find out more about how much capable GlassFish is.
  • GlassFish has connectors for both Eclipse and Netbeans, although other mentioned servers have a connector in Netbeans and Eclipse.
  • Seam support is available from GlassFish 1 upward.
  • Business rule engine support is available from OpenESB project integration.
  • About hibernate support, I cannot understand whether Jonathan means to use Hibernate as a persistence provider or plainly as an ORM, by the way both of this ?features? are available for GlassFish users.
  • GlassFish has an Update center, which allows you to update your application server from a remote repository.
  • GlassFish runs on all mentioned platforms, from Windows to AIX (Glasdfish 2 update 1 runs on AIX) and there is no restriction for you to run it on your platform of choice.

Mentioned items are in relation to what orginal article tried to compare. GlassFish can be used by a ROR developer by its integration with first class ROR IDE (Netbeans 6), It can serve you VOIP and SIP requirement by means of sailfin,etc. Any user with any kind of requirement will find GlassFish a suitable application server.

Although Jonathan did not mentioned GlassFish directly, but he gives his opinion by writing:In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install. Deployment can also be an issue — at least with the recent version of Sun’s Java Application Server. The article co
uld be more complete if Jonathan included GlassFish in his comparsion chart and at then end he could write that GlassFish has problematic deployment procedure

 

An statement which looks odd to me is: In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install., Althogh it will be a complex procedure to setup a Cluser of Websphere (as a commercial application servers ) using websphere XD, Object Grid, and other available packages that faciliate enterprise scale deployment of Websphere, but WebSphere has a decent performance and reliability which is very hard to deny.

Notice: Some parts of this table taken from Jonathan Campbell article published by javaworld and is available at http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html