"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! | | anonymous wrote : | | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024635#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...