netzooid

I’m sitting here at MuleCon in San Francisco today. Its pretty cool to see 200+ people here to learn about whats going on with Mule and to connect with many friends from accross the world.

One of the things that we’re launching today is a product I’ve been hacking on for the last couple months - the Mule RESTpack. What is it? Its really two components:

1. Documentation geared at helping Mule developers build RESTful architectures with Mule. (I still recommend that you go find the RESTful web services book!). This is still being expanded - if you see a missing topic, please let me know.

2. A series of connectors to help developers implement RESTful services. Included currently are connectors for Abdera, Jersey, and Restlet.

I think this is quite important offering for us. Many developers are struggling to figure out how to do RESTful integration. It is now significantly easier for people to do so via these connectors. It also says we’re committed to REST and helping people build RESTful services. I believe we’re the first ESB vendor to really do this.

We’ve pushed out the first set of milestones for Mule 2.0.0-RC3. Now that Mule 2.0.0 final is out (more on that later), we’ll be pushing out 1.0 releases of the connectors later this week.

Check it out and let us know your feedback!

Thanks to the great work of Dejan Bosanac, Jettison 1.0 final has been released! He popped on the mailing list the other day willing to fix things; before I knew it he had SVN access and was fixing everything he could get his hands on. This is looking a high quality release and should greatly reduce the number of problems people have with Jettison.

Thanks again Dejan, and enjoy the 1.0 release of Jettison everyone.

I feel the need to repost my latest posting from The Server Side here…

James Watson writes:

Personally I would like to see a good open source framework for REST based web services. I’m not sure if it’s the way to go but WSDL 2.0 spec should theoretically support REST. I’m unaware of any tools that help with creating these types of WSDLs.

Don’t use WSDL 2.0 for REST. It’s an ugly way of doing RESTful services IMNSHO. There are plenty of great toolkits out there for helping you build RESTful web services. The ones I have my eye on are:

• Restlets
• JAX-RS RI - aka Jersey allows you to build services easily with annotations. CXF has support in the works too.
• Apache Abdera - Build AtomPub services with Abdera. These are quite powerful…

Please keep in mind that REST and SOAP programming models don’t mix well. There is this complete fallacy going around (I succumbed to it too at one point) that you can use the same service class or description to build a RESTful and a SOAP based service. However, the interactions and mappings should end up being completely different from one to the other! One is message based and one is resource based. You’re going to have to design your service differently as they’re two completely different beasts.

Use the best tool for the job. You’ll save yourself time and a lot of hassle.

What does one do after going to QCon and Oredev? ApacheCon of course. I barely made it on my plane out of Sweden. I arrived at the airport checkin thinking the arrival time of the flight was the departure time. Oops.

Here’s my presentation that I did on building RESTful HTTP services. Really its just a bunch of practical stuff that you should know when you get in bed with HTTP.

I was jazzed before the talk as I had somehow managed to teach Sam Ruby something about HTTP that he didn’t know. Expect: 100-continue. You can use the Expect header to ensure that the server will be willing to process the request. Sam brought up an example where you might be uploading a large image from a cellphone and you need to be authenticated to do so. You certainly don’t want upload the image and then get an unauthorized response! The solution to this is to have a client send an Expect: 100-continue header. After the client sends the headers it waits for the server to respond with either a “100 Continue” message or some other status like “401 Unauthorized”. Provided that the client gets a 100, it can continue sending the message. If it gets some other message, the connection is immediately closed and then the client can decide what to do next - like authenticate itself.

I said something along these lines at QCon last week and got some strange looks. I’m happy to see that Don Box is saying its quite important as well. People may takes digs at the complexity of the WS-* specs, but security is damn complex and the WS-SX specs are pretty quite good. If you start looking for equivalent functionality in the Just Use HTTP world you won’t find any.

Sam Ruby has chimed in as well, but I’m not sure what his point is - its a little too terse for me. Maybe he’s hinting that some could write a more RESTful binding. Or that its not in their interest to use WS-SX because its too complex.

Maybe the question we need to ask is how do we do WS-SX related stuff over Just HTTP? Mark Pilgrim did a little work on WSSE, but I don’t think thats sufficient. I’m not sure all the WS-Security token stuff can be mapped to HTTP headers. I’m also not sure its worthwhile trying to make WS-Trust into a more RESTful service other than aesthetics. I don’t see any potential for GET operations in those specs which is where HTTP adds a lot of value.

Which means we might just want to keep WS-Trust around. Kind of like how Infocard already does. Which brings us back to: how do we use WS-Security tokens - username/passwords, saml tokens, tokens from WS-Trust, etc - with HTTP resources? Someone is going to have to sit down and figure this all out.

(Hopefully this makes sense - I am not a WS-Trust expert. But I take comfort in the fact that maybe only 3 or my readers even know what it does. If thats you: I threaten to ban your comments if you expose me! :-))

James Snell:  Wrong. All of this is complex. Technology is complex. It does nobody any good to argue that one particular way of building applications is less complicated than any other way of building applications. WS-* is complex. REST is complex. It’s all complex. Complexity is not the issue. The real issues are things like utility, consistency, accessibility, etc.

Not much I can add to that.

Bill (where is that Ó key) de hÓra: “The fundamental problem here is looking for a RESTful way to do RPC/RMI, instead of redesigning the application to expose resources.”

This gets at one of my main problems with getting people to build good RESTful services: it’s a lot of work.

While OO in theory can map pretty well to REST, it takes a lot of metadata and careful thought to turn those objects into resources. Making an RPC application is much easier. This is one of the killer features of SOAP/WSDL. I can take my business service and build a web service out of it with very little effort (I assert that there are non-evil ways to do this, but thats another story). I can then be interoperating with a .NET application in just a minute or two. Or I can take a WSDL, generate a set of objects, and just write some glue code between my internal objects and the web service objects.

