Web application unit- 5
Universal Description, Discovery, and Integration (UDDI) is a platform-independent
framework for describing services, discovering businesses, and integrating business services
using web services. It serves as a directory for web services, allowing organizations to
publish and discover services over the internet.
1. Registering Services in UDDI
To register a service in UDDI, you need to follow these steps:
1.1 Define Your Service
Before registering, you should have a clear understanding of your web service. This includes:
• Service Name: A unique name for your service.
• Service Description: Details about what the service does.
• Binding Information: URL or other details needed to access the service.
• Business Information: Information about the business providing the service.
1.2 Create a UDDI Business Entity
1. Business Entity: Represents the organization that is offering the service.
2. Business Service: Represents the service offered by the business.
3. Binding Template: Contains the details about how to access the service, including
the WSDL URL.
Example:
Assume you have a web service that provides weather information. Here's how you might
structure the UDDI registration:
1. Business Entity:
o Name: WeatherCo
o Description: A company providing accurate weather forecasts.
2. Business Service:
o Name: Weather Forecast Service
o Description: Provides weather forecasts based on location.
3. Binding Template:
o Access Point: http://weatherco.com/services/forecast
o WSDL URL: http://weatherco.com/services/forecast?wsdl
o Binding Details: SOAP over HTTP
1.3 Register Using UDDI APIs or a UDDI Registry Interface
You can use UDDI APIs or a UDDI registry interface to register your service.
Using UDDI APIs:
Here's a high-level overview of how you might use the UDDI APIs for registration:
• Publish: Use the publish API to create a new Business Entity, Business Service, and
Binding Template.
• API Example:
xml
Copy code
<uddi:publish>
<businessEntity>
<name>WeatherCo</name>
<description>A company providing accurate weather
forecasts.</description>
</businessEntity>
<businessService>
<name>Weather Forecast Service</name>
<description>Provides weather forecasts based on
location.</description>
</businessService>
<bindingTemplate>
<accessPoint>http://weatherco.com/services/forecast</accessPoint>
<wsdlURL>http://weatherco.com/services/forecast?wsdl</wsdlURL>
</bindingTemplate>
</uddi:publish>
2. Discovering Services in UDDI
To discover services, you need to perform a search query based on the criteria you are
interested in.
2.1 Define Search Criteria
You can search for services using various criteria:
• Service Name: The name of the service.
• Business Name: The name of the business offering the service.
• Keywords: Any relevant keywords related to the service.
• Category: The category or type of service.
Example:
If you're looking for weather services, you might search with the keyword "weather".
2.2 Use UDDI APIs to Perform the Search
You can use UDDI APIs to search for services. Here’s a high-level overview:
• Find: Use the find API to search for Business Entities, Business Services, and
Binding Templates.
• API Example:
xml
Copy code
<uddi:find>
<query>weather</query>
</uddi:find>
2.3 Retrieve and Interpret Results
After querying, you'll receive a list of services that match your criteria. Each result will
include:
• Business Entity: Information about the business providing the service.
• Business Service: Details about the specific service.
• Binding Template: Information on how to access the service, such as the WSDL
URL.
Example of Search Results:
• Business Entity: WeatherCo
o Service Name: Weather Forecast Service
o Access Point: http://weatherco.com/services/forecast
o WSDL URL: http://weatherco.com/services/forecast?wsdl
Summary
• Registering Services: Define your service, create business entities, business services,
and binding templates, and use UDDI APIs to publish.
• Discovering Services: Define your search criteria, perform the search using UDDI
APIs, and interpret the results to find relevant services.
1. Service Registries
Role: Service registries act as centralized directories where web services can be registered
and discovered. They help in maintaining information about services, including their
locations and capabilities. This role is crucial in service-oriented architectures (SOA) where
services need to be easily accessible and discoverable.
Key Functions:
• Service Registration: Web services publish their details (e.g., service description,
access URL) into the registry.
• Service Lookup: Clients or other services query the registry to find available services
based on their needs.
• Service Management: Registries provide tools for managing service information,
including updates and deletions.
Example: Consider a financial services application that provides stock market data. The
service registry would contain entries for services such as:
• Stock Quote Service: Provides real-time stock quotes.
• Historical Data Service: Provides historical stock data. Each entry would include
details like service endpoints, descriptions, and other metadata.
2. Service Discovery
Role: Service discovery is the process of finding services that meet specific criteria within a
service registry. It enables applications and services to dynamically locate and interact with
other services based on various attributes or keywords.
Key Functions:
• Search Queries: Services can be queried based on attributes such as service name,
keywords, category, or business entity.
• Dynamic Resolution: Allows for the dynamic discovery of services, enabling
applications to adapt to changes in service availability and locations.
• Filtering and Sorting: Discovery mechanisms can filter and sort results to help users
find the most relevant services.
Example: Imagine a healthcare application that needs to find a service providing medical
imaging data. The application would query the service registry with keywords like “medical
imaging” and receive a list of relevant services, such as:
• Medical Imaging Service: Provides MRI and CT scan images.
• Radiology Report Service: Provides radiology reports and diagnostics.
3. UDDI (Universal Description, Discovery, and Integration)
Role: UDDI is a standard protocol and specification designed to facilitate service registration,
discovery, and integration. It serves as a universal directory for web services, allowing
organizations to publish their services and for clients to discover and use them.
Key Components:
1. Business Entity:
o Represents the organization or business providing the services.
o Includes information like business name, description, and contact details.
2. Business Service:
o Represents the individual services offered by the business.
o Includes service name, description, and category.
3. Binding Template:
o Contains details about how to access the service, including the endpoint URL
and the service's WSDL (Web Services Description Language) document.
4. Service Description:
o A comprehensive description of the service's functionality and how it can be
used.
Example: Let’s say you are developing a logistics application and need to register and
discover a shipment tracking service. Here’s how you might use UDDI:
1. Registering a Service:
o Business Entity:
xml
Copy code
<businessEntity>
<name>LogisticsInc</name>
<description>A leading logistics and shipping
company.</description>
</businessEntity>
o Business Service:
xml
Copy code
<businessService>
<name>Shipment Tracking Service</name>
<description>Track shipments and delivery
status.</description>
</businessService>
o Binding Template:
xml
Copy code
<bindingTemplate>
<accessPoint>http://logisticsinc.com/services/track</accessPoin
t>
<wsdlURL>http://logisticsinc.com/services/track?wsdl</wsdlURL>
</bindingTemplate>
2. Discovering a Service:
o Search Query:
xml
Copy code
<find>
<query>shipment tracking</query>
</find>
o Search Result:
xml
Copy code
<service>
<businessName>LogisticsInc</businessName>
<serviceName>Shipment Tracking Service</serviceName>
<accessPoint>http://logisticsinc.com/services/track</accessPoin
t>
<wsdlURL>http://logisticsinc.com/services/track?wsdl</wsdlURL>
</service>
Summary
• Service Registries: Central directories for publishing and managing service
information.
• Service Discovery: The process of finding services based on search criteria within the
registry.
• UDDI: A standard for service registration and discovery, providing a structured way
to publish and locate web services.
1. UDDI Architecture
UDDI Architecture outlines how different components and entities interact within the UDDI
framework to support the registration, discovery, and integration of web services.
Key Components:
1. UDDI Registry:
o Description: A UDDI registry is a centralized directory where businesses can
publish their web services, and where clients can search for and discover these
services.
o Types:
▪ Public UDDI Registries: Available to everyone, often used by various
organizations for broad service discovery.
▪ Private UDDI Registries: Used within organizations to manage
internal services.
2. UDDI Data Model:
o Business Entity: Represents an organization or company.
o Business Service: Represents a specific service offered by the business.
o Binding Template: Provides details about how to access the service,
including the service endpoint and WSDL URL.
o Publisher Assertion: Used to assert a business's capability to provide a
service.
3. UDDI Interfaces:
o Inquiry API: Used for searching and retrieving information from the registry.
o Publishing API: Used for registering and updating information in the registry.
Example Architecture:
1. Publisher: A company that wants to register its web service.
2. UDDI Registry: A public or private registry where services are registered.
3. Consumer: An application or another service that searches the UDDI registry to
discover and use the registered services.
Workflow:
1. The Publisher submits service details to the UDDI Registry via the Publishing API.
2. The Consumer uses the Inquiry API to search for services in the UDDI Registry.
3. The Consumer retrieves the service details and interacts with the service as needed.
2. UDDI Data Model
The UDDI Data Model defines the structure and relationships of the data elements used to
describe web services in the registry.
Core Data Elements:
1. Business Entity:
o Purpose: Represents the organization that provides one or more services.
o Attributes:
▪ Business Name: The name of the business.
▪ Description: A textual description of the business.
▪ Contact Information: Details about how to contact the business.
2. Business Service:
o Purpose: Represents a specific service offered by the business.
o Attributes:
▪ Service Name: The name of the service.
▪ Description: A description of what the service does.
▪ Category: Classification of the service.
3. Binding Template:
o Purpose: Contains information on how to access the service.
o Attributes:
▪ Access Point: URL or other means to access the service.
▪ WSDL URL: URL to the WSDL document describing the service.
▪ Binding Details: Protocol details, such as SOAP or REST.
4. Publisher Assertion:
o Purpose: Used to assert and maintain the accuracy of service information.
o Attributes:
▪ Assertion Details: Information about the assertion and its validity.
Example Data Model:
1. Business Entity:
xml
Copy code
<businessEntity>
<name>WeatherCo</name>
<description>Provides weather forecasts and climate
data.</description>
<contact>
<email>[email protected]</email>
</contact>
</businessEntity>
2. Business Service:
xml
Copy code
<businessService>
<name>Weather Forecast Service</name>
<description>Offers real-time weather forecasting.</description>
<category>Weather Services</category>
</businessService>
3. Binding Template:
xml
Copy code
<bindingTemplate>
<accessPoint>http://weatherco.com/services/forecast</accessPoint>
<wsdlURL>http://weatherco.com/services/forecast?wsdl</wsdlURL>
<bindingDetails>SOAP over HTTP</bindingDetails>
</bindingTemplate>
3. UDDI Interfaces
UDDI provides several interfaces to interact with the registry, primarily through APIs. These
interfaces allow for publishing, querying, and managing service information.
Key Interfaces:
1. Inquiry API:
o Purpose: To search and retrieve information about registered services.
o Common Operations:
▪ Find Business: Search for businesses based on name or description.
▪ Find Service: Search for services based on name or description.
▪ Find Binding: Retrieve service binding information.
Example Inquiry Query:
xml
Copy code
<findService>
<name>Weather Forecast</name>
</findService>
2. Publishing API:
o Purpose: To publish and update service information in the registry.
o Common Operations:
▪ Register Business: Add a new business entity.
▪ Register Service: Add a new service offered by the business.
▪ Register Binding: Add or update the binding template for a service.
Example Publishing Request:
xml
Copy code
<publish>
<businessEntity>
<name>WeatherCo</name>
<description>Provides weather forecasts.</description>
</businessEntity>
<businessService>
<name>Weather Forecast Service</name>
<description>Real-time weather forecasts.</description>
</businessService>
<bindingTemplate>
<accessPoint>http://weatherco.com/services/forecast</accessPoint>
<wsdlURL>http://weatherco.com/services/forecast?wsdl</wsdlURL>
</bindingTemplate>
</publish>
4. UDDI Implementation
UDDI implementation involves deploying and configuring a UDDI registry and integrating it
with web services to support service registration and discovery.
Steps for Implementation:
1. Choose or Implement a UDDI Registry:
o Commercial UDDI Registries: Examples include Microsoft UDDI Services,
IBM WebSphere UDDI.
o Open Source UDDI Registries: Examples include Apache jUDDI.
2. Set Up the UDDI Registry:
o Installation: Follow the installation instructions provided by the UDDI
registry software.
o Configuration: Configure the registry settings, including security, user
access, and network configurations.
3. Publish Services:
o Use Publishing API: Register your web services in the UDDI registry using
the Publishing API.
o Example: A logistics company publishes its shipment tracking service in the
registry.
4. Discover Services:
o Use Inquiry API: Query the UDDI registry to find available services using
the Inquiry API.
o Example: A healthcare application queries the registry to find medical
imaging services.
5. Integrate with Services:
o Service Interaction: Once discovered, interact with the services using their
provided access points and WSDLs.
Example Implementation:
1. Deploying jUDDI:
o Install the jUDDI server on your application server.
o Configure the server to handle service requests and manage service data.
2. Publishing a Weather Service:
o Use the jUDDI web interface or APIs to create a new business entity and
service entry.
o Upload WSDL files and provide service details.
3. Querying for Services:
o Develop a client application to query the jUDDI registry for weather-related
services.
o Use the retrieved WSDL to interact with the chosen service.
Summary
• UDDI Architecture: Defines the roles of UDDI registries, including publishing and
querying services.
• UDDI Data Model: Outlines the data elements like Business Entity, Business
Service, Binding Template, and Publisher Assertion.
• UDDI Interfaces: Include Inquiry API and Publishing API for searching and
registering services.
• UDDI Implementation: Involves setting up a UDDI registry, publishing services,
discovering services, and integrating them into applications.
UDDI provides a structured approach to managing and discovering web services, facilitating
interoperability and integration across diverse systems and organizations.