The document discusses UDDI (Universal Description, Discovery and Integration), which is an XML-based standard for describing, publishing, and finding web services. It provides a high-level overview of UDDI, including that it allows for a distributed registry of web services and uses WSDL to describe web service interfaces. It also discusses the UDDI Business Registry, major components of the UDDI specification, core UDDI data structures like business entities and technical models, and how applications can programmatically access and search UDDI registries.

1. SUBMITTED BY:
S.N.SWETHA

2. UDDI:
 UDDI is an XML-based standard for describing, publishing, and
finding web services.
 UDDI stands for Universal Description, Discovery, and Integration.
 UDDI is a specification for a distributed registry of web services.
 UDDI is a platform-independent, open framework.
 UDDI can communicate via SOAP, CORBA, Java RMI Protocol.
 UDDI uses Web Service Definition Language(WSDL) to describe
interfaces to web services.
 UDDI is seen with SOAP and WSDL as one of the three foundation
standards of web services.
 UDDI is an open industry initiative, enabling businesses to discover
each other and define how they interact over the Internet.

3. The UDDI Business Registry:
 The UDDI Business Registry (UBR) is a global implementation of the
UDDI specification. The UBR is a single registry for Web services. A
group of companies operate and host UBR nodes, each of which is an
identical copy of all other nodes. New entries or updates are entered
into a single node, but are propagated to all other nodes.
 The UBR is a key element of the deployment of Web
services and provides the following capabilities:
 A centralized registration facility at which to publish and
make others aware of the Web services a company makes
available.
 A centralized search facility at which companies that
require a particular service can locate businesses that
provide that service as well as relevant information about
that service.

4. The various means of accessing an UDDI registry.

5. UDDI Under the Covers:
 In the remainder of this chapter, we discuss how to add entries to a
UDDI registry as well as how to search for available services and
build applications that consume those services. We will also briefly
touch on the major sections of the UDDI specification.
The UDDI Specification:
 Version 3 is the most recent incarnation of the UDDI specification.
Version 3 builds on and expands the foundations laid by versions 1
and 2 of the UDDI specification, and presents a blueprint for flexible
and interoperable Web services registries. Version 3 also includes a
rich set of enhancements as well as additional features, including
improved security and new APIs. The entire UDDI specification can
be found at http://www.uddi.org.

6. The major documents of the UDDI Specification version
3.
UDDI Version 3
Specification
Documents
Synopsis
Features List Brief overview of the key features in version 3.
Specification The actual specification document.
XML Schemas A set of XML Schema files that formally describe
UDDI data structures.
WSDL Service
Interface
Descriptions
A set of files that describe the UDDI Version 3
WSDL interface definitions.

7. UDDI Core Data Structures:
 Information representation within UDDI consists of instances of
persistent data structures that are expressed in XML. It is these data
structures that are persistently stored and managed by UDDI nodes.
The different entity types defined by the UDDI Information
Model.
Entity Type
Name
Description
Business Entity A business that provides a Web service.
Business Service A collection of related services offered by a business.
Binding Template Technical information about a particular Web service.
T Model Technical model information about a Web service that is used to
determine whether a service is compatible with the client's needs.

8. The interrelationship between the UDDI core data structures:

9. Accessing UDDI:
 UDDI is itself a Web service and as such, applications can
communicate with an UDDI registry by sending and receiving
XML messages. This makes the access both language and
platform independent.
 Although it's possible, it is unlikely that programmers will deal
with the low-level details of sending and receiving XML
messages. Instead, client-side packages for different languages
and platforms will emerge that facilitate programmatic access to
UDDI.
 Two such packages are UDDI4J and Microsoft's UDDI SDK,
which are client-side APIs for communicating with UDDI from
Java and . Net programs, respectively. UDDI4J was originally
developed by IBM and released in early 2001 as an open source
initiative.

10. How UDDI Is Playing Out convertions overview:
 Now that we have an understanding of the need that UDDI aims
to fill, some of the core data structures of UDDI, as well as the
variety of the means of communicating with an UDDI registry,
it's worth taking a step back to see how UDDI is really playing
out. How UDDI will truly be used by companies will determine
how, when, where, and why businesses will register their Web
services.
 Up until now our discussion of UDDI has focused on its
analogous behavior with standard telephone directory books:
UDDI provides a listing of businesses and the services each
business offers as well as a means of searching and discovering
Web services to use within consuming applications. Since this
usage of UDDI is during the design of applications, it can be
referred to as the design-time use.

11. WEB SERVICES:
 The term Web service (WS) is either:
 a service offered by an electronic device to another electronic
device, communicating with each other via the World Wide
Web, or
 a server running on a computer device, listening for requests at
a particular port over a network, serving web documents
(HTML, JSON, XML, images), and creating web applications
services, which serve in solving specific domain problems
over the Web (WWW, Internet, HTTP)
 In a Web service a Web technology such as HTTP —
originally designed for human-to-machine communication is
used for transferring machine-readable file formats such
as XML and JSON.

12. Web Services Conversation Language:
 The Web Service Conversation Language (WSCL) proposal
