JBoss.orgCommunity Documentation

Chapter 3. jUDDI Architecture

Table of Contents

3.1. jUDDI Server
3.1.1. UDDI API layer uddi-ws using JAX-WS
3.1.2. Core UDDI juddi-core using JPA
3.1.3. Relational Databases
3.1.4. Servlet Containers
3.2. jUDDI GUI juddi-gui.war

The jUDDI Architecture leverages well known frameworks to minimize the codebase we need to maintain. The API layer uses JAX-WS, while the persistence layer uses JPA. The entire server is packages as a war archive that can be deployed to different servlet containers with minimal configuration changes. The JPA layer uses JDBC to communicate to a relational database. Figure 3.1, “jUDDI Architecture” shows the different components, where the implementation providers marked with a blue dot are the implementations we use by default.

The jUDDI GUI is also a Web Archive that is deployed along side the juddiv3 server in the same servlet container. The GUI uses the juddi-client to communicate to the UDDI API Endpoints. It can use a SOAP, RMI or an inVM transport protocol, so the GUI can be deployed in a different location then the server as long as it can connect to the UDDI SOAP API.

Figure 3.2, “jUDDI Client and Console Architecture” shows the admin console and the juddi-gui. Typically one one run the admin console behind a firewall. The admin console interacts over a jUDDI WS API and, among other things, it can be used to create and delete publishers.

The juddi-gui can be configured to connect to any UDDIv2 or UDDIv3 compliant UDDI server.

You may have a jUDDI v3 Server for each type of environment (Dev, QA and Prod) and you would only need one console to connect to each one of them.

For details on using the GUI see the Client and GUI Guide [stam-oree].