The document discusses protocols, services, and APIs in grid and web service architectures. It focuses on WSDL, SOAP, UDDI, and other common standards and describes what each standard defines and how they relate to each other at different levels of a service-oriented architecture. For example, it notes that WSDL defines the interfaces and endpoints of web services, SOAP defines an XML messaging protocol, and UDDI allows services to be published and discovered.

1. Prof. Neeraj Bhargava
Pooja Dixit
Department of Computer Science
School of Engineering & System Sciences
MDS, University Ajmer, Rajasthan, India
1

2. A protocol-oriented view of a grid architecture
emphasizes the following :
 Development of grid protocols and services
◦ Protocol-mediated access to remote resources
◦ New services, for example, resource brokering
◦ Mostly (extensions to) existing protocols
 Development of grid APIs and SDKs
◦ Interfaces to grid protocols and services
◦ Facilitate application development by supplying higher-
level abstractions
 The model is the Internet, which has been hugely
successful
 A well-defined protocol provides a clearly defined
service; a well-defined service can be supported by
a clearly defined protocol. Protocols, services,
APIs, and SDKs will, ideally, be largely self-
contained.
2

3. 3

4. Protocols, services, and APIs occur at each level.
4

5.  WSDL is a language that provides a way of
describing the specific interfaces of Web services
and APIs.
 Practically, WSDL can be perceived as a document
written in XML.
 The WSDL document describes a Web service; it
specifies the location of the service and the
operations (or methods) the service exposes.
 In other words, it is an XML language for
describing the syntax of Web service interfaces
and their locations.
 The WSDL specification calls it “an XML format for
describing network services as a set of endpoints
operating on messages containing either
document-oriented or procedure-oriented
information.”
5

6. A WSDL document has a definitions element that contains the types,
message, portType, binding, and service elements as described in the
table above.
The main structure of a WSDL document looks like this:
6

7. <definitions>
<types>
definition of types . . .
</types>
<message>
definition of a message . . .
</message>
<portType>
definition of a port . . .
</portType>
<binding>
definition of a binding . . .
</binding>
</definitions>
7

8.  WSDL Services. A service definition element supports the following
attributes (it defines one or more services):
◦ Name is optional.
◦ targetNamespace is the logical namespace for information about this service.
◦ WSDL documents can import other WSDL documents, and setting target-
◦ Namespace to a unique value ensures that the namespaces do not clash.
◦ xmlns is the default namespace of the WSDL document, and it is set to
◦ http://schemas.xmlsoap.org/wsdl/. All the WSDL elements such as
<definitions>,
◦ <types> and <message> reside in this namespace.
◦ xmlns:xsd and xmlns:soap are standard namespace definitions that are used
◦ for specifying SOAP-specific information as well as data types.
◦ xmlns:tns stands for this namespace.
 WSDL Ports. The <portType> element is the most important WSDL element. It defines
a Web service, the operations that can be performed, and the messages that are
involved. The <portType> element can be compared to a function library (or a module
or class) in a traditional programming language.
8

9.  WSDL Messages. The <message> element defines the data elements of an
operation. Each message can consist of one or more parts. The parts can
be compared to the parameters of a function call in a traditional
programming language.
 WSDL Types. The <types> element defines the data type that are used by
the Web service. For maximum platform neutrality, WSDL uses XML
Schema syntax to define data types.
 WSDL Bindings. Binding is an operation that occurs when the service
requestor invokes or initiates an interaction with the service at runtime,
using the binding details in the service description to locate, contact, and
invoke the service . The <binding> element defines the message format
and protocol details for each port.
 WSDL Example. Below is a simplified fraction of a WSDL document. In this
example the “portType” element defines “glossaryTerms” as the name of a
“port,” and “getTerm” as the name of an “operation.” The “getTerm”
operation has an “input message” called “getTermRequest” and an “output
message” called “get- TermResponse.” The “message” elements define the
“parts” of each message and the associated data types. Compared to
traditional programming, “glossaryTerms” is a function library, “getTerm”
is a function with “getTermRequest” as the input parameter, and
“getTermResponse” as the return parameter.
9

10. <message name=“getTermRequest”>
<part name=“term” type=“xs:string”/>
</message>
<message name=“getTermResponse”>
<part name=“value” type=“xs:string”/>
</message>
<portType name=“glossaryTerms”>
<operation name=“getTerm”>
<input message=“getTermRequest”/>
<output message=“getTermResponse”/>
</operation>
</portType>
10

11.  Web Services Inspection Language (WSIL). WSIL is a
simple, lightweight mechanism for Web service
discovery. WSIL is an XML document format designed
to facilitate the discovery and aggregation of Web
service descriptions in a simple and extensible
fashion.
 WSIL provides an XML format for assisting in the
inspection of a site for available services and a set of
rules for how inspection-related information should be
made available for consumption.
 A WISL document provides a means for aggregating
references to preexisting service-description documents
that have been authored in any number of formats.
 These inspection documents are then made available at
the point of offering for the service as well as through
references that may be placed within a content medium
such as HTML.
11

12.  UDDI is a standard Web service description format and Web service
discovery protocol.
 A UDDI registry can contain metadata for any type of service, with “best
practices” already defined for services described by WSDL. By organizing
Web services into groups associated with categories or business processes,
UDDI allows more efficient search and discovery of Web services.
 The UDDI specification defines a four tier hierarchical XML schema that
provides a model for publishing, validating, and invoking information about
Web services.
 UDDI uses standards-based technologies, such as common Internet
protocols (TCP/IP and HTTP), XML, and SOAP.
 There are two types of UDDI :
◦ registries: public UDDI registries that serve as aggregation points for a variety of
businesses to publish their services,
◦ and private UDDI registries that serve a similar role within organizations.
A UDDI registry consists of the following data structure types:
 businessEntity:The top-level XML element in a business UDDI entry.
businessEntity captures the data partners require to find information
about a business service, including its name, industry or product category,
geographic location,and optional categorization and contact information. It
includes support for “yellow pages” taxonomies to search for businesses by
industry, product, or geography.
12

13.  businessService: The logical child of a businessEntity data
structure as well as the logical parent of a bindingTemplate
structure. businessService contains descriptive business
service information about a group of related technical
services, including the group name, a brief description,
technical service description information, and category
information.
 bindingTemplate. The logical child of a businessService
data structure. bindingTemplate contains data that is
relevant for applications that need to in- voke or bind to a
specific Web service. This information includes the Web
service URL and other information describing hosted
services, routing and load balancing facilities, and
references to interface specifications.
 tModel. Descriptions of specifications for Web services or
taxonomies that form the basis for technical fingerprints.
tModel’s role is to represent the technical specification of
the Web service, making it easier for Web service consumers
to find Web services that are compatible with a particular
technical specification.
13

14.  Simple Object Access Protocol (SOAP). SOAP is a
lightweight, XML-based protocol for exchanging
information in a decentralized, distributed environment.
 SOAP supports different styles of information exchange,
including:
◦ Information exchange modeled after the Remote Procedure Call.
This type of exchange allows for request–response processing, in
which an endpoint receives a procedure-oriented message and
replies with a correlated response message.
◦ Information exchange modeled on a message-oriented mechanism.
This type of exchange supports organizations and applications that
need to exchange business or other types of documents; a message
is sent but the sender may not expect or wait for an immediate
response.
 SOAP has the following features:
◦ Protocol independence
◦ Language independence
◦ Platform and operating system independence
◦ Support for SOAP XML messages incorporating attachments
(using the multipart MIME structure)
14

15.  A SOAP message consists of
◦ (i) a SOAP envelope that encloses two data structures,
◦ (ii) the SOAP header and the SOAP body
◦ (iii) information about the namespaces used to define them. The header is optional;
when present, it conveys information about the request defined in the SOAP body.
 For example, it might contain transactional, security, contextual, or user profile
information. The body contains a Web service request or reply to a request in XML format.
 The specification describes the structure and data types of message
payloads using XML schema. The way that SOAP is used for the
message and response of a Web service is:
◦ The SOAP client uses an XML document that conforms to the SOAP
specification and that contains a request for the service.
◦ The SOAP client sends the document to a SOAP server, and the
SOAP servlet running on the server handles the document using,
for example, HTTP or HTTPS.
◦ The Web service receives the SOAP message, and dispatches the
message as a service invocation to the application providing the
requested service.
◦ A response from the service is returned to the SOAP server, again using
the SOAP protocol, and this message is returned to the originating
SOAP client.
15