You have seen now how to interact with a Web service using SOAP; you have also seen how to find out about what the service offers using WSDL.The final question that we will discuss here is this. How do you find the Web service in the first place? If you want to find a Web site that offers something you have never looked for before, the easiest way to find what you are after is to visit a search engine.The equivalent for a Web service is a UDDI Registry. Service providers register with the registry, and then clients can locate the services by querying the registry. UDDI registries enable you to locate businesses and services in a number of different ways:
The information that enables the data to be accessed in this way is stored in an XML structure.This structure is part of the UDDI specification.The UDDI specification covers more than this data structure, however. UDDI defines a number of standards surrounding these registries of Web services:
The details of the UDDI specification are available from the UDDI home page
In this section, we will focus on the interaction with UDDI registries to locate Web services and find out about them.The technology is still emerging and evolving surrounding UDDI, but you can still try some of these techniques out. There are a number of registries available that you can register your Web services with. These URLs provide a browser front end to the UDDI registries. It can be helpful to have a browse around these sites because it helps to crystallize what sort of information is stored about a specific business entity.
The UDDI XML
Every new entry in a UDDI registry is available as an XML document. If you notice in the earlier list of what UDDI defines. One is the schema defining a UDDI entry. Listing 12.22 shows a UDDI XML file for a company offering the averager service that we entered into the IBM UDDI registry.
Listing 12.22 UDDI Entry in the IBM Test Registry
This entry was submitted through a series of HTML forms. I did not have to submit the XML file itself.The XML contains information about the company, along with the services provided. Note the access point in the XML referring to the Web service WSDL file.This is only a test area, so the fact that it is pointing to localhost does not matter. The UDDI XML contains the following core elements:n <businessEntity> n <tModel> n <businessService> n <categoryBag> n <bindingTemplate> n <publisherAssertion>
The <businessEntity> Element
The <businessEntity> element defines the business itself. It contains child elements and attributes defining the contact information, the business name, and any services that are available to clients.The information stored includes the equivalent of a yellow and white pages entry.
The <businessService> Element
The <businessService> element defines a service that is available from a business. Each <businessService> is a child of a <businessServices> element. Notice the use of various unique identifiers throughout this element:
The <businessService> element consists of a name, description, a bindingTemplate, and a categoryBag.The name and description are self explanatory, but the other two are not so obvious.
The <categoryBag> Element
The <categoryBag> element contains categorization information for the service.There are already a number of ways to categorize companies and organizations, and UDDI rather sensibly does not try to define another one, but use the pre-existing mechanisms. The supported categorization standards are currently:
Each of these has a unique identifier to specify which classification mechanism is being used. In the example shown, the tModelKey refers to the classification system.<categoryBag><keyedReference tModelKey=”UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2” keyName=”Computer Training” keyValue=”61142”/></categoryBag>
The key value UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2 specifies that the classification in use here is the NAICS classification.The keyName and keyValue both have values from the NAICS classification system.
The <bindingTemplate> Element
Notice the use of more unique identifiers in this section of the UDDI XML file.The business and the service have both been assigned unique identifiers. The role of the <bindingTemplate> element is to hold the specific information about the actual service. It contains two child elements, the <accessPoint> and the <tModelInstance>.
The accessPoint is the location of the service itself:<accessPoint URLType=”http”> http://localhost:8080/axis/services/averager?wsdl</accessPoint>
The <tModelInstance> requires some further explanation.
The <tModelInstance> and the <tModel> Elements
What exactly is a tModel? The name doesn’t exactly give it away! The tModel represents a technical specification within the context of a UDDI registry, and this specification will have a unique ID. A good example would be a tModel referring to a WSDL file. The WSDL is the specification document for the Web service. In Listing 12.22, the tModelInstance is a reference to a pre-existing tModel:
This tModel key identifies the resource being referred to.This key value refers to any browser or HTTP-based Web service. In the context of the UDDI XML file in Listing 12.22, this informs any clients of the kind of service that is being referenced here. You have now seen the basics of the UDDI XML file.The question is, how can this information be accessed from clients who want to invoke locate the Web service?
The UDDI API
From a Web application perspective, you might well want to query a UDDI registry to locate appropriate Web services.This can be achieved using the UDDI API.This API is also part of the UDDI specification, and there is an implementation written with the Java Programming Language called UDDI4J. It can be obtained from . Using this API, service providers can modify and publish services and information about themselves, and clients can query this information. Essentially, the API enables service providers to programmatically modify their UDDI XML entry, and clients can query the UDDI XML entries.
Listing 12.23 is an example of a JSP that queries the IBM UDDI registry for specific service and displays the information about that service.The code has been kept in one JSP to make it clear as to how it works.
Listing 12.23 uddiClient.jsp
This JSP will look up the services based on a specific business ID, and then display its name, key, and the business key. If you are trying this out, it is located within the clientStubWeb application within the chapter12.zip file.
The system property being set is used by the UDDI4J API to determine what kind of transport it should be using to interact with the UDDI registry.The alternatives are Apache SOAP, and HP SOAP.The property values areTransportClassName=org.uddi4j.transport.ApacheSOAPTransport TransportClassName=org.uddi4j.transport.ApacheAxisTransport TransportClassName=org.uddi4j.transport.HPSOAPTransport
The org.uddi4j.client.UDDIProxy class represents the UDDI server, so all actions that you want to do are against this object.There are two URLs associated with this object. One is the inquiry URL, and the other is the publish URL.The UDDI registry publishes these URLs. If you are a service provider and want to change the services you provide, you would use the publish URL. If you are a client, you use the inquiry URL.To set these URLs, there are two methods of the UDDIProxy class:void setInquiryURL (String url) void setPublishURL (String url)
In Listing 12.23, the setInquiryURL method is being used.The URL is for the IBM Web Services test area. The find_service method is then used to locate services for a specific business ID. The various arguments can be used to specify details such as filter criteria.This returns a ServiceList object, which contains a vector of ServiceInfo objects, one for each provided service.The ServiceInfo object can then be queried for the service name and id. Figure shows the result in a browser, and Figure shows the screen from which the two returned services were set up.
uddiClient.jsp in a Web browser.
Setting up information in a UDDI registry.
There is a related API that can be used with UDDI called the Java API for XML Registries (JAXR) which was introduced earlier in the chapter along with the SAAJ API for SOAP, and the JAX-RPC API for invoking web services. JAXR is part of J2EE 1.4, and is specifically for the purpose of interacting with registries - they do not have to be UDDI.The benefits of JAXR over UDDI4J are that it not restricted to UDDI registries only, and it is also a J2EE standard. Listing 12.24 shows a JAXR application that queries the IBM UDDI test registry.
Listing 12.24 JAXRQueryExample.java
If you wish to try this example, it is found in the zip file download for this chapter in the folder clientsjaxr, and to run it you will require the JARs from the commonlib folder within the Java Web Services Developers Pack (JWSDP) from Sun to be in the classpath.There is a batch file called setclasspath.bat provided with the example that assumes an environment variable has been set called JWSDP_ HOME which points to your JWSDP installation folder.
The code in Listing 12.24 when run requires an argument which is a search string.You can use any company name that may have a web service registered with the IBM UDDI Test registry. We will now unpack the code in Listing 12.24 and explain what is going on. It is similar to the UDDI4J API. First, a Connection is obtained to the IBM Test Registry.This is done by configuring a ConnectionFactory via properties, and then using it to obtain a connection to the registry. Once a connection to the registry is established, you can then obtain a reference to a BusinessQueryManager which can be used to execute a query against the registry.The query is carried out using the findOrganizations method.This method takes in six arguments, the first two of which are of interest in ourexample: BulkResponse response = manager.findOrganizations( qualifiers, patterns, null, null, null, null);
The qualifiers argument is a collection that specifies how the results from any queries are to be returned.The patterns argument specifies what is being searched for. In our case, the patterns argument contains the query argument provided at the command line.
The response from the registry is encapsulated in a BulkResponse object, which can be queried for the data.There are various methods that can then be used to extract information about the organization and the services that it provides. For example, to extract the collection of returned UDDI entries as a Collection, you use the getCollection method of the BulkResponse object.You can then iterate through the collection as demonstrated. Note that the collection contains Organization objects.Organization org = (Organization)iter.next();
You can then access the name and description of the organization, and any services that it has.System.out.println(“Name: “ + org.getName().getValue()); System.out.println(“Description: “ + org.getDescription().getValue());
JSP Related Interview Questions
|J2EE Interview Questions||Core Java Interview Questions|
|JDBC Interview Questions||Java Servlets Interview Questions|
|Hibernate Interview Questions||JavaServer Faces (JSF) Interview Questions|
|JSTL(JSP Standard Tag Library) Interview Questions||JBOSS Interview Questions|
|Log4j Interview Questions||NHibernate Interview Questions|
|Apache Struts 2 Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.