-
-
17. 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? -
18. Re: Virtual Registries?
Anyway getting back to my original reason for bringing this up....
The concept would be this, for every framework to integrate it is hid behind a registry (yes a virtual one). So the bus would request a service from the registry and the registry would look at the framework to realize the service.
For instance:// pseudo code businessQueryMgr.findServices(....) -> applicationContext.findBean(serviceName) -> wrap in service object -> add to BulkResponse return service;
The other idea is that maybe based on the service category the registry is determined by that instead of a specific reference per the service definition.
So I could...
register a registry to register registered bean of that registered registry!
service category=registry class
If we use the category the ESB would talk to its registry that would front a registry of registries
:) -
19. 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.
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.
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.
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.
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.
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.
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.
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 ;-)
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. -
20. Re: Virtual Registries?
"driedtoast" wrote:
Anyway getting back to my original reason for bringing this up....
The concept would be this, for every framework to integrate it is hid behind a registry (yes a virtual one). So the bus would request a service from the registry and the registry would look at the framework to realize the service.
For instance:// pseudo code businessQueryMgr.findServices(....) -> applicationContext.findBean(serviceName) -> wrap in service object -> add to BulkResponse return service;
The other idea is that maybe based on the service category the registry is determined by that instead of a specific reference per the service definition.
So I could...
register a registry to register registered bean of that registered registry!
service category=registry class
If we use the category the ESB would talk to its registry that would front a registry of registries
:)
Take a look at the front-end code we use. It seems to me that what you're after (and the federated approach I mentioned earlier) can be handled there. One way (not necessarily the only way) would be to allow the registration of service-registry handlers/mappers and then the frontend code calls them to lookup the service. In pseudo-code:
client->registry_frontend.lookup(service)
registry_frontend.lookup (service)
{
// go through all registry service-name handlers
loop
{
if handler[loopiter].managestype(service)
return handler[loopiter].lookup(service);
}
return nosuchservicefound;
}
The mapping of handlers to types of service could be done dynamically and also with a static config file. -
21. Re: Virtual Registries?
The mapping of handlers to types of service could be done dynamically and also with a static config file.
That is fine with me, since it does what I want to achieve.
It is amazing how much discussions we can have around a fancy map of services.
:) -
22. Re: Virtual Registries?
Yes ;-) The only reason I mentioned that approach is because that's how I've seen deployments of the good 'ol CORBA trading service used, in the past and still today.