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

"driedtoast" wrote : 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. | Governance and policy are things you need to be concerned about irrespective of your registry implementation or deployment configuration. anonymous wrote : | 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. | At the moment we do tend to use the registry for all services (at least to get the initial handle), but that is certainly something we are going to address. anonymous wrote : | 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. | Agreed, and that's how I've seen UDDI implementations deployed before. When at HP we would have a couple of implementations, one for live services and one for testing purposes. We didn't have an ESB in those days, but the idea is applicable nonetheless. anonymous wrote : | 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. | I'm not sure the term "virtual registry" actually helps here. A federated registry architecture would be my preferred option, like DNS. How much backend implementation details you care to expose to the ultimate user (invoker) of the registry is something to discuss, but it doesn't have to be a lot. For instance, if you had a federated architecture and a nomenclature for service names that identified them as test or live entities, you could ensure that one instance of the registry maintained service "test/foo" whereas another maintained the live version "foo". From a front-end users perspective, as we discussed yesterday, whether "test/foo" and "foo" actually do reside in different registries isn't important. That's a backend implementation/deployment choice. In fact, exposing it to the frontend would be a bad idea as it's getting us towards close coupling. anonymous wrote : | 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. | Again, I think this can be hidden to the user and yet achieve the same result. anonymous wrote : | 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. | As we discussed yesterday, there's a difference between the API the user interacts with and the backend implementation choice. There may be the concept of a single logical registry service, but it could be implemented using clustering or replication. That's the same approach you can use for all of the services. anonymous wrote : | 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. | And I think this can be hidden behind the client facade. anonymous wrote : | 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. | You can see I'm replying and reading your text as I come to it ;-) anonymous wrote : | 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? | If you take a look at some of the original architecture docs and presentations you'll see that the one example of federation of a service we have is based on federated registry. Obviously the idea was that it should be applied to any service, but registry was the important example. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024628#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...