James Bayer's Blog

Lately I've been noticing a lot more references to REST implementations in industry publications.  Today I learned via InfoQ that Netflix recently announced their new REST-based API.  I'm not sure what language or framework they used for the implementation, but I think that REST interfaces will continue to increase and be a technology that is relevant to enterprise Java developers.

At BEA, some of the products such as WebLogic Portal 10.2 and already contained REST API's and other products already had increased developer-friendly REST support in the roadmap such as Oracle Service Bus (formly known as AquaLogic Service Bus).  There is no doubt that customer demand is calling for this in enterprise software.

With JSR 311: JAX-RS: The Java API for RESTful Web Services and the Jersey reference implementation java developers have an annotations based framework to productively implement REST-style services.  There are other java frameworks out there besides Jersey, but this one caught my attention because it's based on the JSR and a reference implementation.  In fact, I stumbled across Oracle developer Gerard Davison's blog that details how to get started with Jersey in WebLogic Server.  If you have an interest in REST for Java, be sure to look at these frameworks for a jumpstart.  In my humble opinion SOAP-based web services still have more enterprise Java mind-share, but I would look for that to balance out over time.

Here's the hello world code snippet from the Jersey Wiki:

package com.sun.ws.rest.samples.helloworld.resources;

import javax.ws.rs.GET;

import javax.ws.rs.Produces;

import javax.ws.rs.Path;

// The Java class will be hosted at the URI path "/helloworld"

@Path("/helloworld")

public class HelloWorldResource {

    // The Java method will process HTTP GET requests

    @GET

    // The Java method will produce content identified by the MIME Media

    // type "text/plain"

    @Produces("text/plain")

    public String getClichedMessage() {

        // Return some cliched textual content

        return "Hello World";

    }

}

I was excited to learn via the popular blog TechCrunch that FriendFeed announced a beta of "Real-time" updates for their html pages using long polling or server push.  This is showcased on a page highlighting the Presidential debate.  One of the quotes I like was from Robert Scoble who said “This is wild. It’s like the web has been turned into a chat room.”

Why is this relevant to WebLogic Server and enterprise customers?  Well, you can build sites like this using WebLogic completely with out of the box features that are also enterprise-ready.  WebLogic Server 10gR3 now includes an enterprise class HTTP Publish and Subscribe Server that implements the Bayeux protocol. This protocol provides the ability to apply the Ajax concept known as Comet. This means that simple web clients based only on html and javascript can be notified nearly instantly as events are observed by the server; no Applets, Flash, or Silverlight required.

The HTTP Publish and Subscribe Server takes advantage of the groundwork laid in previous releases with the Future Response Servlet and Abstract Asynchronous Servlet.  A stock tracking example ships with the server shows real-time updates to market data directly in the browser and on a chart.  Click the image to enlarge.  When you see this example in action, observe that the stock ticker properties and chart are truly "live" and are constantly changing with new market data updates.

Consider how often this comes up in web applications.  I'd be shocked if you've never found yourself repeatedly hitting refresh on your browser to
    - check the status of an online auction
    - try and buy tickets to popular concert at a ticket broker that had a waiting room
    - see whether your stock trade went through
    - see if you have new web mail
    - see if new articles have been posted on a busy news site

Just like the manual refresh situations described above, many web applications have handled stale data checks by automatically refreshing the entire page.  MyYahoo and DrudgeReport are both extremely popular sites still perform a periodic complete refresh.  Ajax has helped improve this situation to some degree by providing a mechanism to only update a page partially without a complete page refresh, which can be faster and more efficient to the client, network, and server resources than request all the page resources again.  However, the AJAX technique often involved periodic server polling techniques, asking the basic question over and over again, "Anything new yet?".  The quicker the page needs display new updates, the more often the client still needs to check for them.  It should remind you of the long road trip cliche "Are we there yet?". 

