netzooid

After quite a wait, Mule 2.0 final is out. Its a pretty big step for us, our users, and our customers. Check out the Whats New page for a rundown of everything. Its a significantly improved release - its much cleaner and easier to use.

Since its Friday and I can’t stare at my IDE any longer, I want to give a quick rundown of the transformation engine which was the primary thing I worked on.

Having implemented two web services frameworks (two more than anyone should ever write), I was getting quite familiar with some of the problems around dealing with XML efficiently. We have many many different representations: DOM, SAX, StAX, bytes[], streams. Applications may work with a variety of these formats as inputs/outputs. Finding the most appropriate match is a difficult one.

A good example of this is where you have one component which can output SAX, DOM, and StAX and another which receives only DOM. When the first component is sending a message, how does it know what to send?

The key was to implement an on demand payload request mechanism. The API is actually similar to what I did with CXF (surprise), but it goes one step further and hooks in the Mule transformation engine. Here’s an example of what the second component would look like.

MuleMessage inputMsg = ...;
Document doc = (Document) inputMsg.getPayload(Document.class);

Quite simple - we’re simply requesting the payload as a Document type. Mule allows you to actually delay any decisions about how to serialize it until getPayload is called. Or you can go down the more traditional route of just choosing some format to send and then have a transformation. i.e. send a SAX stream and convert it to a Document on demand.

As an added benefit, transformations are now automatic - no more manually specifying transformers unless you want to. Mule will use its internal registry of transformers to determine how to best match two components together.

And this concludes our adventure in the world of messaging! If you read this blog entry, you’re probably either sick or are a competitor

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.

Ross finally got a blog. Ross: You’re only a few years late, but glad to see it!

If you’re a Mule user, we’re putting together MuleCon 2008 right now. Come and discuss all things Mule, best practices, Mule product roadmaps, etc. I’ll be giving two talks, one on approaches to RESTful integration and another which will be an introduction to Galaxy & Governance.

If you mention this blog you’ll get an extra $50 discount. Just email mulecon2008@mulesource.com or call +1-415-229-2065!

I’m happy to announce the availability of the Galaxy 1.0-beta-2 release. Galaxy is our open source governance platform which is just a fancy of way of saying, its an open source registry/repository. There are some cool new features in this release….

Mule NetBoot

You can now boot a Mule instance directly from the repository. You simply upload a Mule distribution to the repository and then use Mule NetBoot to boot this instance over the network. This can greatly simplify deployments.

Maven Publish Plugin

The Maven Publish Plugin allows you to easily push resources and artifacts from your build to the repository as part of the release cycle. You can publish individual resources, your project’s jar, and/or your project’s dependencies. This works great with Mule NetBoot…

XML Schema Support

We now index XML schemas. Which allows you to do things like this.

Improved AtomPub API

The number of things you can do with the AtomPub API has been greatly expanded. It features a much improved URI space which allows you to do a number of things you couldn’t do before:

• List individual workspaces easily (No more GQL needed)
• List child workspaces
• Add/delete workspaces
• Edit artifact metadata
• Edit artifact lifecycle information

Feedback

Your comments, suggestions, criticisms, etc are all very welcome. Please sign up for the mailing list and let us know what you think!

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.

Tomorrow I move to San Francisco for a few months. I’m testing the waters to see if maybe I want to live out there. And my company is based out there, so it’ll be good to work in person with people more often.

If you’re based in SF and/or traveling through it, give me a ring! I’ll be ringing up those of you who I remember live around there, but I’m not sure I can remember everybody’s location.

Also, you can always find me on dopplr to track where I am.