The Loop

Any one who has ever implemented a SOAP consuming client service will appreciate that the tooling for various languages is a very welcome feather in SOAP’s cap. Without the WSDL tooling that web service developers are accustomed to, a large portion of those developers would probably struggle to use the said service as the sher verbosity of the SOAP entity payload is simply overwhelming.

REST: A idealist view of the web or serious technology?

When REST came onto the scene it appeared to be met with two very different view points. The open source communities and web purists rejoiced… a resource orientated architecture which allowed them to scrap there verbose SOAP and XML-RPC service flow. However, from what I saw first-hand, the reaction from enterprise was somewhat different; namely, one of “So now we have to implement clients by hand? Sod that!”.

For a number of developers, including myself, we could see that REST was a much better architectural style for distributed computing on the web, but with ever decreasing budgets and squeezed time scales the added overhead of creating totally bespoke services – and therefore clients – was one that proved somewhat of a bitter pill to swallow.

WADL: Here to save the day?

Recently, WADL is coming to the fore as a structured way for providing description and automated development workflow for using REST services. WADL is based around similar principles to WSDL in that it provides a contract of service between service resource and the client.

If WADL can provide a robust framework for automated tooling with REST, I really think that we’ll see REST pick up a second wind of uptake in the enterprise setting. With players like Yahoo! leading by example, how long will it be before others follow suit?

Only time will tell…

As a number of you are aware, I have spent quite a bit of time wrestling with XMPie uProduce SOAP API with the CXF service framework in Java. I finally (and with quite a lot of disappointment on my part) gave up trying to get that to work. CXF just does not want to play nice and I cant seem to make the XJB bindings work correctly with it and the mish-mash WSDL coming from uProduce

Anyway… with that rant over, I tried to be objective and switched to using Metro – ok, out of the box I still had a whole heap of problems, exactly as I did with CXF. However, I have managed to wangle it!

Step 1

You will need access to an XMPie server with the API’s installed and working. For the sake of this example i just wget’d the WSDL file so the generation code was not so bloated.

Step 2

You’ll need an XSD XJB binding file which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" 
          xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
          version="2.0">

  <globalBindings>
    <xjc:simple />
  </globalBindings>

  <bindings scd="~xsd:complexType">
    <class name="ComplexTypeType"/>
  </bindings>

  <bindings scd="~xsd:simpleType">
    <class name="SimpleTypeType"/>
  </bindings>

  <bindings scd="~xsd:group">
    <class name="GroupType"/>
  </bindings>

  <bindings scd="~xsd:attributeGroup">
    <class name="AttributeGroupType"/>
  </bindings>

  <bindings scd="~xsd:element">
    <class name="ElementType"/>
  </bindings>

  <bindings scd="~xsd:attribute">
    <class name="attributeType"/>
  </bindings>
</bindings>

Save this as xsd.xjb (or whatever you like, just make sure the name is reflected in the command below)

Step 3

Actually generate the code! Your command might look different, but heres mine:

  wsimport -b http://www.w3.org/2001/XMLSchema.xsd \
    -b src/xjb/xsd.xjb \
    -keep \
    -s src/java \
    -d target \
    -p com.xmpie.wsapi.icp \
    src/wsdl/InteractiveCampaign_SSP.wsdl

You should then see something like the following in your finder (or other OS file browser if not on mac):

These are the class files created for the InteractiveCampaign WSDL – all 128 of them!

Anyway, I have run out of time for today, but will try and get another blog up soon about how to use this in a client application from a java CLI.

Right, as you know, I use the lift framework a lot these days. I also use Resin as my choice container. So, i recently got to thinking, wouldn’t it be cool if i could just bosh together a simple way to expose controllers in lift via the groovy protocols made available by Resin – well, I have here an example of just such a thing.

Lift Side

Ok, before anyone has a poke at this code… it was a very quick and dirty example, so its not ideal, and obviously your code would be a whole lot more complex, but this article is just about proving concept.

I set up the object that I want to expose via remoting. Critically, there would be nothing stopping me using the persistance built into lift, or anything else available to java or scala for that matter. The key is the traits… as they are like java interfaces (broadly speaking), they let resin know what methods it can call.

package com.timperrett.resin.example.controller

trait HelloTrait {
  def hello: String
}
class HelloWorld extends Object with HelloTrait {
  def hello = "Hello from lift" 
}

Resin Configuration

Next, we add a bit of config to resin so that it knows how/where to expose the service. Critically, we could have used Hessian, Burlap or CXF (for SOAP) and all by being pushed out of the container with zero extra effort.

<web-app id="/lift-remoting-example" 
   root-directory="webapps/lift-remoting-example">
  <servlet-mapping 
   url-pattern="/api/hello-world" 
   servlet-class="com.timperrett.resin.example.controller.HelloWorld">
    <protocol uri="hessian:"/>
  </servlet-mapping>
</web-app>

Client Side (in another language!)

To proove the point, I thought I would just make a simple client in another language (namely ruby):

require 'rubygems'
require 'hessian'

url = http://127.0.0.1:8080/lift-remoting-example/api/hello-world
client = Hessian::HessianClient.new(url)
puts client.hello

Again, a very simple example, but one that proves the point. You should then see “Hello from lift” output in the terminal window.

Project Files

You can download my example from here

If you found this article interesting, or have played with this yourself also, then by all means leave a comment or get in touch.

Web Services for API? Mehhh, haven’t we heard all this before?

Well, frankly, yes, you probably have. But you might not have had the full story. Im not talking about SOAP or other such protocols that require a serious amount of time at remoting-protacol-fat-camp… Today I would like to take some time to talk about the Burlap and Hessian protocols. For the astute readers, yes, those are the same ones that I was banging on about in a previous post when talking about hot technology for 2008. They are both slick remoting systems that run on Resin (they probably can be run on other JEE servers too, but frankly I haven’t tried), and according the chaps at Caucho:

“Hessian and Burlap are compact binary and XML protocols for applications needing performance without protocol complexity. Hessian is a small binary protocol. Burlap is a matching XML protocol. Providing a web service is as simple as creating a servlet.”

Sounds pretty cool doesn’t it? Well they are. I have been playing with Resin running these protocols and evaluating them as methods for creating robust API which 3rd parties can easily integrate with. Before reflecting on what I have experienced during these trials with Burlap/Hessian I would have instantly said that Hessian was better, but then I got to reflecting on use in the world: is it really practical to use binary remoting protocols for services that the 3rd party user does not know well? I think about the times in which I have been developing clients to services I don’t know (or didnt build for that matter) and I do usually end up looking at the message body when trying to troubleshoot any issues that might arise – and Hessian would be totally unworkable in that instance.

Anyway, to conclude, if you or a partner company are working in tandem and have a good working relationship then sure, its got to be Hessian all the way; its fast, its light weight… its all good. However if your exposing services for developers at a 3rd party, then you should really consider Burlap, as it could make someone else’s life so much easier. On the other hand, you could just be greedy and use Resin to expose Hessian, Burlap and SOAP!

Today was the day that Apache CXF graduated out of the incubator and will now become a full bonafied apache project. This is such brilliant news as it means that CXF should replace Apache Axis and Xfire as the defaco Java services framework.

Congratulations to Dan Kulp and the rest of the CXF team – all the sterling work has paid off after about 20+ months of rocking development.

I wish them all the best for the future – CXF will be a big hit!

If you are looking to lean CXF, then you should really read this:

http://www.jroller.com/gmazza/entry/using_strikeiron_s_super_data

It was one of the best written tutorials I managed to find and covers both Maven and Ant compilation.

Kudos Glen!