netzooid

I just finished up two conferences here in Europe.

TSSJS Europ

At TSSJS Europe, I did a “fireside chat” on effective RESTful services. Since one can never count on Europeans being loud and obnoxioius like Americans while discussing things, I put together some slides on Dos and Don’ts of RESTful services. I enjoyed myself and felt there was some good discussion. I hope others did too.

Jazoon

I have to say I was quite impressed with Jazoon. Maybe it is because the speakers were a completely different circle than those I normally see at other conferences – but I feel like I actually learned a lot.

I also gave a talk called The Rise of AtomPub in the Enterprise. I redid my previous talk on AtomPub and I think this flows much better. I gave a short context of the history and how we ended up with AtomPub in the enterprise. Basically I see 3 forces – the move to enterprise services but SOAP/WSDL failing for many cases, the rise of REST, and move toward syndicated content. If you were there, let me know what you thought of the talk.

Scala

Can we just ditch Java and move to it already? From a Java developer’s point of view, its much less abrasive than Erlang, but still seems to have a lot of the power. On a related note, InfoQ had a good recap on the two languages.

JCR/Sling

It took me a while to come around to the JCR way of thinking, but now that I’m getting there, I’m liking JCR more and more all the time. A big thanks to David Nuescheler (spec lead for JCR, CTO for Day software) for patiently answering all my questions last week.

The Sling demo that they did to rebuild The Server Side in 15 minutes was quite impressive. I liked the way it effectively meshed web principles with JCR. They just did a 1.0 release, you should seriously check it out if you’re building a content driven website.

Dan Kulp:

Kulp Technologies is proud to announce the immediate availability of Kulp Micro Edition 2.0. This release builds on the success of the previous version to provide enhancements to the popular features:

• Ability to produce a wide variety of stinky, smelly fluids and excrement.
• A high pitched wail, expected to occur for about 4-5 hours a day, every day.
• Guaranteed to distrupt any thoughts of sleep for anyone around for the first couple months.
• Inate ability to require the use of all spare resources for the next 18 years. If you’re lucky, it will then require even MORE resources for another 4 years

Congrats Dan! The current XKCD comment is funny/relavent as well:

This is a little late, but it seems that MuleSource has been declared a Cool Vendor in SOA Governance by Gartner for our Galaxy product.

Eat that all you people in middle school who told me I’d never be cool.

In related news – while they don’t call me cool, Search SOA has a two part interview with me on Galaxy/REST/UDDI and other subjects.

Seems there has been some more work on Atom over XMPP recently:

There’s been plenty of talk recently about using XMPP to build a decentralized microblogging platform (think Twitter busted apart to run as a distributed network of microblogging providers). Indeed, as Bob Wyman points out, we have all the pieces:

• The core XMPP infrastructure, comprised of 100,000+ messaging and presence servers plus millions of end users.
• The XMPP publish-subscribe extension, specifically the personal eventing profile thereof, which enables your IM account to function as a virtual pubsub service and thus push out all sorts of notifications about you.
• The Atom syndication format along with the Atom threading extension, which (being XML) is easily transported over XMPP.

Now it’s just a matter of putting the pieces together, so Joe Hildebrand and I have done just that in a little spec we call Microblogging Over XMPP. Feedback is welcome!

This builds on the Atomsub spec that Peter Sainte-Andrew (and others?) have been working on. Cool stuff.

Note to self: create a UDDI replication replacement based on Atom and XMPP.

Its hard to believe that its been 20-some months since we originally started merging XFire and Celtix.

In this space of time the project has:

• Released a number of milestones
• Released five highly stable 2.0.x releases
• Implemented many different WS standards
• Provided an easy migration path for XFire users (with some minor exceptions – most notably JiBX users still need to be catered to)
• Passed the JAX-WS 2.0 TCK
• Embarked on JAX-WS 2.1 and I believe there will be a 2.1 CXF release very soon which implements this.

How time flies – I can’t believe its been 4 some years since XFire was started in my spare time. I think this was my first commit of the StAX incarnation, but it started a few months before that.

