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.

Thursday Aug 18, 2011

Templating with JSF 2.0 Facelets

A new article on otn/java, “Templating with JSF 2.0 Facelets,” by Deepak Vohra, offers a concise explanation of how to use Facelets, which in JavaServer Faces (JSF) 2.0, has replaced JavaServer Pages (JSP) as the default view declaration language (VDL). With Facelets, developers no longer need to configure a view handler as they once did in JSF 1.2.

From the article itself:

“Facelets is a templating framework similar to Tiles. The advantage of Facelets over Tiles is that JSF UIComponents are pre-integrated with Facelets, and Facelets does not require a Facelets configuration file, unlike Tiles, which requires a Tiles configuration file.

JSF Validators and Converters may be added to Facelets. Facelets provides a complete expression language (EL) and JavaServer Pages Standard Tag Library (JSTL) support. Templating, re-use, and ease of development are some of the advantages of using Facelets in a Web application.

In this article, we develop a Facelets Web application in Oracle Enterprise Pack for Eclipse 11g and deploy the application to Oracle WebLogic Server 11g. In the Facelets application, an input text UIComponent will be added to an input Facelets page. With JSF navigation, the input Facelets page is navigated to another Facelets page, which displays the JSF data table generated from the SQL query specified in the input Facelets page. We will use Oracle Database 11g Express Edition for the data source. Templating is demonstrated by including graphics for the header and the footer in the input and the output; the graphics have to be specified only once in the template.”

Read the complete article here.


Insider News from the Java Team at Oracle!

javeone logo


« April 2014