netzooid

I’ll be speaking at QCon next week on bringing the enterprise to the web with Mule. Mule has a lot of cool stuff which can help you integrate applications RESTfully. I’ll be looking at some example scenarios and how these problems can be solved using Mule.

Have use cases or scenarios which you’d think would be interesting to discuss? Shoot me an email (dan AT netzooid.com) or leave a comment below!

1. Make it faster. Anyone else notice how slow the apps are to start? It takes like 15-20 seconds for me to get to the point where I can take a picture. This is the case with nearly every application - I spend the majority of my time in front of the iPhone waiting.
2. Build a model with a slide out keyboard.
3. Stop being monopolistic, two faced jerks and allow any application on the iPhone. I want Rhapsody on the iPhone! Subscription music rocks.
4. Create a home screen which shows my upcoming appointments, recent calls, and favorite apps. Kind of like WinMo…
5. Flash for the iPhone. Too many restaurant websites depend on Flash, making the iPhone unusable for a lot of menu browsing.
6. Create a better SMS applicaiton. There is no sorting, filtering, and it takes a lot of scrolling to call a contact. There is also no easy way to go from a contact to the SMS chat history. Annoying.
7. Allow me to turn off spelling correction.
8. Copy & Paste anyone?

Stefan Tilkov just posted his slides from his Lightweight SOA talk. I have nothing to add to them. I just wanted to say: these should be mandatory reading for all our customers and anyone doing integration!

We managed to get Galaxy 1.5 posted yesterday. Between the RC and this release we managed to fix a few bugs that users reported. We also now have the Galaxy enterprise edition out. EE includes a couple cool new features:

• Support for attaching workspaces from remote Galaxy instances
• The ability to replicate between various Galaxy instances
• Better JMX support for NetBoot

Check out whats new in 1.5, give it a download, and let us know what you think!

I’ve been doing some POM editing to build distributions for the Mule RESTpack today. Normally this type of thing would’ve been a painful iteration back and forth between the command line and inspecting the assembly I built. But m2eclipse provides a great way to actually visualize your dependencies.

Screenshots say it all, so here’s a view of all my dependencies:

And here’s a view of me tracking down a specific dependency I want to remove:

I’ve been trying out Ubuntu as I need to use Linux for some work related things. Here are my impressions so far.

Things Which Rock

• Having a real Unix Shell
• Its a bit faster than Windows for things like SVN
• Install was quick
• Wifi works better than Windows I think!

Things Which Suck

• Fonts suck big time on Linux still. Even will all the tweaks (Installing MS fonts, turning on autohinting, etc), they still just don’t compare to Mac OS X and Windows. I have a hard time looking at them all day.
• Dual monitors seem to require a lot of extra set up
• Docking/undocking my T60 doesn’t really work
• Skype on Linux isn’t as good as Skype on Windows
• Bugs: X & Java, Rhapsody in the browser
• No desktop Rhapsody client
• Verizon card doesn’t work out of the box
• UI is extremely inconsistent in Gnome
• Webex doesn’t seem to work out of the box (I installed the Java browser plugin, but still no go - it just froze up)
• OpenOffice…

Let me know if I’m wrong on any of these accounts or did something ridiculously stupid.

Verdict: still not ready for prime time.

I recently submitted a piece for CIO.com where I ranted about UDDI for a bit. Be sure to see the Microsoft counterpoint which is… interesting to say the least. More on that later. While comments are always welcome here, be sure to leave comments on the CIO.com piece as well!

Without further ado:

The registry landscape needs to change. The unholy trinity of SOAP, WSDL and UDDI needs to go. While registry vendors, such as Systinet, have pioneered a number of good ideas in the field, they have failed to meet the needs of enterprise integration projects today, because they are based on these technologies. One should be able to guess this just by seeing the limited adoption, low success rate and high price tags of these solutions. Mass adoption is just not in the cards.

If we’re to understand why this approach for registries has failed, we need to look to the bottom of the stack: SOAP/WSDL-based services. Over the last decade we’ve learned that they’re tightly coupled—making distributed, anarchic change highly difficult.

