Friday Jun 07, 2013

New Messaging Features in JMS 2.0

Part Two of Nigel Deakin’s series on JMS 2.0 (Java Message Service), titled “What's New in JMS 2.0, Part Two—New Messaging Features,” is now up on otn/java. While Part One looked at new ease-of-use features introduced in JMS 2.0, Part Two explores five important new messaging features.

First, a new kind of topic subscription called a shared subscription now allows for multiple consumers on the same topic subscription.

Second, developers can now specify a delivery delay on a message so that the JMS provider will not deliver the message until after the specified delivery delay has elapsed

Third, with JMS 2.0, users can send a message asynchronously. As Deakin explains, “This feature is available for applications running in Java SE or the Java EE application client container. It is not available to applications that run in the Java EE Web or EJB container.” According to Deakin, “When a message is sent asynchronously, the send method sends the message to the server and then returns control to the application without waiting for a reply from the server. Instead of being blocked unproductively while the JMS client waits for a reply, the application can do something useful, such as sending a further message or performing some processing.”

Deakin explains that there are two main ways in which you might use an asynchronous send in an application:

* To allow the application to do something else (such as update the display or write to a database) during the interval when it would otherwise be waiting for a reply from the server

* To allow a large number of messages to be sent in succession without waiting for a reply from the server after each message

Fourth, JMS 2.0 allows applications that receive a message to determine how many times the message has been redelivered.

And finally, a Java EE application that needs to receive messages asynchronously does so using an MDB, or message-driven bean, which is configured by specifying a number of configuration properties. Check out the article here.

Wednesday Feb 15, 2012

GlassFish Adds Agility to Java EE Deployment

A new article by Julien Ponge on the front page of otn/java, titled “Adding Some Agility to Java EE Application Deployment with GlassFish,” reports on four noteworthy features in GlassFish that increase agility to Java EE application deployment.

* Session data preservation across redeployments

* Servlet fragments

* Application-scoped resources

* Application versioning

The article relies on a running example called TaskEE, a simple task list application that functions as a deployable application in which tasks are stored in a volatile Web session. Ponge shows how to morph TaskEE into TaskEEPA in order to store tasks in a relational database rather than a Web session.

Directly from the article:
“Deploying and managing Java Platform, Enterprise Edition (Java EE) applications seems like a fairly established activity. Applications can be deployed, undeployed, and upgraded through a combination of deployment and undeployment. Applications use various types of resources, such as JDBC connection pools or Java Message Service (JMS) destinations. Such resources need to be created, configured, and administered using an application server means, such as configuration files, command-line tools, and graphical interfaces. While the tasks do not vary much from one Java EE application server to another, each one is free to provide a broader set of features that make the developer’s and the infrastructure team’s jobs more enjoyable.”

Read the complete article here.

Monday Jan 09, 2012

Interfaces on Demand with CDI and EJB 3.1

A new article by Java Champion Adam Bien, up on otn/java, “Interfaces on Demand with CDI and EJB 3.1” explains that since Java EE 6, interfaces are no longer required by the container in order to realize common use cases, thus enabling developers to use them more consciously and strategically for the realization of business logic. Bien shows how interfaces can now be used as vehicles for encapsulation or abstraction, as they were originally intended.

From the article:

“There is nothing wrong with the abstraction of every implementation with an interface if such an approach can be clearly justified, but interfaces become dubious when you have to introduce artificial naming conventions to avoid name clashes…
Interfaces should be introduced only as a contract for already existing classes, for the realization of Strategy or Bridge patterns, or when you need to design an API, such as Java Database Connectivity (JDBC), Java Message Service (JMS), and so on. In typical business applications, this occurs in only a fraction of all cases.”
Read the complete article here.


Insider News from the Java Team at Oracle!

javeone logo


« April 2014