Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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.


advertisement

WEBINAR: On-Demand

Unleash Your DevOps Strategy by Synchronizing Application and Database Changes REGISTER >

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:

http://localhost:8080/juddi/publish

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:

http://localhost:8080/juddi/inquiry

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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

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