This can result in very inefficient behavior creating a lot of unnecessary network traffic and server load. Creative javascript and server-side developers started coming up with ways to push server events to clients using standard HTTP.   One of the members of the Dojo Toolkit javascript framework coined the term Comet, a play on the Ajax name, to describe the concept.  With the Bayeux protocol, they have found a way to mitigate some of the concerns polling to make it more efficient on the client and server.

In fact, many applications are now being built that take advantage of Comet techniques.  Take a chat application for example, Google Talk, YahooIM, and Meebo all have basic html and javascript clients that can participate in live chats.  In fact, previous versions of WebLogic Server included a chat example that applied this technique in a raw way.  See my previous post about it.

You can find the information about the stock example and run it with the samples domain.
<WEBLOGIC_INSTALLATION>\wlserver_10.3\samples\server\examples\src\examples\webapp\pubsub\stock

- Note, use IE or another non-FF browser as the sample application does work with latest version of Firefox, I tried FF 3.0.3. The reason is that the html client code uses an old version of the Dojo Toolkit (0.4) that no longer behaves nicely with FF3.  You can tell that this sample was actually built awhile ago in web time. Several new Dojo releases have come out since then, as of this post the latest is 1.1.1, but it's still useful for demonstrating the concept.

A sample application I created with Dojo 1.1.1 worked fine in both IE and Firefox.  I'll plan on writing about in a follow-up entry as there is enough to say to make this a series of posts.  Dojo and WebLogic together provide a very compelling solution, but there are other javascript frameworks out there like JQuery that are also providing client software for this and the WebLogic implementation is compatible with any Bayeux client.  More to come soon.

Overview

*10/21/2008 Update* I mention in this post that I had an issue with Dojo 1.2.0, well I figured it out, read Part 3 for details.

Last week I wrote about the introduction of a HTTP Publish-Subscribe Server in WebLogic Server 10gR3.  The new feature is based on the concept of Comet and implements the Bayeux protocol and is very useful for publishing events immediately to subscribed clients over HTTP.  There are many uses for a feature like this, essentially any time where stale information should be updated on a web page as soon as possible.  This entry will showcase a basic Hello World example application that will demonstrate the basic mechanics for using this feature.  Click the image to enlarge and get a better look at the application.

Pre-reqs

Dev Tools - I built this example with Oracle Enterprise Pack for Eclipse 1.0.0, the Eclipse 3.4 version, which you can download here.  If you just want to deploy the WAR file, then you can skip this.

Application Server - You will need WebLogic Server 10gR3.

Browser Debugging  - You must have Firebug for Firefox if you spend any time doing web development.  I insist.

Javascript Framework - It's also probably not a good idea for me to include Dojo Toolkit source with my example without getting approval, so grab a copy of that too.  I used version 1.1.1 because 1.2.0 was not out last week and more importantly when I tried 1.2.0 tonight, I got the error message below which leads me to believe there is a compatibility issue with 1.2.0 and the Bayeux implementation on WLS.  More to come when I figure this out.  I see that Dojo 1.2.0 version supports an additional connection type that WLS's pubsub server doesn't accept currently.  The bottom line is use Dojo 1.1.1 for now.

*10/21/2008 Update* I mention in this post that I had an issue with Dojo 1.2.0, well I figured it out, read Part 3 for details.

[{"channel": "/meta/handshake", "successful": false, "error": "402:long-polling-json-encoded:Invalid

 supportedConnectionTypes attribute.", "supportedConnectionTypes": ["long-polling","callback-polling"

], "version": "1.0", "minimumVersion": "0.1", "advice": {"reconnect": "none", "interval": 500, "multiple-clients"

: false}}]

Server-side

The example consists of server-side components that simply requires editing two deployment descriptor files in your web application's WEB-INF folder.  The typical steps section of the documentation are pretty clear.  In your weblogic.xml file, add a reference to the pubsub library, which will cause WLS to merge the files in the pubsub library with your application at runtime.  Here is the simplest that file could look:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <library-ref>
        <library-name>pubsub</library-name>
        <specification-version>1.0</specification-version>   
    </library-ref>        
