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.


2 responses to “Why Artix Registry/Repository is different

  1. Newcomer explains “Why Artix Registry/Repository is different”

    IONA recently announced their distributed SOA Registry/Repository. The key differentiator is its “active” capability. IONA’s CTO explains in more detail the virtues of active registry/repository over previous “passive” solutions. – SOA Network Architec…

  2. It’s Runtime, Do You Know Where Your Code Is?

    I just came across an interesting post by Eric Newcomer of Iona. He writes about SOA solutions and how many…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s