Evaluation of jUDDI for JBossESB
I have built the juddi.war and have deployed it to jboss. Attached are my datasource and the war (with juddi-0.9rc4). The datasource is for a mysql db. I used to have an issue in jboss4 but that has been worked out.
As is typical with UDDI registries the communication protocol used between Scout and jUDDI is SOAP.
Figure 1. Typical use of JAXR, where the communication between the JAXR imeplementation and the XML Registry is SOAP. Note that the communication protocol is not specified in JAXR itself.
To improve performance we can write our own local transport implementation which simply makes local calls. Scout itself is ignorant of the protocol used, and the transport implementation is conveniently hidden behind a Transport interface. In this case jUDDI will no longer be approached via the InquiryService
servlet and we will need to write a class much like the AbstractService, which will be directly called from our local transport class. See also this thread on the Design Forum. We call this an embedded registry.
Figure 2. Embedded jUDDI
Now we can embed jUDDI in any java application. Here are some configuration options that one can consider.
If the registry is embedded in application 1 (i.e. the JBossESB), other java apps can use JAXR and RMI (Scout with our RMI-Transport) to connect to the UDDI embedded in the JBossESB, this is depicted in figure 3.
Figure 3. Scenario 1. A Single jUDDI, with RMI transports.
Each application has their own embedded jUDDI, which is configured to use the same database. Or use their own registry database with somekind of replication, see figure 4.
Figure 4. Scenario 2. Distributed registries. Feeding of 1 or multiple databases.
What if the client is not java based? Those apps can send uddi SOAP requests directory to jUDDI, as shown in figure 4.
Figure 5. Scenario 3. Using jUDDI with not java applications.