</weblogic-web-app>

Secondly, you will need a weblogic-pubsub.xml file.  Below is the simple one for my sample application.  Notice the channel pattern definition, which is concept very similar to a Topic in JMS, except that there is also pattern matching.  There are also some configuration constraints for the channel pattern.

<?xml version="1.0" encoding="UTF-8"?>
<wlps:weblogic-pubsub
    xmlns:wlps="http://www.bea.com/ns/weblogic/weblogic-pubsub">
 
  <wlps:channel>
    <wlps:channel-pattern>/hello/**</wlps:channel-pattern>
    <!--since no handler defined, the default handler will be used -->
  </wlps:channel>  
  
  <wlps:channel-constraint>
    <wlps:channel-resource-collection>
      <wlps:channel-resource-name>subscribe</wlps:channel-resource-name>
      <wlps:description>subscribe channel constraint</wlps:description>
      <wlps:channel-pattern>/hello/*</wlps:channel-pattern>
      <wlps:channel-operation>subscribe</wlps:channel-operation>
      <wlps:channel-operation>create</wlps:channel-operation>
      <wlps:channel-operation>publish</wlps:channel-operation>
    </wlps:channel-resource-collection>
  <!-- Open this up for all users, if this section is enabled, web users will need to authenticate
    <wlps:auth-constraint>
      <!- allow only user with "subscriber" role to subscribe to above channels ->
      <wlps:role-name>subscriber</wlps:role-name>
    </wlps:auth-constraint>
   -->
  </wlps:channel-constraint>

Client-side

The simple.jsp that is included with my project showcases the most basic example of Dojo client API.  For additional functionality, look at the source of index.jsp.  Both of these files just as easily could be html files instead of jsp.

<html>
  <head>
    <!-- Import Dojo -->
    <script type="text/javascript" src="dojo-release-1.1.1/dojo/dojo.js"
        djConfig="parseOnLoad:true, isDebug:true"></script>

    <script type="text/javascript">

        dojo.require("dojox.cometd");

        dojox.cometd.init("cometd");

        dojox.cometd.subscribe('/hello/world', function(msg) { alert(msg.data.test); } );

      

    </script>

  </head>

  <body>

    <input type="button"

       onclick="dojox.cometd.publish('/hello/world', { test: 'hello world' } )"

       value="Click Me!">

  </body>

</html>

Run it

Below are the steps for OEPE/Eclipse, if you just would rather work with the war file, download CometWEB.war, add Dojo 1.1.1 as described in step 3, and deploy to the server.

1. Download my CometWEB project archive. 
2. Import the archive into OEPE as an existing project.
3. Put Dojo 1.1.1 in the web application so that the path to dojo looks like CometWEB\WebContent\dojo-release-1.1.1\dojo\dojo.js
4. Deploy to WLS 10.3, I used the samples domain <WEBLOGIC_INSTALLATION>\wlserver_10.3\samples\domains\wl_server
5. Go to your URL, on my configuraiton it is: http://localhost:7001/CometWEB/index.jsp

Try it in multiple browsers at the same time and publish messages to one another.  Use Firebug to see what is going on in the network traffic between the server and the client.  In future posts I plan on showing some of the protocol and discussing more advanced enterprise features like JMS integration and security.

Yesterday I published my sample Comet application for WLS 10.3 and described how to get it to work with Dojo 1.1.1.  I mentioned that I had an issue with Dojo's brand new 1.2.0 release.  Well I figured out the issue and the work-around to using Dojo 1.2.0 with WLS 10.3.  All that is required is to call the dojox.cometd.connectionTypes.unregister() function before you use dojox.cometd.init().

dojox.cometd.connectionTypes.unregister("long-polling-json-encoded");

Now that I ruined the punch-line, read-on if you're interested in how the Bayeux protocol handshake happens and how I trouble-shot this.  When the client initializes there is a handshake message exchanged with the server so they can agree on which method of communicating to use.  Apparently WLS 10.3 as it ships does not like a new supported connection type that is available in Dojo 1.2.0.

The client normally uses code like this to initialize a connection:

<!-- Import Dojo -->
<script type="text/javascript" src="dojo-release-1.2.0/dojo/dojo.js"
    djConfig="parseOnLoad:true, isDebug:true"></script>

<script type="text/javascript">

    dojo.require("dojox.cometd");

    dojox.cometd.init("cometd");

</script>

Using Firebug and a simple URL decoder we can see that it sends the following with a POST to the server:

message=[{"version":"1.0","minimumVersion":"0.9","channel":"/meta /handshake","id":"0","supportedConnectionTypes":["long-polling","long-polling-json-encoded ","callback-polling"]}]

The response looks like this:

[{"channel": "/meta/handshake", "successful": false, "error": "402:long-polling-json-encoded:Invalid
 supportedConnectionTypes attribute.", "supportedConnectionTypes": ["long-polling","callback-polling"
], "version": "1.0", "minimumVersion": "0.1", "advice": {"reconnect": "none", "interval": 500, "multiple-clients"
: false}}]

Uh oh, notice how there is an error in the handshake indicating that WLS does not like the long-polling-json-encoded connection type?  So after posting in the Dojox support forum, I got a response suggesting specifying a property as an argument to the init() call so as not to send the extra connection type.  That did not work for me, but it put me on the path of using Firebug, the js source, and the Dojo API docs.  I discovered that the connection types are stored in an dojo.AdapterRegistry and that there is an unregister function for the connection types.  That's it.  So now my client code looks like this with the new unregister invocation:

<!-- Import Dojo -->
<script type="text/javascript" src="dojo-release-1.2.0/dojo/dojo.js"
    djConfig="parseOnLoad:true, isDebug:true"></script>

<script type="text/javascript">

    dojo.require("dojox.cometd");

    dojox.cometd.connectionTypes.unregister("long-polling-json-encoded");

    dojox.cometd.init("cometd");

</script>

Which results in a POST like this:

message=[{"version":"1.0","minimumVersion":"0.9","channel":"/meta /handshake","id":"0","supportedConnectionTypes":["long-polling","callback-polling "]}]

And a successful response like this:

[{"channel": "/meta/handshake", "version": "1.0", "supportedConnectionTypes": ["long-polling","callback-polling"
], "clientId": "NNR2BOeRyCVKjLN", "successful": true, "minimumVersion": "0.1", "authSuccessful": true
, "advice": {"interval": 500, "multiple-clients": false}}]

Which causes the Dojo cometd framework to send another request specifying that it prefers long-polling:

[{"channel":"/meta/connect","clientId":"NNR2BOeRyCVKjLN","connectionType":"long-polling","id":"1"}]

And a confirmation response that long-polling should be initiated:

[{"channel": "/meta/connect", "successful": true, "clientId": "NNR2BOeRyCVKjLN", "error": "", "timestamp"
: "2008-10-22 01:59:27", "connectionId": "null", "advice": {"interval": 500, "multiple-clients": false
}}]

Which results in an immediate call to the server:

[{"channel":"/meta/connect","connectionType":"long-polling","clientId":"lMRDFU5fBxnE5kg","id":"3"}]

The response either times out on the server after about 80 seconds or returns if there is an event that the client has subscribed to sooner.  Then the process simply repeats.  Here is the response after a timeout.

[{"channel": "/meta/connect", "successful": true, "clientId": "lMRDFU5fBxnE5kg", "error": "", "timestamp"
: "2008-10-22 02:15:57", "connectionId": "null", "advice": {"reconnect": "retry", "interval": 500, "multiple-clients"
: false}}]

This causes the connect message to be sent again.  Firebug shows me the spinning request (see the last POST) indicating that it is waiting for the server response, and I know that it's working.  And the world is right again.  A helpful diagram showing how some of the various delivery methods work for this is on Carol McDonald's blog.