Java2Days 2012: Java EE

Stoyan RachevNovember 7th, 2012Last Updated: November 7th, 2012

0 29 8 minutes read

The Java2Days conference is the major event in Eastern Europe to present the latest trends in Java development. This year, it took place in Sofia, Bulgaria on 25 – 26 October. I was there and enjoyed the opportunity to taste some cutting edge Java, cloud, and mobile content delivered right to my home city, together with few of my colleagues from SAP.

I am visiting this event for a second year in a row. This year, it was bigger and included new things such as “Free Tech Trainings”. There is also a contest (open until 11 November) with some cool programming problems to solve.

In this blog post I would like to share short summaries of some of the conference sessions which I attended, based on my notes and some additional research I did afterwards.

JavaEE.Next(): Java EE 7, 8 and Beyond, by Reza Rahman
Building HTML5/WebSocket Applications with GlassFish, Grizzly and JSR 356, by Reza Rahman
Domain Driven Design with Java EE 6, by Reza Rahman

JavaEE.Next(): Java EE 7, 8 and Beyond

In the conference opening session, Reza Rahman, a Java EE / GlassFish evangelist at Oracle, presented the key changes in the upcoming 7th edition of Java EE, which is to be released in March / April next year, as well as a glimpse into Java EE 8. We learned that cloud support is postponed to Java EE 8, and saw an overview of various changes such as an overhaul of JMS, WebSocket and HTML 5 support, a standard API for JSON processing, the next version of JAX-RS, the Caching API, and more.

JMS 2.0

The new version of Java Message Service (JMS), which is currently being developed as JSR 343, introduces some major improvements over the existing JMS 1.1, which was released almost 5 years ago. It introduces new messaging features such as batch delivery and delivery delay, as well as several changes to the JMS API to make it simpler and easier to use, such as new annotations and dependency injection. With the new API, sending a message involves essentially injecting a context, looking-up a queue, and finally a single method call, with all needed objects created on the fly:

@Inject
private JMSContext context;

@Resource(mappedName = "jms/inboundQueue")
private Queue inboundQueue;

public void sendMessage(String payload) {
  context.createProducer().send(inboundQueue, payload);
}

See also JMS 2.0 Early Draft.

Java API for WebSocket

The Java API for WebSocket (JSR 356) is a new specification introduced for the first time with Java EE 7. It features both server and client-side API for WebSocket, in two different flavors – programmatic and declarative. For more information, see the summary of the dedicated session on this topic below.

Java API for JSON Processing

The Java API for JSON Processing (JSR 353) is also a new specification, which brings the ability to parse, generate, transform, and query JSON content. It features both object model and streaming APIs, similar to DOM and StAX in the XML world. In the future, there will be also binding JSON to Java objects, similar to JAXB, but for the moment, this is still not part of the scope of this JSR. See also JSON-P: Java API for JSON Processing.

JAX-RS 2.0

The major addtions in the next version of Java API for RESTful Web Services (JAX-RS) are the standard client API, as well as new features such as message filters and handlers, entity interceptors, asynchronous processing, hypermedia support, and common configuration. See also JAX-RS 2.0 Early Draft Explained.

Java Caching API

The Java Caching API (JSR 107) has been languishing for almost 10 years, and is finally going to be part of Java EE. It introduces a standard API and annotations for storing and retrieving objects from a cache. The API is pretty simple, for example putting a customer object into a cache would involve code similar to the following:

public class CustomerDao {
  @CachePut(cacheName = "customers")
  public void addCustomer(
    @CacheKeyParam int cid, 
    @CacheValue Customer customer) {
    ...
  }
}

Other Java EE 7 Features

JPA 2.1 adds built-in schema generation, including indexes, as well as support for stored procedures, and other enhancements.
JTA 1.2 introduces support for declarative transactions outside EJB, and the @TransactionScoped annotation.
JSF 2.2 introduces better HTML5 support, including islands of HTML5 in JSF pages and binding of HTML5 input types to JSF beans, as well as additional annotations such as @FlowScoped and @ViewScoped, CDI alignment, etc.
Batch Processing for Java EE is a new specification which introduces an API for batch processing based on jobs which consist of steps, each one involving reading, processing, and writing items. Instead of implementing interfaces, the methods for reading, processing, and writing items can be simply annotated as @ReadItem, @ProcessItem, and @WriteItem
Bean Validation 1.1 introduces method constraints and injectable artifacts.

Java EE 8

The 8th edition of JavaEE is expected to be released 2 years after Java EE 7, which is in 2015. It will focus on the following areas:

Cloud, PaaS, multitenancy
Modulatiry based on Jigsaw
Even better HTML5 support
More CDI and EJB alignment
NoSQL (?)

Summary

This was indeed a lot of information to swallow in 45 minutes, but the speaker did a good job delivering it. It seems that Java EE 7 will be a solid addition to the series, and even more major features will be coming with Java EE 8.

The slides from this session are available here. You can try these new features out by downloading GlassFish 4. To keep up-to-date, you can follow The Aquarium blog.

Building HTML5/WebSocket Applications with GlassFish, Grizzly and JSR 356

This was in fact the last conference session, in which Reza Rahman presented one very interesting part of the upcoming Java EE 7, namely support for WebSocket.

