Archive for October, 2006

Planning for Reliability with HTTP

Monday, October 30th, 2006

MyArch has a good article about achieving reliable semantics with your web service:

…we still might be able to use SOAP/HTTP if we make our service consumers a little smarter. Specifically, service consumers must be able to meet the following requirements: Consumers must be able to retry a Web service call in case of a failure due to a connectivity error… Consumers must be able to uniquely identify the data that they are sending to providers… Consumers must be able to handle certain application-specific errors (SOAP faults)…

There is also a good table of what you need to think about for simple CRUD operations (which are what most web services are) to achieve reilability.

This reminds me of the HTTP vs SOAP/WS-* discussion we were having at JavaZone. James Strachan suggested that we can easily achieve our own reliability with HTTP by creating a unique URL which the client POSTs to until they get a response code. While its not that transparent, it isn’t a huge pain either.

CXF REST Support

Friday, October 27th, 2006

Since the cat is out of the bag, I figured I’d blog about the CXF (incubating) REST support a little as Apache Confluence seems to be down and I can’t write docs there…

One of the reasons I held off on REST support for XFire was that I wanted to do real support for REST style service. Not just this POST/GET crap that people claim as REST style. This means being able to map arbitrary URI/VERB combinations to services and their operations.

Lets say I want to build an HTTP service that shares and manipulates customer data. The first thing I might want to do is create a URI that returns a document of all the customers in my database. In CXF this would be done like so:

@Get @HttpResource(location="/customers") List getCustomers();

The @Get annotation maps the operation to the GET verb and the @HttpResource maps it to a URI. The List gets sent off the databinding implementation you’re using and will be serialized as a document. So far very simple!

Now lets say I want to pull down a specific customer, from /customers/ID:

@Get @HttpResource(location="/customers/{id}") Customer getCustomers(GetCustomer getCustomer);

The major new concept in this example is URI templates. The GetCustomer object has a single property named “id”. The URI parameters get mapped to the XML document according to its schema and the WSDL 2 rules. So CXF will actually synthesize an incoming XML document like this:

<customer><id>{id here}</id></customer>

Lets move on to a more complex example - a PUT operation which updates the customer:

@Put  @HttpResource(location="/customers/{id}") Customer updateCustomer(Customer customer);

Instead of synthesizing a document this time, we’re actually merging the URI parameters into the incoming document. This means {id} will get mapped to the /customer/id of the incoming customer document!

For a final example, lets look at adding a customer:

@Post @HttpResource(location="/customers") void addCustomer(Customer customer);

This will allow users to do a POST to the /customers URI with their document and add it to the collection of customers contained there.

And thats our REST support in a nutshell. A couple closing thoughts:

  • You can create services in a true REST style with CXF. We support POST, PUT, GET, and DELETE as well as mapping arbitrary URIs.
  • You can take existing services and make them REST easily by simply annotating them.
  • These annotations are located over at the Java Rest Annotations project at the Codehaus. The idea is that in addition to CXF using them, web frameworks or other projects may want to use them as well. So have it at if you’re interested!
  • REST is cool! :-)

You can find the CXF sources here (sorry no release quite yet…), an example service here, and example unit test here. And for those of you wondering whats coming next:

  • Support for HTTP headers. In my last POST example I think you’d really want to return the new ID of the customer so the user could then know to go to /customers/ID and find their new document there. This is fairly trivial to do.
  • Client support
  • A non annotation way of exposing services (probably an XML document)
  • Support for non XML data, like JPEGs (yes CXF can do that!)
  • WSDL 2 generation and code generation from WSDL 2

As always if you’d like to get involved, improve the HTTP binding, send your suggestions, etc, please pop on the mailing lists!

ApacheCon, CXF REST progress, CXF Architecture Guide…

Sunday, October 15th, 2006

ApacheCon this year was… busy. Lots of hacking, eating, drinking, and meetings. It was a good time though and it was great to see everyone again.

I gave my REST vs SOAP smackdown! talk on Friday. It is supposed to be a discussion about what the two are and when/where to apply the principles/technologies. REST vs SOAP is a bit of a non sequitir as one is an architecture and one is a technology. This definitely came up during the talk which was good. It was a pleasure to have Roy Fielding show up there as he had some particularly insightful comments. When we started talking about whether or not things need a description language, he said the web already has one - HTML. Forms for POST and a#href for GET. I don’t know that I buy this argument. These things do not fully describe things like content types or available parameters.

I did a lot of work at AC on CXF. I had a good time working on the Geronimo integration with David Jencks. I think we’re pretty close to getting the basics done. I am reminded though how stupid JEE is. The way you deploy a service is to create a servlet mapping where the is the web service class name. How stupid is that?

I also hacked a bit on the CXF HTTP REST implementation. I’ve got it pretty much working now. I have to say I was surprised how cool it was to take my JAX-WS service and be to test it in the web browser :-). You can use URI templates within annotations to map your services to URIs (i.e. @RestResource(location=”/customers/{id}”). I’ll have more details on this later this week once I check it in. We’re publishing SNAPSHOTs now so you’ll be able to try it out yourself.

We’re hard at work on CXF M1. We have a few things to do yet, but it the list is dwindling fast. I’m really excited about how good things are looking and I’m hopeful that we can start a vote on the release soon! One final note: if you want to get involved, we’ve been working on an architecture guide. It should give you the basics to start hacking and understand the overall workings.

Enterprise Community Model?

Sunday, October 8th, 2006

Henri Yandell: …the ASF is not a place for developing new projects. Nobody starts a project there, and few ever have.

This is something I’ve noticed as well. I think Apache should really be asking “why?” The above is just a small part of his thoughts on Apache. He ties it all together talking about Apache as the enterprise community model:

I think a lot of this adds up to one thing. The search for enterprise open source. Now, don’t make rash judgements about what I mean there - I really should be saying ‘enterprise open community’. It’s not software (peopleware, whateverware) for the enterprise, it’s about trying to apply the difference that exists between an enterprise company and a small company to open source projects. What do we get when we amalgramate in large numbers; what is the value. We get to lower costs - meaning time and money, in terms of shared hardware and shared expertise. We get to share brand, so that trust for one spreads to the others, though it also has a backlash of weakening the original trust a little. We get bigger boots - so if Apache can speak as one on an issue, they can speak louder. 

I would add that this implies that the Apache community style is not the right community style for every project - contrary to the many ASF bigots who like to put out Apache as the One True Way propoganda. We need other models as well. The dictator model is usually my favorite because projects that are developed by one or two people instead of group-think tend to be better. (And no I’m not talking about my own projects.)

On my way to ApacheCon

Sunday, October 8th, 2006

Its before god wakes up and I’m on my way to ApacheCon. In the spirit of other todo lists, here’s mine:

  • Meet up with fellow CXF developers to discuss and hack code. Hoping to get our milestone 1 out very soon. (more on this in another post)
  • Write documentation for CXF
  • Go to CXF BOF
  • Get the initial Geronimo/CXF integration done
  • Go to Axis2 BOF and laugh if they talk about XFire the whole time again.
  • Give my talk on REST vs SOAP (they don’t seem to have links to the individual talks so you’ll just have to search for “Diephouse”)
  • Explore Austin - I hear its awesome city.
  • Attempt to document how PPMCs work (and why they work the way they do) in the Apache incubator - if consensus can be gained :-)

If you want to meet up and we aren’t already planning on it - shoot me an email: dan AT netzooid dot com. See you all there!