Comment lines by Kevin Haverlock: A closer look at the WebSphere Application Server Feature Pack for Web 2.0

The same technology used by IBM® to create dynamic Ajax style applications is available to you through the IBM WebSphere® Application Server Feature Pack for Web 2.0. Learn how some of these key features can have a big impact on your Web applications. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Kevin Haverlock (kbh@us.ibm.com), Software Development, IBM

Author photoKevin Haverlock is a software engineer for IBM in Research Triangle Park, NC. He has worked on various portions of WebSphere Application Server dating back to 5.0. His most recent assignment was the Web 2.0 Feature Pack for WebSphere. Kevin is currently working on web development tooling to help customers enhance their serviceability of WebSphere Application Server.


developerWorks Contributing author
        level

24 June 2009

Also available in Chinese Spanish

Now, back to our feature (pack) presentation

It’s been exciting to watch our development teams within IBM Software Group create and deliver new and innovative designs based around Ajax (Asynchronous JavaScript and XML) style architectures. Ajax represented the next generation of Web development and lent itself to the creation of innovative browser-based user interfaces. As a developer, I have seen how the line has become blurred between heavyweight graphical user interface applications that run on their native operating systems, and the richness that is possible with today’s browsers and devices.

The same technology used by IBM developers to create Ajax style applications is also conveniently available to IBM WebSphere Application Server users -- at no cost -- through the Feature Pack for Web 2.0.

Unlike other WebSphere Application Server feature packs, such as the ones for EJB 3.0 and Web services, the WebSphere Application Server Feature Pack for Web 2.0 is application centric. This means that the Feature Pack for Web 2.0 does not modify the internal WebSphere Application Server runtime to provide additional benefit and functionality. Instead, the feature pack provides a set of Java™ libraries and JavaScript™ files that you can use when developing your applications. I point this out because I have encountered users who are reluctant to try a feature pack for fear that it might introduce new behavior in the application server runtime; that is not the case here. When developing with the Web 2.0 feature pack, you can pick and choose the features or technologies you want to include in your applications, and then deploy the applications as you normally would.

I wrote an overview article on the Web 2.0 feature pack when it was originally released in 2008. Here, I want to bring your attention to just a few of the key features that can make a big impact on your Web application development.


A look at key features

The Feature Pack for Web 2.0 V1.0.0.2 contains elements that are aligned with client-side and server-side runtimes. On the client side is the Dojo Toolkit 1.3.1. On the server side is a rich set of libraries and connectivity features. Let’s take a closer look at both sides.

On the client side

The Dojo Toolkit 1.3.1 is a powerful open source JavaScript library that you can use to create rich and varied user interfaces running within the browser. Dojo supports all major browsers and renders well on both the Palm Pre and Apple iPhone, which are based on the WebKit browser engine. The Dojo Toolkit abstracts away the peculiarities and quirks of platform browser implementations.

The Dojo Toolkit is divided into five sections:

  1. Base is the kernel of the Dojo Toolkit and consists of a dojo.js file that is designed to be compact, and optimized so that it takes minimal time to download to the browser. The base contains useful utilities, such as bootstrapping and event notification, to name just a few.
  2. Core contains a wide variety of GUI widgets and the IO transport for XHR requests to the server.
  3. Dijit builds on the base and core by providing a rich set of additional widget controls that are internationalized and enabled for accessibility.
  4. Dojox contains aspects of the Dojo Toolkit that represent innovative material. Dojox modules include charting, offline storage, grid, and data store (described below), to name a few.
  5. Util contains a testing harness for Dojo and can be used to test the widgets that are provided with the toolkit.

Dojo has a rich set of features, but one that I want to call particular attention to is called dojox.data. Dojox.data provides a uniform access layer that abstracts away the concept of unique data formats. From a JavaScript perspective, all data is represented as an item (or as an attribute of an item), which provides a way to access data in a standard fashion. Out of the box, Dojo provides a rich set of data stores for well known services, such as Google, Flickr, and more. You can easily combine the data stores with your own UI widgets or directly integrate them into many widgets that are provided directly by Dojo.

More importantly, dojox.data store provides a means through which you, as the developer, can access server side services that you create. The dojox.data.JsonRestStore file provides a standards-based way to interact with JSON (JavaScript Object Notation) based services that use a RESTful style architecture. JsonRestStore provides read, write, and notification through HTTP/REST. Interactions use server-based GET, PUT, POST, and DELETE commands.

The line of code below illustrates how a dojox.data.JsonRestStore is created. The target specifies a URL for the resource and idAttribute is the ID name. Often the idAttribute will represent a primary key ID used to uniquely identify the resource on the server:

newStore = new dojox.data.JsonRestStore({target:"/MyTable/", idAttribute:"myId"});

The real power of dojox.data is the ability to combine it with a wide array of Dojo UI widgets. For example, the dojox.grid widget is a table display widget. Adding the example dojox.data.JsonRestStore is as simple as passing in the dojox.data store that you created (Listing 1).

