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.0, JMS 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 https://www.openshift.com/blogs/java-ee7-development-and-hosting-on-openshift-with-wildfly-part-1
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 https://www.openshift.com/blogs/how-to-build-java-websocket-applications-using-the-jsr-356-api