defines the overall input and output message sequences for one web
service using a finite state automation FSA over the alphabet of
message types.
 External links[edit]
 Web Service Conversation Language (WSCL) proposal.
WSCL interface components:
 A WSCL interface is both complimentary and similar in spirit to its
associated WSDL description. Like WSDL, a WSCL interface starts
off simple and gradually builds up its description stage by stage
until a whole conversation pattern is formed, ready for
consumption on the Web. Our discussion on WSCL will
follow the same pattern. Using the bar scenario as our example, we
will start at the abstract sections of the WSCL interface and work
our way through to a full-fledged conversation.

13. Interactions:
 An interaction with a conversational Web service is modeled as
an XML document exchange whose flow is seen from the point
of view of the service being invoked. WSCL supports four
distinct message exchange patterns.
 Send The service creates a one-way message that is sent to the
consumer and expects no correlated response from that
consumer.
 Receive The service expects to receive a message from the
consumer, while the consumer expects no message back in
return.
 Send Receive The service initiates a bilateral message exchange
with the consumer, for which it expects a correlated response.
 Receive Send The service expects to receive a message from the
consumer to which it will respond.

14. The bar scenario conversations:
 At this point we are ready to tackle an entire WSCL interface.
Accordingly, the bar conversation is presented in full .
 We've already covered all of WSCL, so the interface shown in doesn't
hold any significant surprises. However, there are a number of
elements whose function is interesting, particularly
those Interaction elements that have multiple possible Out bound
XML Messages and the corresponding Transition elements which
possess a Source Interaction Condition. Take for example the billing
aspect of the conversation, which involves the following interactions:

16. Relationship between WSCL and WSDL workflow:
The three main aspects of a Web service's interface are:
o Abstract interfaces: The application payload (in the form of
messages) being exchanged and the order in which they are
exchanged (which is known as choreography).
o Protocol bindings: The protocols used to enable the sending and
receipt of messages.
o Services: The concrete service implementation that provides a
network accessible address for a particular protocol at which the given
message set is understood i.e., the location of an instance of the Web
service.
 If we reflect on our experience with WSCL and our previous
experience with WSDL, then it is clear (as we might expect from two
technologies that are both Web service interface languages) that there
is some overlap.

17. WSDL and WSDL Complimentary Features:
Aspect Function WSDL WSCL
Abstract Interfaces Choreography N/A Transition
Messages Operation Interaction
Protocol Bindings Binding N/A
Concrete Services Service N/A

18. Business Process Management:
 The business process engine enables you to easily create a graphical
representation of your business process, allowing you to focus on
the application logic rather than on implementation details. You
create a graph of component nodes in your business process by
dragging components from the Business Process Palette and
dropping them onto the Design View pane. Program control is
represented visually by these nodes (or shapes) and the connections
between them. Effectively, you create a graphical representation of
your business process and its interactions with clients and resources,
such as databases, JMS queues, file systems, and other components.
The following figure provides an example of the visual business
process editor.
 As you build a business process, Web Logic Workshop writes source
code to a business process file (a JPD file).
 For more information on building business processes, see Guide to
Building Business Processes in Building Integrated Applications in
the Web Logic Workshop Help.

19. Business Process Management diagram

20. Workflows and Workflow Management Systems:
 Web technology is seen as a means by which a business can
achieve agility and competitiveness. Although information
technology has numerous beneficial effects on a typical
enterprise, perhaps the most potent means of applying
information technology is to use it to directly manage business
processes through workflow management systems.
 A workflow management system provides the business analyst
with a view of the processes that the business currently operates,
and allows the analyst to manage those processes according to
the enterprise's business direction and changing market
conditions. Under the covers, the workflow system is a
dependable (and usually distributed) computing system that
ensures.

21. Business Process Execution Language:
 The Web Services Business Process Execution
Language (WS-BPEL), commonly known as BPEL (Business
Process Execution Language), is an standard executable
language for specifying actions within business
processes with web services. Processes in BPEL export and
import information by using web service interfaces exclusively.
The BPEL language:
 BPEL is an orchestration language, and not a choreography language.
The primary difference between orchestration and choreography is
exe cutability and control. An orchestration specifies an executable
process that involves message exchanges with other systems, such
that the message exchange sequences are controlled by the
orchestration designer. A choreography specifies a protocol for peer-
to-peer interactions, defining, e.g., the legal sequences of messages
exchanged with the purpose of guaranteeing interoperability. Such a
protocol is not directly executable, as it allows many different
realizations (processes that comply with it).

22.  In addition to providing facilities to enable sending and receiving
messages, the BPEL programming language also supports:
 A property-based message correlation mechanism
 XML and WSDL typed variables
 An extensible language plug-in model to allow writing expressions
and queries in multiple languages: BPEL supports XPath 1.0 by
default
 Structured-programming constructs including if-then-elseif-else,
while, sequence (to enable executing commands in order) and flow (to
enable executing commands in parallel)
 A scoping system to allow the encapsulation of logic with local
variables, fault-handlers, compensation-handlers and event-handlers
 Serialized scopes to control concurrent access to variables.

23. Thank you