gettin all zoidal on ya
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:
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
Things Which Suck
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.”