Listing 1
gridLayout = [
       { name: 'Address', field: 'shipToAddress', editable: true},
       { name: 'Name', field: 'name'},
       { name: 'Id', field: 'myId'}];
var grid = new dojox.grid.DataGrid({
       store: newStore,
       structure: gridLayout
}, dojo.byId("gridElement"));
grid.startup();

The gridLayout array defines the column names and the field mappings. The dojox.data.JsonRestStore handles the parsing of the JSON data returned by the server, and the dojox.grid.DataGrid widget handles mapping the item contents to the row and columns in the grid. The dojox.data.JsonRestStore can also be used to return user-modified data back to the server through the POST and PUT operations.

On the server side

The Feature Pack for Web 2.0 provides a rich set of libraries and connectivity features that you can use within your server-based applications to assist in browser client development. It is not mandatory that you use these libraries with the Dojo Toolkit, but they will make development easier:

  • JSON4J

    I mentioned earlier that you can use dojox.data to interact with your own JSON-based services. The JSON4J library is an implementation of JSON handling classes for use within your Java application. The library can be used to derive your JSON data streams that are returned to the client, and provides:

    • A Java object model for constructing and manipulating data to be rendered as JSON.
    • A fast transform for XML-to-JSON conversion. JSON4J can be used to convert an XML reply from a service into a JSON structure for easy use in an Ajax application.
    • A JSON string and stream parser that can generate the corresponding JSONObject, which represents that JSON structure in Java.
  • Ajax proxy

    The feature pack provides a servlet-based forward proxy that can be used in the aggregation of content from different sites. Modern browsers use a same origin policy that only permits subsequent requests to be issued to the same domain where the page originated. The same origin policy can be a problem if your JavaScript application wants to contact services that you or others have written. For example, if your JavaScript application contacts another server, such as Yahoo for weather information, the browser will block the request since the information you are requesting (from Yahoo) is not the same domain location where your JavaScript application originated. The Ajax proxy can be configured to issue the request to the Yahoo service on the browser’s behalf. Since the Ajax proxy resides in the same domain as your JavaScript application, the JavaScript application passes the browser’s same origin policy test.

    To provide control, the proxy contains a white-listing configuration file that can be used to define the sites that the proxy can access. Additionally, the proxy can filter on HTTP headers, cookies, and mime-types to provide a level of control over the sites that a browser-based client can access.

  • Web-remoting for Java components

    A challenge in combining Ajax-based architectures and J2EE™ solutions is mapping a client-side runtime to J2EE constructs. For example, consider a JavaScript widget that displays information in a table that is dynamically created using JavaScript. The data needed for the table exists on the server and is accessible using EJB components. So, how do you access those EJB constructs?

    The feature pack provides a Remote Procedure Call Adapter (RPCAdapter), provided as a JAR library, that can be embedded into a server-side Web application. The RPCAdapter can be used to accept HTTP requests, such as POST and GET, and map the requests directly to user-created classes. One of the powerful aspects of the RPCAdapter is the ability to serialize EJB session and collection data to a JSON or XML stream that is returned to the browser client. The JSON and XML data can contain the information to be displayed by the widget.

  • Ajax messaging

    While Ajax messaging might sound somewhat innocuous, it is an innovative concept that lets you to create applications that update dynamically, based on changes that occur from the server. The Ajax messaging service uses a publish and subscribe pattern to connect the browser to the WebSphere Application Server Service Integration Bus (SIBus) for server-side event push to the browser. Client-server communication is achieved through the Bayeux protocol, which is JSON-based and used as the publish/subscribe mechanism for event delivery. On the server, you can consider the Ajax messaging service a Comet server implementation with the Dojo Toolkit providing client-side support.

    The Ajax messaging service bridges browser clients with the WebSphere SIBus, enabling a Web service or any other item connected to the bus to publish events to Web-based clients. You can use the Ajax messaging service in a new or existing application by placing a utility file library JAR in an application Web module, setting up a simple configuration file, and configuring servlet mapping.

  • Apache Abdera libraries

    Apache Abdera is an open source project that provides feed syndication support. Abdera addresses both the ATOM syndication format and the ATOM publishing protocol. You can use the Abdera libraries on the server to read syndication feeds from other sources or to generate your own ATOM feed content for use by your widgets. Dojo provides UI widgets to help in displaying ATOM-based information.


Conclusion

This look at the IBM WebSphere Application Server Feature Pack for Web 2.0 focused on some key functions that can help you create your own Ajax-style Web applications for WebSphere Application Server. Hopefully, this information will inspire you to explore the feature pack further, where you will find even more features you can use to unleash the potential in your Web applications.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Web development
ArticleID=398784
ArticleTitle=Comment lines by Kevin Haverlock: A closer look at the WebSphere Application Server Feature Pack for Web 2.0
publish-date=06242009