Monday Apr 29, 2013

JSR 356, Java API for WebSocket

A new article, now up on otn/java, by Java Champion Johan Vos, titled “JSR 356, Java API for WebSocket,” shows developers how to integrate WebSockets into their applications. JSR 356, part of the Java EE 7 platform, specifies the API that Java developers can use when they want to integrate WebSockets into their applications on both on the Java server and client side. The API is highly flexible, and frees developers to write WebSocket-based applications independent of the underlying WebSocket implementation, thus preventing vendor lock in. It also allows for more choice in libraries and application servers. Web clients or native clients leveraging any WebSocket implementation can more easily communicate with a Java back end.

As part of the Java EE 7 standard, all Java EE 7-compliant application servers will have an implementation of the WebSocket protocol that adheres to JSR 356. Vos explains:

“Once they are established, WebSocket client and server peers are symmetrical. The difference between a client API and a server API is, therefore, minimal. JSR 356 defines a Java client API as well, which is a subset of the full API required in Java EE 7….

The Java API for WebSocket is very powerful, because it allows any Java object to be sent or received as a WebSocket message.

Basically, there are three different types of messages:

* Text-based messages
* Binary messages
* Pong messages, which are about the WebSocket connection itself

When using the interface-driven model, each session can register at most one MessageHandler for each of these three different types of messages.

When using the annotation-driven model, for each different type of message, one @onMessage annotated method is allowed. The allowed parameters for specifying the message content in the annotated methods are dependent on the type of the message.”

Check out the article here and learn how to integrate WebSockets into your applications.

Tuesday Aug 14, 2012

Enterprise JavaFX Deployment with LightView: Part 3 now on otn/java

A new article by Java Champion Adam Bien, now up on otn/java, titled “Enterprise JavaFX Deployment with LightView: Part 3,” explores ways to use Maven 3 to build and deploy the LightView application in all available deployment modes. In addition, Bien shows how to sign and deploy LightView with a Java EE 6 application.

Bien explains the basics:

“LightView uses the HTTP (REST) protocol to communicate with the back-end server. For the realization of back-end communication, an external library—the Jersey client—is used. LightView connects with the back end (LightFish) at startup time, so it is not suitable to lazy-load the Jersey dependencies for optimization purposes. Furthermore, multiple JAR files are hard to handle for standalone applications; you have to set up the class path correctly and keep all the moving parts consistent. The most convenient way to deploy Java (and JavaFX) applications is simply by starting them with java -jar my-killer-app.jar and deploying a single file that contains all the dependencies.”

He shows how the class files are packaged with the javafxpackager, which is shipped with the JavaFX 2 SDK, using the exec-maven-plugin and explains the core tasks achieved by Maven and describes the what javafxpackager does behind the scenes. He then shows how the LightView application operates and interacts with LightFish.

Bien concludes by emphasizing that the richness of JavaFX lies in the fact that it is another Java library. “Because JavaFX is ‘just’ an additional Java library, all of the established build, test, and deployment infrastructure can be reused. You can develop JavaFX applications using any integrated development environment (IDE) you like. And best of all, you can use a single language in a project, from the Java EE back end to the JavaFX front end.”

Check out the article here.


Insider News from the Java Team at Oracle!

javeone logo


« April 2014