November 2nd, 2012

Written by Stoyan Rachev


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

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:

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 (?)


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:

public class HelloBean {

  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.


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)


  • 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 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.


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:

November 16th, 2011

by Stoyan Rachev

In this blog series, I will be writing short summaries of some of the Devoxx 2011 sessions which I attended, mainly focusing on topics that are not covered already by Ivan’s posts.

Devoxx this year is a big. More than 3000 attendees, 5 days, 150 sessions, all packed with rich and interesting content. It’s a great chance to get an overview of the latest technology trends and do a crash course in all those topics you missed so far while focusing on your specific problems, and maybe also an opportunity to see those problems from a different, refreshing perspective.

When choosing which sessions to attend, I chose to stick to the following themes:

  • Methodology – Sessions here to be more “timeless” in nature. Also, I was until recently responsible for managing agile teams, and improving processes and tools is still a significant part of what I do.
  • New Languages on the JVM – I tend to be rather enthusiastic about programming languages in general, but I am also a bit overwhelmed by the current boom of new JVM-based languages. How could we possibly use all that diversity?
  • Java SE – The evolution of the core of the language is going to affect all of us in many significant ways. Also there are some really great speakers – Joshua Bloch, Mark Reinhold, and Brian Goetz among others.
  • Architecture – My current job title is “architect” after all …

Each post will cover a single session or a small number of related sessions, and unlike Ivan’s posts, they won’t necessarily come in chronological order. Whenever I am aware of published slides and other relevant material, I will link that. Read everything if you would like to follow the conference or chose whatever topics are most interesting to you. Any feedback would be great.

February 3rd, 2010

by Pavel Cheshmedjiev

In the last 10 years the Java world welcomed many different technologies, frameworks and initiatives. It is getting harder and harder to keep track of all innovations or at least what Ivko does 🙂 Nevertheless there are technologies that are almost impossible to be missed or neglected. Such technology is the OSGi – Open Services Gateway initiative. For more information visit

While the original focus was on embedded systems OSGi appeared to be too attractive for all in the scope of Java technology. There are a number of papers and much documentation on the OSGi topic so I’ll try to give my point of view and what I think is the real value of OSGi for a typical software developer.

Briefly the OSGi introduces a framework that brings the following main features:

  • Modularity
  • Life cycle management
  • Service orientation
  • Execution environment

So why OSGi ? We have the Object Oriented Java language , we can use design patterns  and different component models.

The first and most important reason for me is that thinking in the context of OSGi makes a developer think in the direction of best design principles such as service reusability, separation of concerns and loose coupling on any application level.  This is very important especially when we design core application layers because usually these layers aim to provide such functionality rather than get use of it. All of these can be achieved with pure language techniques and good practices but not in such lean and standard way. It is also possible that some of the design issues will be left for later refactoring.

Secondly we have all the infrastructure to achieve this – the execution, module, life cycle, service and bundle layers, providing the needed functionality for registering services, life cycle and dependency management etc. We can concentrate on defining the granularity and logic of  the modules of our application , what services it will provide, what are the dependencies and how services interact with each other. Respectively we don’t bother with issues related to the  class loading, application life cycle, service registry etc. Application bundles can be developed and tested in the most agile way – separately, service oriented and with clear dependencies. Once again – we enhance our application design together with all added values from the OSGi specification.

Currently the OSGi Service Platform, Enterprise specification is available at . Now why Enterprise OSGi ? This time it is a bit more confusing – we have the OSGi core, we have all the JEE world – CORBA, EJB, Spring etc and many JEE frameworks are even based on OSGi implementations – from JBoss micro container to Spring DM. Sounds very complicated but the idea is exactly the opposite. We already have the service platform and management.  It is well accepted and adopted. So it is most naturally to think how this platform can be enhanced for the Enterprise world. And what do we need to face the Enterprise world – we need component model, distributed services,  life cycle, session, transaction, persistence management and a set of standard services. So that’s exactly what the OSGi Enterprise specification introduces:

  • Component model
  • Distributed service
  • Web applications and http servlets
  • Event models
  • Management and configuration services
  • Naming and directory services
  • Database access
  • Transaction support
  • Miscellaneous Supporting Services

So on the question why Enterprise OSGi – we have the EJB, CORBA and other component models, JPA specification, DI frameworks and many products that provide similar set of functionalities. So what is new and is it alternative to the JEE world. The new approach that OSGi brings is that it keeps the modular and service oriented nature of the application – we are still thinking in bundles and service, but now a bundle can define a set of components, a component might expose a service and live in distributed environment. We may think of the OSGi enterprise profile to OSGi core as  RMI model to the Java object – it brings many important features, it is transparent, and the main idea is the same. And Enterprise OSGi integrates the JEE concepts very nicely – it does not define alternative of the EJB containers, neither it specifies own persistence APIs – Enterprise OSGi just introduces EJB and JPA service specifications. Existing implementations can be migrated as standard services and keep all the advantages of the specification and their own realization.

So OSGi, Enterprise or both ? Let’s try both with accent on the proven JEE specifications.

Thanks for your time.