Thursday Jun 27, 2013

An Overview of Batch Processing in Java EE 7

Up on otn/java is a new article by Oracle senior software engineer Mahesh Kannan, titled “An Overview of Batch Processing in Java EE 7.0,” which explains the new batch processing capabilities provided by JSR 352 in Java EE 7. Kannan explains that “Batch processing is used in many industries for tasks ranging from payroll processing; statement generation; end-of-day jobs such as interest calculation and ETL (extract, load, and transform) in a data warehouse; and many more. Typically, batch processing is bulk-oriented, non-interactive, and long running—and might be data- or computation-intensive. Batch jobs can be run on schedule or initiated on demand. Also, since batch jobs are typically long-running jobs, check-pointing and restarting are common features found in batch jobs.”

JSR 352 defines the programming model for batch applications plus a runtime to run and manage batch jobs. The article covers feature highlights, selected APIs, the structure of Job Scheduling Language, and explains some of the key functions of JSR 352 using a simple payroll processing application. The article also describes how developers can run batch applications using GlassFish Server Open Source Edition 4.0.

Kannan summarizes the article as follows:

“In this article, we saw how to write, package, and run simple batch applications that use chunk-style steps. We also saw how the checkpoint feature of the batch runtime allows for the easy restart of failed batch jobs. Yet, we have barely scratched the surface of JSR 352. With the full set of Java EE components and features at your disposal, including servlets, EJB beans, CDI beans, EJB automatic timers, and so on, feature-rich batch applications can be written fairly easily.”

Check out the article here.

Wednesday May 22, 2013

What's New in JMS 2.0: Ease of Use

A new article by Oracle’s Nigel Deakin, up on otn/java, titled “What's New in JMS 2.0, Part One: Ease of Use,” demonstrates ways in which JMS 2.0 enables developers to send and receive messages while writing less code. Some features of JMS 2.0, part of Java EE 7, and can be deployed in Java EE Web or EJB applications, while others can only be used standalone in a Java SE environment.

Deakin writes:

“The single biggest change in JMS 2.0 is the introduction of a new API for sending and receiving messages that reduces the amount of code a developer must write. For applications that run in a Java EE application server, the new API also supports resource injection. This allows the application server to take care of the creation and management of JMS objects, simplifying the application even further…”

The new API, known as the “simplified” API, is simpler and easier to use than the existing JMS 1.1 API, now known as the “classic” API.

Deakin describes the new API as follows:

“The simplified API consists of three new interfaces: JMSContext, JMSProducer, and JMSConsumer:

* JMSContext replaces the separate Connection and  Session objects in the classic API with a single object.

* JMSProducer is a lightweight replacement for the MessageProducer object in the classic API. It allows message delivery options, headers, and properties to be configured using method chaining (sometimes known as a builder pattern).

* JMSConsumer replaces the MessageConsumer object in the classic API and is used in a similar way.”

Developers can now choose between the two APIs and have access to both the classic and new features. Stay tuned for Part Two, in which Deakin will explore new messaging features in JMS 2.0.

Check out Part One here.

Monday Apr 08, 2013

Technical Article: Java EE 7 and JAX-RS 2.0

A new article by Java Champion Adam Bien, titled “Java EE 7 and JAX-RS 2.0” is up on otn/java. The article demonstrates how Java EE 7 with JAX-RS 2.0 has several new useful features which further simplify development, and lead to the creation of more sophisticated Java SE/EE RESTful applications.

Using a Java-friendly, but simplistic JAX-RS 2.0 example Bien takes the reader through aspects, request interception, client and configuration issues and much more. He concludes the article as follows:

“Interestingly, JAX-RS does not even require a full-fledged application server. After fulfilling the specified Context Types, a JAX-RS 2.0–compliant API can be anything. However, the combination with EJB 3.2 brings asynchronous processing, pooling (and so throttling), and monitoring. Tight integration with Servlet 3+ comes with efficient asynchronous processing of @Suspended responses through AsyncContext support and CDI runtime brings eventing. Also Bean Validation is well integrated and can be used for validation of resource parameters. Using JAX-RS 2.0 together with other Java EE 7 APIs brings the most convenient (=no configuration) and most productive (=no re-invention) way of exposing objects to remote systems.”

Check out the article here.

Friday Mar 30, 2012

Spring to Java EE, Part Three - new tech article on otn/java

In a new article up on otn/java, Java EE expert David Heffelfinger continues his series exploring the relative strengths and weaknesses of Java EE and Spring. Here, he demonstrates how easy it is to develop the data layer of an application using Java EE, JPA, and the NetBeans IDE instead of the Spring Framework.

In the first two parts of the series, he generated a complete Java EE application by using JavaServer Faces (JSF) 2.0, Enterprise JavaBeans (EJB) 3.1, and Java Persistence API (JPA) 2.0 from Spring’s Pet Clinic MySQL schema, thus showing how easy it is to develop an application whose functionality equaled that of the Spring sample application.

In his new article, Heffelfinger tweaks the application to make it more user friendly.

From the article:
“The generated application displays primary keys on some of the pages, and these keys are surrogate primary keys—meaning that they have no business value and are used strictly as a unique identifier—so there is no reason why they should be visible to the user. In addition, we will modify some of the generated labels to make them more user-friendly.”

He concludes the article with a summary:
“The Java EE version of the application is not a straight port of the Spring version. For example, the Java EE version enables us to create, update, and delete veterinarians as well as veterinary specialties, whereas the Spring version of the application enables us only to view veterinarians and specialties. Additionally, the Spring version has a single page for managing/viewing owners, pets, and visits, whereas the Java EE version of the application has separate pages for each of these entities.
The other thing we should keep in mind is that we didn’t actually write a lot of the code and markup for the Java EE version of the application, because the bulk of it was generated by the NetBeans wizard.”

Have a look at the complete article here.

Tuesday Mar 13, 2012

Key to the Java EE 6 Platform: NetBeans IDE 7.1

Oracle’s Geertjan Wielenga has a new article up on otn/java, titled “Key to the Java EE 6 Platform: NetBeans IDE 7.1,” in which he shows how the NetBeans IDE provides the tools, templates, and code generators to support Java EE 6 and its main specifications.

He initially observes that, “When you begin to grasp the breadth and ambition of the Java EE 6 Platform, which covers everything from the model (JPA and Bean Validation), to the controller (EJB and Servlets), to the view (JavaServer Faces), a simple entry point is difficult to find. Enter NetBeans IDE 7.1, which is Oracle’s IDE for the Java Platform, created by the same group of developers who created the Java EE 6 Platform. Here you find tools, templates, and code generators intended to be used in combination with the set of specifications that the Java EE 6 Platform encompasses.”

After offering a tour of the NetBeans IDE 7.1 tools that support Java EE 6, Wielenga ends on a cautionary note:

“While code generators and tools such as those described here are great to help you get your feet wet, a danger is that a lot of code is generated that you don't understand and that you therefore do not know how to debug and maintain. The good news is that far less code needs to be generated in Java EE 6 than before, making it far easier to understand and maintain.

Nevertheless, it is advisable to use tools of this kind intelligently. Start small, focusing on specific APIs. Get to know them via the generated code and then slowly extend the application as you become more familiar with the Java EE 6 Platform. Once you are comfortable with the spec, the tools aim to help you become more productive: combining the leanness of the Java EE 6 Platform with the tools in the IDE, you'll be rapidly creating the core of your application.”

Check out the article.


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.


About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
5
6
7
12
13
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today