Building the RESTful equivalent isn’t nearly as easy IMO. (At least for Java).

I suppose there are two ways to build RESTful services. First, you can turn your interfaces/POJOs into a RESTful service. This requires you to know:

• The relationships between the objects. I.e. parent/child relationships and primary keys. This would allows basic URIs like /customers/1 or /customers/1/orders.
• How to map methods on your business interface to resources.

Given a business interface and a set of POJOs, this isn’t quite so easy. Sure, people are working on JSR 311, annotations, etc. But I would like to assert that it will still be harder than building the equivalent RESTful service. At the very least you need to add a bunch more annotations as well as design your URI structure. (JPA annotations may give us some help here in the future - @Id, @OneToMany, etc would give some of the necessary metadata - but not everyone has these annotations on their application. It also seems a little icky to retarget these for RESTful services.).

The other option would be to design your application in a RESTful manner to begin with. I’ll be honest, I don’t have a lot of experience with doing it from the start. Most applications that I encounter have some OO/DAO backend which is exposed through various frontends.

Am I wrong about all this? Should building a RESTful service be easy/easier? (Just for the record - even if it is more work, that doesn’t mean I don’t think there aren’t other more important benefits like scalability)

It’s official, I’m joining up with MuleSource!

In the spirit of self-interviews…

Why?

Mule is an open source ESB. Its a great product. Its got a huge community behind it. Its robust. Its got a great feature set. Its got an excellent team developing it. I’ve run into my fair share of installations while consulting. I mean, really how can you not with an install base like this? Its the OSS ESB leader.

What will you be doing?

I’ll be bringing Mule and web services more closely together in a variety of senses. Stay tuned for more info.

And of course I’ll still be blogging here and talking at conferences about web services and the like.

Will you be working on CXF still?

I’m not dying or falling off the face of the earth, so I’ll still be active in the CXF community.

etc.

If I wasn’t able to tell you personally, I apologize, its been a busy time for me.

Personal email is now officially dan AT netzooid.com and MuleSource email is dan.diephouse AT mulesource.com.

Wish me luck as I move forward!

Fake Steve

Ahhh crap - Fake Steve has been revealed and he works for Forbes. I was hoping the revealing would be more dramatic than this. Maybe involving lawsuits. Will it keep its charm? Or will it turn into a Forbes marketing ploy? Whatever the outcome, Jaysus, we need more posts with Bono!

Dopplr

I started using to Dopplr to track all my trips and my friend’s trips. The interface kinda sucks, but my life is still better off with it than without it. My #1 feature wish is for the ability to give trips names. I.e. get Septemeber 13 & 14 to be called “JavaZone” instead of “Oslo, Norway” in my calendar.

I have several invites if people want to join up. I recommend it especially if you travel a lot and like to see who will be where you’re travelling. If you’re already on there, add me as a fellow traveller!

Conference Season

Speaking of travelling, there are too many conferences coming up: JavaZone, QCon, Oredev, ApacheCon US, OS Summit Asia, and possibly others…

CXF 2.0.1

We’re voting on it right now. Well technically the Apache Incubator PMC members are voting on it. Hopefully it will pass in a day or two. If all goes well we’ll have a follow up release with bug fixes and new features in under 5 weeks! Pretty good, eh?

Its also our one year anniversary - check out Dan Kulp’s retrospective for a good recap!

Well, its been about one year since we began and today we’ve finally reached our 2.0 release! From the announcement:

The Apache Incubator CXF team is proud to announce the availability of the 2.0 release!

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These
services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.

CXF includes a broad feature set, but it is primarily focused on the following areas:

• Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security.
• Frontends: CXF supports a variety of “frontend” programming models. CXF provides a JAX-WS Compliant frontend. It also includes a “simple frontend” which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.
• Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more.
• Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.

For those who aren’t up on things, CXF is the merge of the XFire and Celtix projects. As such, CXF is really a continuation of the XFire project and can be thought of as XFire 2.0. For all the XFire users out there: have no fear, your services should deploy just fine in CXF. You’ll just need to change your deployment code/xml. Check out our migration guide if you’re interested in more details.

For more information on CXF check out:

• User’s Guide
• Downloads
• Mailing Lists

Many thanks to all those involved in the whole process. Its been a pleasure to work with so many talented people. Thanks to Debbie Moynihan for helping the whole CXF project get rolling and getting IONA involved. Dan Kulp for continually making CXF more coherent, his incredible eye for detail, TCK work, build maintenance and patience with my build breakage. Andrea Smyth for the great Policy/ReliableMessaging work. Jervis Liu for his work on everything, like the SAAJ stuff which was a giant PITA. Eoghan Glynn for putting up with me and the superb WS-A layer. James Mao for making CXF tooling rock. Christopher Moesel for his MTOM integration. Willem Jiang for fixing things all over and the JCA work. Guillaume Nodet for using XFire, showing me how many things were wrong with it when using it with JBI and then helping develop the CXF JBI code. Freeman Fang for the JBI work. Jeff Genender and Jarek Gawor for their awesome work on the TCK and Geronimo. Jim Ma for the work on the tooling and frontends. Thanks to all the incubator folks for reviewing our releases. Our mentors who guided us in the Apache process, especially Jim Jagielski. (*whew* - I probably missed some people, apologies!)

A special thanks to Tomek Sztelak who has been helping maintain the XFire code more than I have lately and answering a ton of questions on the XFire list. Not only that, but he’s also found time to contribute a set of Maven archetypes to CXF. All this while he’s been working full time AND been in and out of the hospital! Heroic!

The CXF community welcomes involvement and feedback. For more information see how to get involved or the mailing lists.