WebSocket Primer

Two-way communication over the half-duplex HTTP protocol has always been a challenge. Flavors of server push such as polling, long-polling, or AJAX have been introduced but they are complex, inefficient, and wasteful.

In contrast, WebSocket provides a bi-directional, full-duplex communication channel over a single TCP socket. Unlike pure TCP, however, all communications are done over the standard HTTP port (e.g. 80), which allows it to work in environments which block non-standard Internet connections using a firewall. It was originally proposed as part of HTML 5.

W3C defines a very simple WebSocket JavaScript API and a WebSocket Protocol. The Protocol defines “handshake” and “framing”, where the handshake defines how a normal HTTP connection can be upgraded to a WebSocket connection, while the framing defines wire format of the message. The API defines methods for opening and closing a connection and for sending a message in various flavors. It is currently supported by all major browsers.

Java API for WebSocket

Java EE 7 introduces WebSocket support via the Java API for WebSocket (JSR 356). The reference implementation is called Tyrus and is part of GlassFish 4. The specification defines two different API flavors – programmatic based on interfaces and declarative based on annotations, both for the client and the server.

The declarative API is overly simplistic and completely hides the WebSocket internals from the developer. In its simplest form, a WebSocket endpoint can be defined as follows:

@WebSocketEndpoint("/hello")
public class HelloBean {

  @WebSocketMessage
  public String sayHello(String name) {
    return "Hello " + name;
  }
}

There are the following annotations:

@WebSocketEndpoint is a class-level annotation that declares a POJO to accept WebSocket messages. The path at which the messages are accepted is specified in this annotation. Optionally, it can also specify decoders, encoders, and subprotocols.
@WebSocketMessage is a method-level annotation that for the method that is invoked when the endpoint receives a message. The value returned from this method is sent back to the other side.
@WebSocketOpen and @WebSocketClose are method-level annotations for intercepting connection open and close events.
@WebSocketError is a method-level annotations for intercepting errors during the conversation.
@WebSocketParam is a parameter-level annotation for path segments that are passed as parameters.

Summary

WebSocket seems to be indeed a much better alternative to the currently used server push approaches, so it’s cool that support for this is coming in JavaEE quite soon.

The slides from this session are available here. There is also a similar presentation already available on Slideshare, Building HTML5 WebSocket Apps in Java.

Domain Driven Design with Java EE 6

The third Java EE session by Reza Rahman focused on Domain Driven Design (DDD). This is an approach to developing software by connecting the implementation to an evolving model. Its premise is placing the project’s primary focus on the core domain and domain logic, and basing designs on a model of the domain. The term was first coined by Eric Evans in his book of the same title. DDD emphasizes a return to Object Oriented Analysis and Design, and is gradually gaining popularity as an alternative to traditional architectures originally popularized by J2EE Blue Prints. The goal of the session was to demonstrate how DDD can be implemented using Java EE 6 by mapping its core concepts to Java EE specifications, and by providing a comprehensive code example.

Core Concepts

Domain: A sphere of knowledge (ontology), influence, or activity.
Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
Ubiquitous Language: A language structured around the domain model and used by all team members.
Context: The setting in which a word or statement appears that determines its meaning.

Building Blocks

The diagram below is the “canonical image” of Domain Driven Design.

Entity: An object that is not defined by its attributes, but rather by a thread of continuity and its identity.
Value Object: An object that contains attributes but has no conceptual identity.
Aggregate: A collection of objects that are bound together by a root entity, otherwise known as an aggregate root.
Service: When an operation does not conceptually belong to any object.
Repository: Methods for retrieving domain objects should delegate to a specialized Repository object.
Factory: Methods for creating domain objects should delegate to a specialized Factory object.

Maintaining Model Integrity (Strategic DDD)

Layers

User Interface: Shows the user information and receives input.

Application: Thin layer to coordinate application activity. No business logic or business object state is in this layer.
Domain: All the business objects and their state reside here. Objects in the domain layer should be free of concern about displaying or persisting themselves.
Infrastructure: The objects dealing with housekeeping tasks like persistence.

Mapping DDD to Java EE

DDD Concept / Layer	Java EE Concept
Context	Packaging, Modularity
UI Layer	JSF, Servlet
Services, Application Layer	EJB, CDI
Entities, Value Objects, Repositories	JPA (Entities), CDI
Infrastructure Layer	JPA (Entity Manager API), JMS

Sample Application

The sample application that was demoed during is an evolution of the DDD Sample already available at SourceForge. It is a Shipping Tracker application. The packaging structure of the application reveals clearly the different layers mentioned above. The renovated DDD sample application will be published soon as a java.net project. Until then, you can download and play with the existing DDD sample, it builds with Maven, can be run in an embedded Jetty, and of course imported into Eclipse for a deeper look.

Summary

I found DDD quite interesting, even though initially it was a bit hard to grasp. Reza explained everything in details, however this shortened the time available for demoing and showing the code of the sample application. I and my colleagues were intrigued by the fact that the business logic in the sample is captured in the Domain layer classes themselves, without any controller of facade. This seemed initially as a somewhat unusual approach to me but upon second though it made perfect sense.

The slides from this session are available here. While researching DDD after the conference, I found the following interesting resources: