[jboss-dev-forums] [Design of JBoss ESB] - Re: Virtual Registries?

Give a man a bucket for water and see how much he will spill.... I should start threads like this more often. The concept of the virtual registry is that the registry itself is not published and may not be a physical registry. Registries and UDDI came about through people trying to get a grip on how to "manage" services. If we have a central "registry" than we know what is running when, leads people into talks about governance, policies... etc... This is also a bit of legacy from the Object Brokering days. The registries value is to locate services and to register services. But what happens when you really don't want to "publish" a service to the world. I just want to use my instance and my instance alone not the registries. You get into these type of questions when you are deploying large scale systems across an organization. You may want to register a service for a bus that handles all the "public" traffic, but want to replace a service on a trial basis on a different instance that will essentially override one public service internally. If you had the notion of a virtual registry this would indicate that the bus is responsible for it's own services that are registered in the virtual registry and not published to the world. In addition, you may want to have service clients/consumers that talk to a bus A that use most of the main registry entries, with just one variation maybe version a slightly different syntax, etc... Bus B would just use the registry entries without any changes. This way clients could be running their whole system against bus A for a certain variation in their process Service A location is still the same on each bus but maybe on Bus A the service version is different. Also realistically I hate to say this but the concept of using a registry in a live system is something that a lot of engineers don't like to count on. The reason is that the registry could be down which makes it a single point of failure. The concept of auto-discover is an interesting debate that has happened for a while. If you ever design systems and infrastructure you pretty much know what is going to be there if something changes you would know and it wouldn't be a "dynamic" change. My thoughts are that we should be flexible with the fact that registries are great in principle, but let's not constrain ourselves to having a dependency on a global registry or a single registry. I might need to use a registry outside the company for some services in the bus, while the internal services are registered with a different registry. This is the idea of federation. Federation involves an external registry to aggregate or a whole infrastructure to provide federation which in itself is a "bus" like view geared toward managing entries and locations of services. So does an ESB worry about more than one registry? The answer is as services are being delivered and consumed by many companies and a bus is the "aggregator", "router" or whatever term you can generalize the bus too, it needs to be responsible for the services it manages regardless of how many registries are in the infrastructure or whether there is control over that. Look at the liberty alliance projects to look at how complicated the registries could become in the concept of federation. Instead why don't we view the bus as knowing about various registries and even taking into account that a registry could just be a concept and not a physical representation within the infrastructure "virtual". Make sense? Off my rocker? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024617#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...