Unit-4

Universal Description, Discovery and

Integration (UDDI)
&
Remote Procedure Call and Messaging (RPC)
Table of Content
●
Introduction to UDDI
➢
What is UDDI?
➢
UDDI Nomenclature
➢
Core UDDI
➢
Service Publication & Discovery
●
Introduction to RPC
●
What is RPC
●
Synchronous Web Services
●
Asynchronous Web Services
●
RPC or Messaging
2
Introduction to UDDI
●
Service brokers Play one of the key role in the web services. It enables both, the
service provider and the service requested to identify each other. The broker
brings both the provider and requester to the same platform.
●
The broker is essentially a registry application that enables storing and retrieving
business related information in a specific format, based on a given taxonomy
Information. Both the provider and requester use applications to communicate
with the registry.
●
UDDI Is a specification that helps providers in registering their service, and
thereby advertise the product as well as service information. Likewise UDDI
service He requested to find the services and all the related details.
●
Provider could be using a software tool that conforms to the specifications for
publishing and Updating business and service related information in the
registry. On the other hand, Requester could be using a software tool or
integrated development environment or browser or queries and obtain required
business and services related information.

3
History of UDDI
●
UDDI 1.0 was originally announced by Microsoft, IBM, and Ariba in
September 2000.
●
Since the initial announcement, the UDDI initiative has grown to include
more than 300 companies including Dell, Fujitsu, HP, Hitachi, IBM,
Intel, Microsoft, Oracle, SAP, and Sun.
●
In May 2001, Microsoft and IBM launched the first UDDI operator sites
and turned the UDDI registry live.
●
In June 2001, UDDI announced Version 2.0.
●
As the time of writing this tutorial, Microsoft and IBM sites had
implemented the 1.0 specification and were planning 2.0 support in the
near future.
●
Currently UDDI is sponsored by OASIS.

4
Introduction to UDDI

UDDI has two sections −

A registry of all web service's metadata,

including a pointer to the WSDL description of a
service.

A set of WSDL port type definitions for

manipulating and searching that registry.

5
 What is UDDI ?
Universal description, discovery and integration is a
certification that is designed to manage business and
services related information. Organisations and
enterprises based on the specifications will be able to
store modify, update, share and exploit key business and
services information among the partners, collaborators
and other related business organisations.
 UDDI ElEMENTS
A business or a company can register three types of information into a UDDI registry.
This information is contained in three elements of UDDI.
These three elements are −
●
White Pages,
●
Yellow Pages, and
●
Green Pages.

White Pages
White pages contain −
Basic information about the company and its business.
Basic contact information including business name, address, contact phone
number, etc.
A Unique identifiers for the company tax IDs. This information allows others to
discover your web service based upon your business identification.
 UDDI ElEMENTS
Yellow Pages

Yellow pages contain more details about the company. They include descriptions of the kind
of electronic capabilities the company can offer to anyone who wants to do business with it.
Yellow pages uses commonly accepted industrial categorization schemes, industry codes,
product codes, business identification codes and the like to make it easier for companies to
search through the listings and find exactly what they want.

Green Pages
Green pages contains technical information about a web service. A green page allows
someone to bind to a Web service after it's been found.
It includes −
●
The various interfaces
●
The URL locations
●
Discovery information and similar data required to find and run the Web service.

NOTE − UDDI is not restricted to describing web services based on SOAP. Rather,
UDDI can be used to describe any service, from a single webpage or email address all
the way up to SOAP, CORBA, and Java RMI services.
SPECIFICATIONS AND SERVICES
●
The UDDI services are designed based on the UDDI specifications. UDDI
services helps companies to store, share and exploit business and services
information. UDDI specifications helps companies to create applications
that aid in storing, modify, sharing and exploring business information,
thereby helping companies progress towards business automation.
●
UDDI Browser Registries(UBR) are global, public, online directories.
These UBRs offer services to business for publishing the company data as
well as the services related data for public and global use.
●
The specification is the result of an Industry driven initiative. Many major
industry leaders such as Arriba, IBM, Merrill lynch And Microsoft are
involved in establishing the UDDI specifications
 PUBLIC AND PRIVATE REGISTRIES
●
Many leading organizations have already set up and are offering registry
services. The public registries that are in conformance to UDDI
Specifications are set up by the organisations such as IBM, Microsoft etc.
●
A few of them have also set up a registry that enable professionals to gain
valuable experience in working with such registry.Private business registry
are also available.However the specifications of the private registration
may not be in full conformance with the UDDI specifications.
●
UDDI specifications also outlines a set of XML schema definition that
describes the data type to be used for representing business data. This
allows the business to Query for services related information.
UDDI Nomenclature

The UDDI Specifications, uses some specific terminology which that need
to be understood before exploring the details.

They are :
● Node API Sets
● UDDI Nodes
● UDDI Registry
● Information Model
● Data Structure
Node API Sets
These are the APIs that are used for inter-UDDI communications and
the implementation.
The purpose is to manipulate the data stored in different UDDI
implementations.
The Node API sets are available for Implementing of variety of tasks
such as
● UDDI enquiry
● UDD and publication
● UDDI subscription
● UDDI security.
 UDDI Nodes
A system that host an application to support at least one of the
node APIs set is called a UDDI Node.
UDDI Node must ensure the following:
1. Interaction with the UDDI Data through API set
2. Membership with exactly one registry
3. Ability to access and manipulate the UDDI data.
UDDI Registries
One or more UDDI nodes May be combined to form of UDDI registry. These
UDDI nodes are designed to collectively manage the business data in the registry.
The UDDI registry architecture Is shown in the figure.
 DATA STRUCTURE
This forms one of the most important part of UDDI specifications. The UDDI data
structure is the XML representation of the assistant business data within the UDDI
nodes.
The UDDI Specifications re-presents data in six different type of data structures
these data structures are referred to as entities.
They are:
● Business Entity
● Business Services
● Binding Templates
● tModel
● Publisher Assertion
● Subscription
These data structures represent the core of the UDDI information model.
Information Model
The information model of UDDI is composed of instances of “persistent”
data structures called “entities” . The UDDI specification defines an
abstraction and representation of entities, their properties and attributes
and their inter-relationships. In essence, the information Model represents
data and behavior of API set that query and Manage the data transport.
CORE UDDI
Six different data structures mark up the information in a definite way.

They are :
● Business Entity
● Business Services
● Binding Template
● Tmodel
● Publisher Assertion
● Subscription.

At the very basic level we present the XML elements that are associated
with UDDI related name space
Business Entity

The business entity structure

represents the provider of web
services. Within the UDDI
registry, this structure contains
information about the company
itself, including contact
information, industry categories,
business identifiers, and a list of
services provided.
Business Entity
Business Service
The business service structure
represents an individual web
service provided by the business
entity. Its description includes
information on how to bind to the
web service, what type of web
service it is, and what taxonomical
categories it belongs to.
 Business Service
Here is an example of a business service structure for the Hello World web
service.

Notice: the use of the Universally Unique Identifiers (UUIDs) in the business

Key and service Key attributes. Every business entity and business service is uniquely
identified in all the UDDI registries through the UUID assigned by the registry when the
information is first entered.
Binding Template

●
Binding templates are the technical
descriptions of the web services
represented by the business service
structure. A single business service may
have multiple binding templates. The
binding template represents the actual
implementation of the web service.
●
As a business service may have
multiple binding templates, the service
may specify different implementations
of the same service, each bound to a
different set of protocols or a different
network address.
 Binding Template
Here is an example of a binding template for Hello World.
<bindingTemplate serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
bindingKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
<description>Hello World SOAP Binding</description>
<accessPoint URLType = "http">http://localhost:8080</accessPoint>

<tModelInstanceDetails>
<tModelInstanceInfo tModelKey = "uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
<instanceDetails>
<overviewDoc>
<description>
references the description of the WSDL service definition
</description>

<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
 tModel
●
tModel is the last core data type, but
potentially the most difficult to grasp.
tModel stands for technical model.
●
tModel is a way of describing the various
business, service, and template structures
stored within the UDDI registry. Any
abstract concept can be registered within
the UDDI as a tModel. For instance, if you
define a new WSDL port type, you can
define a tModel that represents that port
type within the UDDI. Then, you can
specify that a given business service
implements that port type by associating
the tModel with one of that business
service's binding templates.
 tModel
Here is an example of a tModel representing the Hello World Interface port type.
<tModel tModelKey = "uuid:xyz987..." operator =
"http://www.ibm.com" authorizedName = "John Doe">
<name>HelloWorldInterface Port Type</name>
<description>
An interface for a friendly Web service
</description>

<overviewDoc>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</tModel>
Remote Procedure Call and Messaging
 Introduction
●
The constituent of webservice namely, SOAP, WSDL and UDDI
provide a basic Framework that can help in establishing
communication among the interconnected applications.
●
Interchange of information in the form of SOAP message ammong
the communicating applications is considered an important part of
web services.
●
The information interchange through SOAP between two or more
communicating applications can be realized either synchronously
or asynchronously.
●
This part will present the details of the two approaches and
compare the two with regard to Webservice.
 What is RPC?
●
Remote Procedure Call (RPC) is a powerful
technique for constructing distributed, client-
server based applications.
●
It is based on extending the conventional local
procedure calling so that the called procedure
need not exist in the same address space as the
calling procedure.
●
The two processes may be on the same system, or
they may be on different systems with a network
connecting them.
●
NOTE: RPC is especially well suited for client-
server (e.g. query-response) interaction in which
the flow of control alternates between the caller
and callee. Conceptually, the client and server do
not both execute at the same time. Instead, the
thread of execution jumps from the caller to the
callee and then back again.
Working of RPC
The following steps take place during a
RPC:
1. A client invokes a client stub procedure,
passing parameters in the usual way. The
client stub resides within the client’s own
address space.
2. The client stub marshalls(pack) the
parameters into a message. Marshalling
includes converting the representation of
the parameters into a standard format, and
copying each parameter into the message.
3. The client stub passes the message to the
transport layer, which sends it to the remote
server machine.
Working of RPC
4. On the server, the transport layer passes the
message to a server stub,
which demarshalls(unpack) the parameters and calls
the desired server routine using the regular
procedure call mechanism.
5. When the server procedure completes, it returns to
the server stub (e.g., via a normal procedure call
return), which marshalls the return values into a
message. The server stub then hands the message to
the transport layer.
6. The transport layer sends the result message back
to the client transport layer, which hands the
message back to the client stub.
7. The client stub demarshalls the return parameters
and execution returns to the caller.
Synchronous Web Service
●
Synchronous communication means a real-time two-way
communication without any time delay which both parties
involved In the communication being present and acting upon
those messages exchanged immediately.
●
A consequence of this is that a sender of a message is blocked
until a responses received from the other end.
●
Depending on whether the client or the server component
initiate the message,synchronous communication can be of two
types. They are:
●
Request-Response
●
Solicit-response
Synchronous Web Service
Request-Response: In this style, the client application initiates
a “request “ to an application on the server, and wait for a
Response.
The client is blocked on the responses received from the
service. Client/Server, distributed applications and RPC As a
best example of this category.

Solicit-Response: in this type, research or application

“Solicits” a “response” from the client application. As against
request response child, the server initiates the communication
and await a response from the client.
 RPC Basics
●
The term "Procedure Call" is referred to the invocation of a function / method / procedure
during the runtime environment of a local system. This term is used in the conventional
software development.
"Remote Procedure Call', also referred to as "RPC", is a term that describes invocation of a
●

method/function / procedure on a "remote" system.

●
RPC is neither a specification nor a standard. It is just a technique that is proposed to make
remote applications communicate. When a program, at run time, initiates a
procedure/function call, the call adheres to certain predefined semantics.
●
The call is initiated by the client and involves the use of the procedure/ function name of an
application on the server along with the parameters that are needed by the function.
●
The client application is referred to as the "caller" and the server application as "callee". In
the standalone environment, both the caller and callee reside on the same system. For the
local procedure invocation scenario, the client knows the exact memory address of the
function, which is being called. The parmeters required by the procedure may also be passed
via their addresses. This is called as “pass by reference”.
RPC Basics
●
In a Remote Procedure Call, the client and server reside on different systems, and
the two may be connected in a LAN/WAN, or even on the Internet. The caller
requires the knowledge of the remote address, protocol for communication,etc. for
involdng this procedure. Additionally, the parameters that are being passed to the
procedure and the result that is to be received from the procedure need to be
physically transported between the two systems.
●
In order that this can be realized, a proper "communication infrastructure" needs to
be in place. This infrastructure must be available at the server-side as well as the
client-side. It is the responsibility of the communication infrastructure to ensure
that the client and server participate in the communication between the two.
●
In RPC, two parts provide the communication infrastructure: Stub and
Skeleton (Tie).
●
The stub is also called as a proxy, as the function of the stub is similar to that of a
proxy in conventional terms. The stub constitutes the communication
infrastructure at the client end.
 RPC Basics
●
The skeleton does communication at the server end. Application tools typically generate the
stub and skeleton at the time of deployment of remote applications.
●
The stub is accessible to the client application and the skeleton is accessible to the server
application.Similarly, the server's response goes through the skeleton, stub and then to the
client.
●
When the procedure requires one or more parameters, unlike in the case of a standalone
system, the parameters need to be "passed by value". This requires that the parameters
needs to be converted to the format understood by the communication infrastructure. This
process is called marshalling. Similarly, converting them back to the application-required
format is called unmarshalling.
●
Thus, when the caller passes any parameters to the procedure, the stub performs marshalling
on these parameters for further processing. When the call reaches the skeleton (along with
the marshalled parameters), these parameters are unmarshalled by the skeleton and passed on
to the procedure on the server application.
●
Likewise, the results are marshalled by the skeleton and sent across to the stub. At the client
side, these results are unmarshalled back to their original values and then passed on to the
client application.
RPC Basics
●
The most attractive part of the RPC is that it unshackles the developer from
coding the infrastructure part of the remote Communication. The client program
makes a call to the server application as if it were executing in the same address
space. That is, the remote call happens transparently to the client.
●
The call return process executes transparently on the server side too. The
developer, thus depends on the stubs and skeleton for achieving the necessary
communication, without being aware of it or being impacted by it.
●
Software tools and IDEs eidst that help the developer in generating the stubs
and skeletons.
●
This is usually done at the time of compiling the server application. RPC is a
tightly-coupled synchronous technology. Tight coupling indicates that the client
and server should know about each other and they should be running at the
same time when the call is made.
RPC Basics
●
The figure besides is a detailed representation
of the RPC call between a client and a server
in a distributed environment.
●
The environment chosen to explain this
concept is essentially RPC environment. In this
environment, the client makes a local call on
the proxy/stub.
●
The stub in turn, takes over the rest of the call
responsibilities, including marshalling/un-
marshalling of the parameters, and protocol.
●
In order to help the client and server do this,
two additional layers help in carrying out the
call. They are: Remote Reference
Layer(RRL) and Transport Layer (TL).
Stub and skeleton take care of the semantlcs of
call invocation on the cllent side respectively
SOAP based RPC
●
The client and the server, in this mode of communication, essentially need to
communicate using SOAP. This necessitates that client well as the server
applications are supported with SOAP processors.
●
These processors use appropriate APIs that conform to the SOAP specification.
Additionally, these processors need to be capable of supporting the "skeleton"
(or "ties")/"stubs" (or "proldes").
●
Most of the software tools and IDEs generate stubs and skeletons. The
skeletons and stubs are generated during the development or deployment of the
server application.
●
The stubs are required by the client applications for achieving the remote
procedure call. In order to enable this, stubs are downloaded to machines that
run the clients.
 SOAP based RPC
●
The client application that participates in the RPC is a "Static
client" or Dynamic client". If the client application uses an already
downloaded stub (or downloads the stub at runtime), then it is called
a "Static Client".The stubs are generated at the server side. Static
clients are most useful when the server side function invocation is
generally non-dynamic in nature.
●
Dynamic clients, on the other hand, are capable of generating the
client-required stubs at the run time in their local environment.
●
In the web services parlance, the clients are capable of understanding
the WSDL that is published on the server side to understand the call
semantics. Software tools are available that are capable of generating
the stubs required at run time and enable the clients to adapt to the
dynamic situation. Such clients are termed as dynamic clients.
 SOAP based RPC
●
A simplified picture of SOAP-
enabled RPC mechanism is shown in
the figure
●
It is important to note here that in
this form of RPC, there ia an
additional layer that take care of
SOAP communication between
Server application as well as the
client application.
●
Both client and server communicate
using SOAP through communication
Infrastructure.
●
The studb takes care of the remaining
part of communication requirements.
Asynchronous Web Services
●
Asynchronous communication, can take place between two or
more applications irrespective of whether the applications are
running at the same time.
●
This is a powerful mode of communication that can help in
bridging many different applications, running on incompatible
operating environments to exchange information.
●
Messaging technology uses asynchronous communication for
exchanging information.
●
Messaging middleware (or Messaging Oriented Middleware),
which uses asynchronous communication at the core, is one of the
architectures that helps in bringing about business integration
among a wide variety of systems, applications and environments.
Messaging Basics
Messaging means sending or receiving of a message, or a piece of data between
two or more
applications connected in a distributed architecture. The message that is being
exchanged could be
For a business-to-business scenario, messaging is considered as an important
textual or non-textual. For a Business – to – Bussiness scenario, messaging is
considered as an important infrastructural tier.
Messaging is often referred to as "loosely coupled" middleware. By allowing
"loose coupling", client and server need not be aware of any information about
each other and they need not be connected to each other at the same time. This is
the most important aspect of messaging. The message from the sender is
received by a messaging system that will assume the responsibility of "queuing
up” the message and ensure that the message is delivered to the recipient at a later
time. This is called as asynchronous messaging.
Messaging Basics
●
It actually means that when the message is sent to another system, the sender will not
wait for an acknowledgement or response.
●
It may receive an acknowledgement and/or response from the target application at a
later time - the sender may actually receive a response from the middleware - like the
fault response if the middleware is non-functional.
●
The only thing that is expected out of messaging middleware is hat the recipient of the
message understands the format of the message as well as the message itself properly.
●
The messaging technology has been one of the strong pillar of e-business since the
introduction of this technology
●
The strength of messaging technology arises from its ability to interconnect
applications developed on disparate systems, running disparate operating
environments.
●
The strength of messaging particularly stems out of the fact that the communicating
applications need not be always in synchronization with the other systems,as the
technology is designed on an asynchronous communication model.
Messaging Basics
Messaging semantics are shown in the following Image
Messaging Basics
●
Message Oriented Middleware or MOM is specialized to coordinate the
communication among multiple applications, for sending and receiving messages.
●
MOMs are designed to respond to events, exchange messages in a wide variety
of formats and tuned to deliver the messages quickly and reliably.
Messaging works on two communication models: Synchronous and
●

Asynchronous.
●
For synchronous messaging to be possible, both the communicating partners
must be online, and the calls between them are blocked until the exchange of
message is completed. This type of messaging can be compared with that of
synchronous RPC.
●
In asynchronous communication, the sender and receiver need not be online
simultaneously. The sender can send messages at will and the message gets
delivered to the recipient whenever it gets connected to the system at a later point
of time.
Messaging Model
●
Two messaging models (sometimes referred to as messaging domains) are
prevalent in enterprise application scenarios. They are Point-to-Point, PTP and
Publish/Subscribe (Pub/Sub).
●
Either of the models is capable of providing synchronous or asynchronous
communication.
These models are discussed in the following paragraphs:
●
Point-to-Point: This is a one-on-one message delivery model. In order to
implement this model, a Message Queue is used for enabling the delivery
mechanism.
●
The delivery is to only one intended recipient and PTP ensures the delivery of
the message. However, this model becomes unviable, in case the same message
needs to be delivered to a large number of recipients. Furthermore. the viability
would be reduced drastically if the recipients were not in a fixed number.
Messaging Model
Messaging Model
●
Publish/Subscribe: Model provides an
excellent message delivery model that
is perfectly suited for need wherein
multiple senders are sending messages
to a growing/shrinking set of receivers.
●
Channels are used for publication of
messages and publishers connect to it
whenever required, and publish the
message. In a similar manner,
subscribers subscribe to one or more
channels and receive the published
messages.
 XML/SOAP Messaging
●
Web services that are implemented using the
messaging model work in a similar way as the
classic messaging model, the predominant
difference being that the messages are SOAP
messages. The choice between point-to-point
and Publish/Subscribe depends particularly on
the business requirement, as well as the
technology requirement.
●
Most Frequently Messaging oriented web
services are delivered using a “Provider”
model. A message provider ensures the
delivery of the message to the communicating
partners.
●
Messaging Provider ensures the delivery of
the soap message in an asynchronous fashion.
RPC or Messaging
●
Now that SOAP can be used in synchronous as well as asynchronous modes of
communication,the problem of choosing between them. However, in building an
enterprise solution using web services route, there are several factors that need
to be considered. A careful evaluation of the enterprise requirement may
demand a combination of RPC as well as messaging- based web services.
●
In fact, depending on the requirement, not all services in the enterprise may
need to be realized as web services.
●
Moreover, other non-functional requirements such as security, reliability
extensibility, performance could further influence the choice between RPC and
messaging technologies.
●
Nevertheless, RPC as well as messaging have their own pros and cons that need
to be evaluated in an enterprise situation.