With the SAP Web AS Java, enterprises can set up their own Universal Description, Discovery and Integration (UDDI) server. In this article, we will provide answers to the following questions:
What is the purpose of a UDDI server?
What is the basic architecture?
How do you configure a UDDI server?
20 Jul 2004
What Is the Purpose of a UDDI Server?
When using Web services, we distinguish between the service provider and the service requestor. In the simplest case, we can assume that the service provider – the person who provides the services – knows the service requestor and informs the latter where services can be found. However, this contradicts the idea of Web services as a global service platform. What makes the use of Web services so attractive is precisely the idea that applications can be built from Web services that are available globally. This service can be provided with UDDI.
UDDI is a basic, integral part of the Web Service Framework. UDDI is used by service providers in order to make services known. It is also used by service users to find a service that meets special requirements. Many companies provide UDDI server implementations (public and private). One public, free of charge Universal Business Registry (UBR) exists with data replication between the different nodes. Their Web-based UIs can be found at: SAP http://uddi.sap.com/, Microsoft http://uddi.microsoft.com/, or IBM http://uddi.ibm.com/.
SAP Web AS includes a UDDI Server implementation. With the help of this implementation customers can create their own private registry. A UDDI business registry is a central database in which companies can register their services. The registry is something like an address book where providers and services are listed. A UDDI registry provides three types of information:
The white pages are a register that is sorted by provider name. The white pages get their information from the business entity element, a basic data structure in the UDDI information model. The name, address, and industry sector of the Web service provider are stored here. The business entity element also functions as a type of container to hold all other information on a Web service. Therefore, one main prerequisite for the publication of a Web service in a UDDI registry is the availability of a business entity.
The yellow pages are a registry sorted by categories. The service information in the yellow pages is stored in the business service element. The purpose is to sort services into groups – for example, on the basis of the business processes for which they were conceived. Examples of business processes include e-business services for purchasing goods.
The green pages contain technical details on services provided. They contain binding templates, that is, technical data, so a user can get in contact with a Web service and communicate with it. This category includes, for example, the Web address to reach a service. The tModel element provides even more detailed data – a subset of the binding templates. It describes the specification of the interfaces used by a Web service.
With the help of a UDDI server, you can set up public as well as private registries. Companies can provide private directories, for example, for business partners’ access. But within the intranet, too, you can set up Web service registries. With the help of the currently used UDDI version 2.0, you can assume that private directories will be used more frequently than public catalogs for reasons of safety. Companies are currently showing a tendency to implement Web services initially in networks that are protected from the outside through firewalls.
What Is the Basic Architecture?
UDDI servers have the following basic architecture:
Figure 1. Basic architecture.
Web User Interface
The user interface for a UDDI server is the UDDI client. It enables you to perform a browser-based search for, and publish data on, the UDDI server. You call a UDDI client with:
In the <host> field, enter the required host name. In the <port> name, enter 50000. By default, the port is 50000. The Web User Interface can be used if a J2EE engine has been started and the UDDI server has been configured on this application server.
UDDI servers can be operated either manually through the browser or through client programs using SOAP APIs.
To access the data of a UDDI registry, the client software uses SOAP through HTTP. UDDI provides, as a web service, an inquiry API and a publishing API – in accordance with the specifications. The calls for applications that search through the business registry form the inquiry API. This includes calls such as find_business and find_service. On the other hand, applications must be in a position to create and change this information. For this purpose, calls such as save_business and save_service are available. You can use them to create or update information for a business entity or for a business service.
The following SOAP APIs can be used with the UDDI server.
You can decide in the Visual Administrator on whether to use the publishing API http or https. We recommend you install the cryptographic library and use https.
The UDDI registry data is usually stored in a relational database. The J2EE Engine Database is used by default. Using a few administrative steps, you can also store data in other databases
The UDDI logic implements the search and publication functions defined in the UDDI standard. The data searched for using a SOAP API or a Web user interface is read from the database using UDDI logic. Likewise, data is published and written to the database with the help of the appropriate utilities.
How Do You Configure a UDDI Server?
You configure the UDDI server with the help of the Visual Administrator. The following steps are necessary:
Preload core taxonomies.
Set up registries.
Preload core taxonomies
After installation, the UDDI Server database is empty and does not include even the core tModels. To use the UDDI server, you must reset the database used. UDDI data that was available previously is deleted; UDDI core tModels and taxonomies are imported.
In the Visual Administrator, choose Web Services Container Service -> Runtime -> UDDI Server. In the General register, select the checkbox Preload base tModels and taxonomies (UNSPSC, ISO-3166, NAICS, etc…) and then choose Reset DB.
Figure 2. UDDI Server Configuration
Set up registries
In the Visual Administrator, choose Web Services Container Service -> Runtime -> UDDI Client. Choose New Registry and enter the Registry Name, the Inquiry URL, and the Publish URL.
Figure 3. UDDI registries.
Users and roles play an important part in the publication of new services in UDDI registries. If you have a non-public registry, only a selected circle of users should be allowed to make entries in the UDDI database. In the Visual Administrator, choose Web Services Container Service -> Runtime -> UDDI Server -> Users. You can choose the following authorization levels:
Level Tier 1
The user can create the following:
• 1 business entity
• 4 business services
• 2 binding templates for each business service
• 100 tModels
Level Tier N
The user can create an arbitrary number of UDDI objects.
The user can create an arbitrary number of UDDI objects and delete the UDDI data of other users.
Figure 4. Authorization levels table.
Figure 5. User data example.
UDDI servers should enable companies to register Web services and to provide them to internal and external users who are appropriately authorized. A UDDI server can be set up for each J2EE engine. You configure a UDDI server by setting up registries and users for this UDDI server.
You can publish Web Services in a UDDI registry by publishing the tModel in the SAP NetWeaver Developer Studio and then making the Web service available with the Visual Administrator. You must publish a business entity that contains the general information on the name, address and business sector of the Web service provider.