Browse DevX
Sign up for e-mail newsletters from DevX


Creating Your Own Private UDDI Registry : Page 5

You don't have to rely on some huge public UDDI repository to expose your Web services to developers and automated processes. Instead, find out how to set up a UDDI registry on your own server.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

jUDDI Data Structures
jUDDI encapsulates the primary UDDI data structures (businessEntity, businessService, bindingTemplate and tModel) in classes following the ValueObject pattern. The classes are found subordinate to the org.apache.juddi.datatype package as follows:

  • org.apache.juddi.datatype.business.BusinessEntity
  • org.apache.juddi.datatype.service.BusinessService
  • org.apache.juddi.datatype.binding.BindingTemplate
  • org.apache.juddi.datatype.tmodel.TModel
Instances of each of these classes (along with all other UDDI data types) are acted on by jUDDI handlers and functions in order to process client requests, as shown in Figure 4

Figure 4. Process Flow for a Save_Business Request: The diagram illustrates the class instances and process flow for a save_business request:
Handling Publication Requests with jUDDI
The jUDDI framework dispatches request messages through an Axis handler object—aptly named AxisHandler. The AxisHandler class uses the services of the RegistryEngine class to do the actual request processing. A URL mapping for a specific child of AxisServlet is used to classify inquiry requests, publish requests, and admin requests.

The framework classifies each request according to the property value set in the request's MessageContext object for the transport.http.servlet key. Thus, the framework maps the following URL to the PublishServlet:


After receiving a request, the RegistryEngine class converts the XML-based UDDI request to Java objects (a process called unmarshalling), invokes the appropriate Java objects, and converts Java objects to XML-based responses (called marshalling).

Handling Inquiry Requests with jUDDI
As with a publish request, a URL mapping for a specific child of AxisServlet is used to classify inquiry requests. The transport.http.servlet property of the request's MessageContext object will return an instance of the InquiryServlet class and therefore be routed accordingly. Thus, jUDDI will map the following URL to the InquiryServlet:


Handling Authentication Requests with jUDDI
jUDDI uses the org.apache.juddi.auth.AuthenticatorFactory object to create the desired Authenticator instance in order to authenticate a client. AuthenticatorFactory is an implementation of the Factory pattern. You use it to create an implementation of the org.apache.juddi.auth.Authenticator interface. You retrieve the name of the specific Authenticator implementation to create from the "juddi.auth" property value. If you pass a null value then the AuthenticatorFactory creates a default Authenticator implementation "org.apache.juddi.auth.DefaultAuthenticator." The DefaultAuthenticator class applies no restrictions; therefore, it allows all requests.

Production systems should supply an implementation of the Authenticator interface that can authenticate callers against an existing authentication system. The Authenticator implementation class is registered in the juddi.properties file.

Thanks for your registration, follow us on our social networks to keep up-to-date