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