Java EE7 Development and Hosting on OpenShift with Wildfly: Part 1

This is the first blog post in a series where I will cover how to build web applications in Java using Java EE 7. Java EE 7 is the latest release of the Java Enterprise Platform, with a focus on HTML 5 and developer productivity.

Java EE 7 introduced five new specifications covering WebSockets (JSR-356), JSON Processing (JSR-353), Batch Applications (JSR-352), Concurrency Utilities (JSR-236), and Caching (JSR-107). Apart from these new specifications, three existing specifications (JAX-RS 2.0JMS 2.0, and EL 3.0) have major updates and a few other specifications have minor updates. We will cover most of these specifications in detail in this blog post series.

Read full blog here

Deploy WebSocket Web Applications With JBoss Wildfly

Wildfly application server on OpenShift

Wildfly is the new name for the community edition of the JBoss Application Server. The current development version of Wildfly (8.0) will be adding support for Java EE 7. Java EE 7 brings a lot of goodies for Java(EE) developers. One of the features of Java EE 7 is the JSR 356 Java API for WebSockets, which specifies a Java API that developers can use to integrate WebSockets into their applications — both on the server side as well as on the Java client side. In case you are new to WebSockets or JSR 356, please refer to my earlier blog post on this subject. In this blog post, we will install Wildfly on OpenShift using the DIY cartridge and look at the sample WebSocket application bundled with the quickstart.

OpenShift already has best in class Java support with Tomcat 6Tomcat 7JBoss AS7, and JBoss EAP 6 bundled with it. You can also run Jetty or GlassFish on it using the DIY cartridges. In addition, OpenShift provides support for Jenkins continuous integration server.

Read full blog at

How to build Java WebSocket Applications Using the JSR 356 API

It is a well known fact that HTTP(Hypertext Transfer Protocol) is a stateless request-response protocol. This simple design of the HTTP protocol makes it very scalable but inefficient and unsuitable for highly interactive real-time web applications. HTTP was designed for document sharing and not for building today’s highly interactive web applications. HTTP is bit chatty in nature, as for each http request/response, a lot of headers need to be transmitted over the wire.

Before the HTTP 1.1 version, every request made to the server resulted in a new connection. This was improved in HTTP 1.1 with the introduction of HTTP persistence connections. Persistent connections allowed web browsers to reuse the same connection for fetching images, scripts, etc.

HTTP was designed to be half-duplex which means it allows transmission of data in just one direction at a time. A Walkie-talkie is an example of a half duplex device because only one person can speak at a time. Developers have created some workarounds or hacks to overcome this HTTP shortcoming. Some of these workarounds are polling, long polling, and streaming.

You can read full post at