Alright, enough gratuitous self-reflection. Thanks to all of those in the project who helped us get this far and looking forward to seing where we can go in the future!

Sweet: I just made a call on my iPhone over my laptop’s adhoc wifi connection and in turn over my 3G Verizon connection.

Update: bonus, it works with my Vonage account as well. No more calling through the laptop unless I want to when travelling internationally.

Jonathan Schwartz:

The CIO responded categorically with “we don’t run MySQL, we run [name withheld to protect the proprietary].” The CISO said, “We can’t just let developers download software off the net, you know, we’ve got regulation and security to worry about.” The CTO smiled. Everyone else appeared to be sitting on their hands. I was going to leave it at that. Thanks for the business.

Until a (diplomatically) assertive Sun sales rep piped up, “Um… no, I connected with a buddy of mine over at MySQL, and had him check – you’ve downloaded MySQL more than 1,300 times in the last twelve months.”

One of the great open source business questions seems to be – how do you turn these downloads which nobody but the developers know about and convert them into sales?

P.S. Does anyone think of this clip ever when hearing Jonathan’s name?

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

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.

I agree that stuffing a URI in an HTTP Content-Type header isn’t the best way to discover more metadata about a mime-type. And maybe decentralized mime types are a bad idea.

But, there are still times where you may encounter unknown elements and want to find a schema. I thought I’d describe a quick example of how you could use Galaxy to do this.

Searching for schemas by XML element name

1. Download Galaxy (this is a snapshot, but it’ll be released soon enough)

2. Run galaxy:

$ java -jar  galaxy-web-standalone-1.0-beta-2-SNAPSHOT.jar

3. Post your schema to Galaxy:

$ curl -v -d myschema.xsd -u admin:admin –header “Slug: myschema.xsd” –header “X-Artifact-Version: 1.0″ http://localhost:8080api/registry/Default%20Workspace

This adds your schema to the workspace “Default Workspace”. (Workspaces are just folders.)

4. Query Galaxy for a schema whenever you discover an XML element you don’t know [1]

$ curl -v -u admin:admin http://localhost:8080/api/registry?q=select%20artifact%20where%20xmlschema.targetNamespace%20=%20′http://www.example.org/test/’%20and%20xmlschema.element%20=%20′testElement’

5. Parse the result for /feed/entry/content/@src for links to any schemas which describe that XML element.

Searching by media type

Let’s pretend that you didn’t actually have to have your media type approved by IANA or just didn’t care. We can also lookup schemas by media types. We’ll intercept the above process at step #4.

4 (version 1). Log in to the web interface for Galaxy. Select the schema. Add a new property to the metadata where the id is “mediaType”, the description is “Media Type” and the value is “application/vnd.myContentType+xml”.

4 (version 2). Modify the metadata via Atom:

a) Get the atom representation of the schema:

$ curl -v -u admin:admin http://localhost:8080/api/registry/Default%20Workspace/myschema.xsd\;atom > entry.atom

b) Edit the entry.atom file and add the following to the entry/metadata element:

<property name="mediaType" value="application/vnd.myContentType+xml" />

c) PUT the new atom representation of the schema:

$ curl -v -u admin:admin -T entry.atom http://localhost:8080/api/registry/Default%20Workspace/myschema.xsd\;atom

5. Search for schemas associated with your media type:

$ curl -v -u admin;admin http://localhost:8080/api/registry?q=select%20artifact%20where%20mediaType%20=%20′application/vnd.myContentType%2Bxml’

6. Parse the result for /feed/entry/content/@src for links to any schemas which describe that media type

Conclusions

Pros: Easy to find and manage schemas.

Cons: Its not universal. You need to know about Galaxy. Decentralized media types are evidently bad (see Mark’s post).

Endnotes

1. Hooray for URL encoding. In case you’re wondering, the q query parameter is really:

select artifact where xmlschema.targetNamespace = ‘http://www.example.org/test/’ and xmlschema.element = ‘test’

More friendly URLs are on the way…