"kurt.stam(a)jboss.com" wrote : We will soon have an embeddedable JAXR/UDDI component using Apache Scout as the JAXR implementation, a local transport implementation to support local java calls, and a slightly modified jUDDI to support these direct java calls (and soon there after hopefully RMI calls too). OK so far so good. Now the ESB has access to any kind of XML registry (it'd be ebXML or UDDI), and by default it will use embedded jUDDI. | | Now what if other systems want to access this registry? | As long as the registry implementation is pluggable, then anyone who wants to replace our out-of-the-box implementation with their own will have to determine the best deployment configuration for themselves. This works fine as long as the interface we're using (JAX-R) does not expose any deployment/implementation choices: I assume it doesn't. What I'm driving at is that as long as the interface is right, this is just another server and clients/services don't need to know (probably couldn't care) whether it is co-located or running in another address space. So what you're asking below is really specific to our out-of-the-box deployment, true? anonymous wrote : | I see 3 scenarios of how you could do this: | 1. If the registry is embedded, those systems can use JAXR and RMI (Scout with our RMI-Transport) to connect to the UDDI embedded in the JBossESB. | 2. Those systems can call to their very own embedded jUDDI, which is configured to use the same database. Or use their own registry database with somekind of replication. | 3. What if the client is not java based? Then you could deploy juddi.war and point it to the same registry database (or in jboss - versions newer then 4.0.2 you already have juddi build-in when running 'all'.). Now you have a soap webservice you can go to (for UDDI). | I think this covers the bases as far as the 4.0 GA is concerned: shared or independent deployments. We just need to make sure that we can support those configurations fairly easily as far as the user is concerned, i.e., "use this config for a single shared Registry Service, and this one for independent co-located Registry Service". anonymous wrote : | Do these scenarios seem right? Does it cover all real world needs? BTW I'm not talking about clustering and/or caching, we can worry about that later. | | We could take it to the next level and bring up a Registry Service in the JBossESB. | We definitely need to support that. anonymous wrote : | All clients can/should connect to this one and it can query to other registries in your business. If we do this, what kind of XML protocol should we support? Our own, or both UDDI and ebXML. Do we need something like this for the GA release? | | I'd love some feedback on this :). | | --Kurt | The default deployment for our Registry Service should be a single instance per ESB. That's the easiest for people to understand and manage. Once we go beyond the GA, we can add in caching, fault tolerance etc. What do you mean by "what kind of XML protocol"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973181#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...