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!

While I love the concept of OpenID, I refuse to use it as it requires me to enter a URL for my login. This is the most inane thing to do from a human interface point of view.

As I was daydreaming about software last week, and in particular how to get around this, I started wondering “what if a Jabber extension was created for OpenID?”

Think about this:

• User enters email into web site to log in
• System sends jabber message to user (where their email is their jabber id) asking if they want allow the login.
• User responds yes/no.
• System grants/denies access based on the response.

Now consider the modified version.  The user opens their web browser. They tell the web browser to log into the jabber server and listen for messages on a specific jabber resource. Now all the user needs to do is enter there email for any OpenID site. (Maybe there is a way to get around the email entry too?)

One could also imagine a scenario which used SMS or other IM protocols. URLs definitely do not have to be the only identifier available to OpenID users.

There’s probably a whole host of issues with this, and I’m much too lazy right now to go research if its feasible via an OID extension, but I thought I’d throw it out there.

This week I put the finishing touches on the first version of a Jersey connector for Mule. It makes it really easy to drop in JAX-RS services into a Mule application.

For the non-Mule users out there – you’re probably asking, why would I need Mule and JAX-RS?

Imagine this scenario: you receive messages over HTTP. You wish to process these messages asynchronously with your backend servers. With Mule its pretty easy to set up an HTTP listener and connect it to a JMS queue. You can then have pull messages off the queue and process them asynchronously within a transaction. JAX-RS makes it very easy to map your Java class to resources with it’s simple annotations.

While you could piece this together all yourself, Mule is like integration glue – it makes connecting all these things easier. </marketing>

I finished up the first draft of a guide on how to develop your first AtomPub service with Abdera. This shows the much simplified server code base in action, so beware – this requires the latest trunk/ code. 0.4.0 should be out soon though.

There is definitely more one way to skin a cat and develop services with Abdera. But, I’m kind of fond of the above method if you’re integrating with some existing application and are not looking for just a generic Atom store.

Feedback/comments welcome.