Yes, your enterprise is a bit anarchic. Business needs change rapidly. To keep up with these changes, IT scales and evolves rapidly. To do this, enterprises have been adopting a RESTful approach to building highly scalable services. RESTful architectural principles are the ones behind HTTP, and allowed the Web to scale and evolve at such a rapid pace.

Even if SOAP/WSDL was the right answer, we will never be able to adopt a single type of service. All technologies have tradeoffs associated with them, and we should never assume a homogenous enterprise environment (not to mention the massive cost of switching everything over). Because UDDI has been designed around the concepts of SOAP/WSDL, it has failed to evolve and address this problem.

There are yet more problems with UDDI, though. A lot of effort has been spent on seldom-required use cases. For instance, it’s often recommended that people use it at runtime to dynamically look up services. In reality, this is often dangerous, and hardly ever done. You can easily end up with a service you don’t want, whether it’s because the functionality is slightly different, the service is slower, or it lacks redundant backups.

On top of this, UDDI is also quite hard to use. It seems people were so confused, the technical committee had to write another long document explaining how it could be used as a registry with SOAP/WSDL services. Then Systinet had to write another long document called the Governance Interoperability Framework to make it actually possible for inter-vendor communication using UDDI.

Where does this leave us? We need to leave this whole stack behind. Registries need to be more agile, easier to use, and focus on things that matter for SOA projects today. We’ve been pioneering a new approach with Mule Galaxy. It uses a simple, extensible services model which enables you to reap the benefits of registries—service visibility, contract management, policy management, etc.—while remaining in a heterogeneous environment.

It also uses a new type of registry API based on the Atom Publishing Protocol (AtomPub). This API, which is built on Atom (the successor to RSS), enables integration using a simple, RESTful mechanism. This RESTful approach, combined with our flexible services model, reflects the way that enterprises actually do business, not some vendor-imposed theory.”

I was giving a demo to a company today. The following sequence of events happened:

• Webex froze my computer, not once, not twice, but three times - requiring full reboots. (It seems it doesn’t work well with dual monitors)
• Construction knocked out my cable - which I use for phone and Internet
• I called back in on my cell phone and my call dropped

Sometimes it is just not your day.

Folks, we managed to push out a Galaxy 1.5 release candidate yesterday. It has some pretty cool new features I think:

• Much expanded metadata capabilities. You can define new properties which are stored of various types - like links to other things in the registries, lifecycles, users, and simple values. For instance, you can define a property called “supercedes” which is a link type. Than users can link to another entry in the registry that a particular service/artifact supercedes.
• The ability to work with a much larger variety of services. Galaxy 1.0 only stored artifacts. Galaxy 1.5 allows you to just store metadata about services in the form of registry “entries.” For instance, you can define an entry for a RESTful service then start attaching metadata such as the service owner, URL, links to documentation, lifecycle information, etc.
• Event API - easily develop extensions which listener for lifecycle transitions or new entries/artifacts
• Scripting shell - great for scripting things such as notificactions or replication

And there’s a lot more as well…you can find out the rest of the details in the What’s new in Galaxy 1.5 document.

We’ll be releasing the 1.5 final version (along with the 1.5 enterprise version) in a couple weeks once we’re able to put it through some more QA/testing and once we get all the documentation updated for 1.5.

As always, we’re eager to here feedback so kick the tires and please let us know what you think.

Yesterday, I touched down in Oslo to attend the JavaZone conference (can you believe Sun still lets them use that name?). This is always a great conference as the Norwegians are always doing cool stuff with Java.

This morning I attended Jim Webber’s talk on Guerilla SOA. He was hilarious as always. He (correctly) derided the idea of a giant “Bus” which sits on your network which does intelligent routing for every application then talked about how a more webby approach can solve a lot of the problems. Unfortunately, I there was no mention of enterprise man boobs (a.k.a. “moobs”) in this talk.

I also tried to attend Arjen’s talk on RESTful services in Spring, but it was full and they wouldn’t let me in.

I’ll be giving a talk tomorrow entitled “SOA Governance - 5 common mistakes and how to avoid them.” Hope you can make it if you’re here.