Johnny CORBA

Well, they finally did it. Posted it on YouTube, that is.
One note to non-Boston residents: the “come on down” is a famous catchphrase of a long time local auto dealer.
Update 4/27: I guess I should explain a bit of the background here. IONA’s annual sales kickoff features a presentation by Steve Vinoski, and for historical reasons it’s ended up being a blend of technology and humor. This video was what Steve used to close his presentation this year, and we all thought it was hilarious. The “actors” are all IONA sales people, one of whom is (ironically enough) named Art. We talked forever about whether or not it should be posted on YouTube, and this week I found out that someone finally had.

Taking an open step

I first met James Strachan at a conference back in October, 2005, although I’d heard about him before that from my former DEC colleague, John Apps.
We were talking about JBI, Java, and related stuff when a well-dressed, energetic guy came over inserted himself into the converstation. It turned out to be Winston Damarillo, which was my introduction to him and his company, SimulaLabs. I had heard the Gluecode story (of course) but was not aware that Winston had started another company, which was basically an incubator of open source products such as ServiceMix. Since that time I’ve seen and talked with Winston many times, and of course today we released the announcement of the acquisition that brings James and his colleagues into IONA.
Debbie has written this up pretty well already, so there’s not much more for me to say but to welcome James and the rest of the LogicBlaze folks to IONA
This may seem like a relatively small acquisition, but it is a huge step for us, and hopefully for open source SOA in general.

Why Artix Registry/Repository is different

Update 4/4: see also Chris Horn’s thoughtful and interesting related entry about the concept of the “SOA Guardian,” drawing an analogy to government in general, referring to Cicero’s ultimate law as the welfare of the people – here of course we are talking about the role of the SOA reg/rep in ensuring the welfare of IT.
William has already written about this announcement, and Frank gives a good perspective and a comment about how some of the media reports have missed the point (some did not, to be fair).
I’d like to add some more perspective about why the Artix Registry/Repository is different. I often get asked why IONA is entering this market – isn’t it already sewn up? Aren’t we late to a croweded party? The answer is that the current solutions do not meet customer requirements.
Today’s registry/repository solutions are what I’d call passive. That means you store metadata in them, such as WSDL files, WS-Policy assertions, and other attributes descriptive of parts of the the SOA design. And then, like any database application, you look up things about what you stored.
Sometimes you can even store things related to management, such as service level agreements and policy enforcement points. But you can’t translate that into deployment configurations for your runtime container.
Sure, there’s even a notification system to alert interested parties when a service changes. But you are still stuck using manual procedures to create and update configuration and dependency information for your runtime container, using other tools.
Yes, you can use today’s registries to find services, and bind to services, notify someone of a change to a service, but you cannot do anything with the runtime implementation of the service. For that you need another tool or set of tools.
Current registry/repository solutions are not active, at least not in the sense that they allow you to actually do anything with the implementation of the services. They are comlpetely and totally disconnected from the SOA runtime.
Now part of the reason for this is that the industry is still hung up trying to use yesterday’s containers for today’s problem. Configurable, lightweight runtimes are gaining popularity as the complexity of JEE based application servers continues to inhibit SOA adoption. Same for EAI hub and spoke based solutions.
This is why all of a sudden we have vendors like BEA and Tibco out there announcing their new “micro” containers. IONA has been shipping a lightweight configurable container for 7 years.
We know that’s what you need for SOA. We have been doing SOA for 10 years.
So there’s been lots of talk recently about the obvious shortcoming in current registry/repository products, about developing active registry/repository solutions, but all that the other vendors have done is to propose a way to combine the passive registry/repository model with existing system management (and sometimes service management) solutions. That doesn’t really cut it. This is still assuming that things like application servers and EAI hubs are valid implementations of SOA infrastructure – which they are not.
Today’s passive registry/repository solutions just don’t give you the capability to work the metadata to configure your runtime and push the change out to the SOA infrastructure.
Now sure, I’ve mixed up the topics a bit here, between the obvious shortcoming of today’s passive registry/repository solutions, and the fact that most vendors still promote yesterday’s platforms as the answer to today’s requirements.
But I really think these are related. The industry is moving toward lightweight, configurable containers, via Spring and OSGi. A lightweight, distributed runtime is much better suited to SOA. Services can directly find and interact with each other, without having to go through a central application server or EAI hub.
The world of SOA infrastructure is adopting these lightweight, configurable runtimes, because you get more for your money, and software that’s better suited to the purpose. And as you do, the requirements of your SOA infrastructure will also be better served by an active registry/repository. One that’s able to deal with the composition and configuration implications of changes in service descriptions (i.e. the deployment implications).
When you change a policy, you want to be able to push that right out to the SOA infrastructure, and you don’t want to have to do a lot of manual recoding, recompiling, configuration, and redeployment using yesterday’s tools.
Update 4/2: One of my colleagues pointed out that I never came back to the point about the crowded market. SOA registry/repository is a very new market segment, and therefore by definition nowhere near sewn up or crowded.