Distributed Systems II CNDS Lecture 2 Course code : CND 412

Service descriptions
and IDL for web
services.
Dr. Ali Haider Shamsan

1
Lecture Outlines

• Service descriptions and IDL for web services.

• Coordination of web services
• Applications of web services

Background Review
• WEB SERVICES
• Communication patterns
• Loose coupling
• Representation of messages
• Service references
• Activation of services
• Transparency
• SOAP
• .
Keywords

Distributed Systems, DS, web services, soap

2
 Service descriptions and IDL for web services
• Interface Definition Language
• Interface definitions are needed to allow clients to communicate with
services.
• For web services, interface definitions are provided as part of a more
general service description, which specifies two other additional
characteristics –
• how the messages are to be communicated and
• the URI of the service.
• To satisfy for use in a multi-language environment, service descriptions
are written in XML.
• A variety of different methods of communication can be used by web
services and their clients.
• Therefore the method of communication is left to be decided by
the service provider and specified in the service description,
3
rather than built into the system.
 Service descriptions and IDL for web services
WSDL
• In the web services context, the Web Services Description Language
(WSDL) is commonly used for service descriptions.
• It defines an XML schema for representing the components of a
service description, which include, for example, the element name
definitions:
• types, messages, interface, bindings, and services.
• WSDL separates the abstract part of a service description from the
concrete part, as shown in Figure 9.10.
• The abstract part of the description includes a set of definitions of
the types used by the service – particularlly,
• the types of values exchanged in messages.

4
Figure 9.10
The main elements in a WSDL description

definitions
types message interface bindings services

target namespace document style request-reply style how where

abstract concrete

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Service descriptions and IDL for web services
WSDL
• The inherent modularity of a WSDL definition allows its components to
be combined in different ways –
• for example, the same interface may be used with different
bindings or locations.
• The types may be defined inside the types element or they may be
defined in a separate document referenced by a URI from the types
element.

6
 Service descriptions and IDL for web services
WSDL
Messages or operations
• In web services, all that the client and the server need is to have
a common idea about the messages to be exchanged.
• For a service based on the exchange of a small number of
different types of documents, WSDL just describes the types
of the different messages to be exchanged.
• When a client sends one of these messages to a web service,
the latter decides what operation to perform and what type of
message to send back to the client based on the message type
received.
• For example, Figure 9.11 shows the request and reply messages
for the newShape operation.

7
Figure 9.11
WSDL request and reply messages for the newShape operation

message name = "ShapeList_newShape" message name = "ShapeList_newShapeResponse"

part name ="GraphicalObject_1" part name= "result"

type = "ns:GraphicalObject " type= "xsd:int"

tns – target namespace xsd – XML schema definitions

 Service descriptions and IDL for web services
WSDL
Interface
• The collection of operations belonging to a web service are grouped
together in an XML element named interface (sometimes called
portType).
• Each operation must specify the message exchange pattern between
client and server.
• The available options include those shown in Figure 9.12 .
• The first one, In-Out, is the commonly used request-reply form of
client-server communication.
• In-Only is for one-way messages with maybe semantics and Out-Only
is for one way messages from server to client;
• Robust In-Only and Robust Out-Only are the corresponding
messages with guaranteed delivery; fault messages may be
exchanged.
9
• Out-In is a request-reply interaction initiated by the server.
Figure 9.12
Message exchange patterns for WSDL operations

Name Messages sent by

Client Server Delivery Fault message

In-Out Request Reply may replace Reply
In-Only Request no fault message
Robust In-Only Request guaranteed may be sent
Out-In Reply Request may replace Reply

Out-Only Request no fault message

Robust Out-Only Request guaranteed may send fault
Figure 9.13
WSDL operation newShape

operation name = "newShape"

pattern = In-Out
input message = tns:ShapeList_newShape

output message ="tns:ShapeList_newShapeResponse"

tns – target namespace xsd – XML schema definitions

The names operation, pattern, input and output are defined in the XML schema for WSDL

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Service descriptions and IDL for web services
WSDL
Concrete part
• The remaining (concrete) part of a WSDL document consists of the
binding (the choice of protocols) and the service (the choice of
endpoint or server address).
• The two are related, since the form of address depends on the type
of protocol in use.
• For example, a SOAP endpoint will use a URI whereas a CORBA
endpoint will use a CORBA-specific object identifier.
.

12
 Service descriptions and IDL for web services
WSDL
Concrete part
• Binding:
✓ The binding section in a WSDL document says which message
formats and form of external data representation are to be used.
✓ For example, web services frequently use SOAP, HTTP and MIME.
✓ Figure 9.14 shows an example of a binding enclosing a
soap:binding that specifies
✓ the URL of a particular protocol for transmitting SOAP envelopes:
the HTTP binding for SOAP.
• Service:
✓ Each service element in a WSDL document specifies the name of
the service and one or more endpoints (or ports) where an
instance of the service may be contacted.
✓ Each of the endpoint elements refers to the name of the binding
13
in
use.
Figure 9.14
SOAP binding and service definitions

binding service
name = ShapeListBinding name = "MyShapeListService"
type = tns:ShapeList
soap:binding transport = URI endpoint
for schemas for soap/http
style= "rpc" name = "ShapeListPort"
binding = "tns:ShapeListBinding"
operation
name= "newShape"
input soap:address
soap:body location = service URI
encoding, namespace

output
soap:body
encoding, namespace

soap:operation the service URI is:

soapAction “http://localhost:8080/ShapeList-jaxrpc/ShapeList”

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Service descriptions and IDL for web services
WSDL
Documentation
• Both human- and machine-readable information may be inserted in a
documentation element at most points within a WSDL document.
• This information may be removed before WSDL is used for automatic
processing, for example, by stub compilers.

15
 Service descriptions and IDL for web services
WSDL
WSDL use
• Complete WSDL documents can be accessed via their URIs by clients
and servers, either directly or indirectly via a directory service such as
UDDI.
• Tools are available for generating WSDL definitions from information
provided via a graphical user interface, removing the need for users to
be involved in the complex details and structure of WSDL.
•
• For example, the Web Services Description Language for Java
Toolkit (WSDL4J) allows the creation, representation and
manipulation of WSDL documents describing services
[wsdl4j.sourceforge.org].

16
 A directory service for use with web services
directory service
There are many ways in which clients can obtain service
descriptions.
• For example, anyone providing a higher-level web
service like the travel agent would almost certainly make a
web page advertising .
• However, any organization that plans to base its
applications on web services will find it more convenient
to use a directory service to make these services
available to clients.
• This is the purpose of the Universal Description,
Discovery and Integration service (UDDI) which provides
both a name service and a directory service.
17
 A directory service for use with web services
directory service
• That is, WSDL service descriptions may be looked up
by name (a white pages service) or by attribute (a
yellow pages service).
• They may also be accessed directly via their URLs,
which is convenient for developers who are
designing client programs that use the service.
• Clients may use the yellow pages approach to look up a
particular category of service, such as travel agent or
bookseller,
• or they may use the white pages approach to look up a
service with reference to the organization that provides
it. 18
 A directory service for use with web services
Data structures
• The data structures supporting UDDI are designed to
allow all the above styles of access and can incorporate
any amount of human-readable information.
• The data is organized in terms of the four structures
shown in Figure 9.15 ,
• each of which can be accessed individually by
means of an identifier called a key (apart from t
Model, which can be accessed by a URL)

19
Figure 9.15
The main UDDI data structures

businessEntity businessServices
human readable businessServices
information
businessServices bindingTemplate
about the publisher
human readable
bindingTemplate
information URL
about a bindingTemplate tModel
family of services information tModel
about the
URL
serviceinterfaces
service interfaces
tModel
key URL
key service descriptions
key
 A directory service for use with web services
Data structures
• businessEntity describes the organization that
provides these web services, giving its name, address
and activities, etc.;
• businessServices stores information about a set of
instances of a web service, such as its name and a
description of its purpose (for example, travel agent or
bookseller);
• bindingTemplate holds the address of a web service
instance and references to service descriptions;
• tModel holds service descriptions, usually WSDL
documents, stored outside the database and accessed
by means of URLs. 21
 A directory service for use with web services
Lookup
• UDDI provides an API for looking up services based on
two sets of query operations:
• The get_xxx set of operations includes
get_BusinessDetail, get_ServiceDetail, get_bindingDetail
and get_tModelDetail; they retrieve an entity
corresponding to a given key.
• The find_xxx set of operations includes find_business,
find_service, find_binding and find_tModel; they retrieve
the set of entities that matches a particular set of search
criteria, providing a summary of names, descriptions,
keys and URLs
22
 A directory service for use with web services
Lookup
• clients in possession of a particular key may use a
get_xxx operation to retrieve the corresponding entity
directly.
• the user may use the find_service operation to narrow
the search by matching the sort of service required.
• In both cases, they will find the key of a suitable
bindingTemplate and thereby find the URL for retrieving
the WSDL document for a suitable service.

23
 A directory service for use with web services
Publication
• UDDI provides an interface for publishing and
updating information about web services.
• The first time that a data structure is published at a
UDDI server,
• it is given a key in the form of a URI – for example,
uddi:cdk5.net:213 – and that server becomes its
owner.

24
 A directory service for use with web services
Registries
• The UDDI service is based on replicated data stored in
registries.
• A UDDI registry consists of one or more UDDI servers,
each of which has a copy of the same set of data.
• The data is replicated between the members of a registry.
• Each of them may respond to queries and publish
information.
• Changes to a data structure must be submitted to its owner
– that is, the server at which it was first published.
• It is possible for an owner to pass on the ownership to
another UDDI server in the same registry.

25
 A directory service for use with web services
Registries
Replication scheme:
• The members of a registry propagate copies of data
structures to one another as follows:
• a server that has made changes notifies the other
servers in the registry, which then request the changes.
• A form of vector timestamp is used to determine which
of the changes should be propagated and applied.
Interaction between servers:
• They can also interact in order to transfer ownership of
data structures.
• However, the response to a lookup operation is made
by a single server without any interaction with other
servers in the registry. 26
 XML security

• XML security consists of a set of related W3C designs for

signing, key management and encryption.
• Typically the documents are created, exchanged, stored
and then exchanged again, possibly after being modified by
a series of different users.
• XML tags can be used to define the properties of the data in
the document.
• In particular, XML security depends on new tags that
can be used to indicate the beginning and end of
sections of encrypted or signed data and of signatures.
• Once the necessary security has been applied within a
document, it may be sent to a variety of different users,
even by means of multicast. 27
 XML security
Basic requirements
• XML security should provide at least the same level of
protection as TLS. That is:
• To be able to encrypt either an entire document or just
some selected parts of it
• transaction,
• To be able to sign either an entire document or just some
selected parts of it.
• used for cooperative work by a group of people

28
 XML security
Additional basic requirements
• Further requirements arise from the need to store
documents, possibly to modify them and then to send them
on to a variety of different recipients:
• To add to a document that is already signed and to sign the
result
• To authorize different users to view different parts of a
document
• can view some particular section.

29
 XML security
Requirements concerning algorithms
• XML secure documents are signed and/or encrypted well
in advance of any consideration as to who will be
accessing them.
• If the originator is no longer involved, it is not possible to
negotiate the protocols and whether to use authentication
or encryption.
• Therefore:
• The standard should specify a suite of algorithms to be provided in
any implementation of XML security
• At least one encryption and one signature algorithm should be mandatory, to
enable the widest possible interoperability
• The algorithms used for encryption and authentication of a
particular document must be selected from that suite and the
names of the algorithms in use must be referenced within the XML
30
document itself
 XML security
Requirements concerning algorithms
• XML security defines the names of elements that can be
used to specify the URI of the algorithm in use for signing or
encryption.
• to be able to select a variety of algorithms within the
same XML document.

31
 XML security
Requirements for finding keys
• When a document is created and each time that it is updated,
appropriate keys must be chosen, without any negotiation with
those parties that may access the document in the future.
• This leads to the following requirements:
• To help the users of secure documents with finding the
necessary keys:
• signed data should contain information as to the public key
to be used to validate the signature. A KeyInfo element
can be used for this purpose.
• To make it possible for cooperating users to help one another
with keys:
• Provided that the KeyInfo element is not cryptographically
bound to the signature itself, information may be added
without breaking the digital signature. 32
 XML security
The KeyInfo element
• XML security specifies a KeyInfo element for indicating the key to
be used to validate a signature or to decrypt some data.
• It may contain, for example, certificates, the names of keys or
key agreement algorithms.

• Its use is optional: the signer may not want to reveal any key
information to all of the parties that access the document, and in
some cases the application using XML security may already have
access to the keys in use.

33
 XML security
Canonical XML
• Some applications may make changes that have no effect on
the actual information content of an XML document.
• This arises because there are a variety of different ways of
representing what is logically the same XML document.
• For example, attributes may be in different orders and differing
character encodings may be used, yet the information content
is equivalent.
• Canonical XML [www.w3.org X] was designed for use with
digital signatures, which are used to guarantee that the
information content of a document has not been changed.

34
 XML security
Use of digital signatures in XML
• The specification for digital signatures in XML [www.w3.org XII] is
a W3C recommendation that defines new XML element types to
hold signatures, the names of algorithms, keys and references
to signed information.
• The names provided in this specification are defined in the XML
Signature schema, includes the elements Signature,
SignatureValue, SignedInfo and KeyInfo.
• Figure 9.16 shows the algorithms that must be available in an
implementation of XML Signature

35
Figure 9.16
Algorithms required for XML signature

Type of algorithm Name of algorithm Required reference

Message digest SHA-1 Required Section 7.4.3

Encoding base64 Required [Freed and Borenstein 1996]

Signature DSA with SHA-1 Required [NIST 1994]

(asymmetric) RSA with SHA-1 Recommended Section 7.3.2

MAC signature HMAC-SHA-1 Required Section 7.4.2 and Krawczyk

(symmetric) et al. [1997]

Canonicalization Canonical XML Required Page 810

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 XML security
Key management service
• The specification of the XML key management service
[www.w3.org XIII] contains protocols for distributing and
registering public keys for use in XML signatures.
• Although it does not require any particular public key
infrastructure, the service is designed to be compatible with
existing ones.
• Clients can use this service to find the public key of
a person.

37
 XML security
XML encryption
• The standard for encryption in XML is defined in a W3C
recommendation that specifies both the way to represent
encrypted data in XML and the process for encrypting and
decrypting it [www.w3.org XIV].
• It introduces an EncryptedData element for enclosing
portions of encrypted data.
• Figure 9.17 specifies the encryption algorithms that should
be included in an implementation of XML encryption.

38
Figure 9.17
Algorithms required for encryption(in Figure 9.16 are also required)
 Coordination of web services
choreography
• Choreography is intended to support interactions between web
services which are generally managed by different companies
and organizations.
• A collaboration involving multiple web services and clients should
be described in terms of the sets of observable interactions
between pairs of them.
Such a description might be seen as a contract between the
participants, and could be used for the following purposes:
✓ to generate code outlines for a new service that wants to
participate;
✓ as a basis for generating test messages for a new service;
✓ to promote a common understanding of the collaboration;
✓ to analyze the collaboration, for example to identify possible
deadlock situations. 40
 Coordination of web services
choreography
• The use of a common choreography description
by a set of collaborating web services should
result in more robust services with better
interoperability.
• In addition, it should be easier to develop and to
introduce new services, making the overall
service more useful.

41
 Applications of web services
Web services
• Web services are now one of the dominant
paradigms for programming distributed
systems.
• In this section, we discuss a number of the major
areas where web services have been employed
extensively:
• in supporting service-oriented architecture,
• the Grid and latterly, cloud computing.

42
 Applications of web services
Service-oriented architecture (SOA)
• is a set of design principles whereby distributed
systems are developed using sets of loosely
coupled services that can be dynamically
discovered and then communicate with each
other or are coordinated through choreography to
provide enhanced services.
• Service-oriented architecture is an abstract
concept that can be implemented using a variety
of technologies including the distributed object or
component-based approaches.
43
 Applications of web services
Service-oriented architecture
• This style of architecture can be used within a business or
organization to offer a flexible software architecture and to
achieve interoperability between the various services.
• Its prime use, however is in the broader Internet, offering a
common view of services making them globally accessible and
amenable to subsequent composition.
• This makes it possible to transcend the levels of heterogeneity
inherent in the Internet and also to deal with the problem of
different organizations adopting different middleware products
internally.
• The resultant property is known as business- to-business (B2B)
integration.

44
 Applications of web services
The Grid
• The name ‘Grid’ is used to refer to middleware that is
designed to enable the sharing of resources such as
files, computers, software, data and sensors on a very
large scale.
• The resources are shared typically by groups of users
in different organizations who are collaborating on the
solution of problems requiring large numbers of
computers to solve them, either by the sharing of data
or by the sharing of computing power.
• These resources are necessarily supported by
heterogeneous computer hardware, operating
systems, programming languages and applications. 45
 Applications of web services
The Grid
• Management is needed to coordinate the use of
resources to ensure that clients get what they
need and that services can afford to supply it.
• In some cases, sophisticated security
techniques are required to ensure that the correct
use is made of resources in this type of
environment.
•

46
 Applications of web services
The Grid
The World-Wide Telescope is typical of a range of data-intensive Grid
applications:
• The World-Wide Telescope is typical of a range of data-intensive
Grid applications, wherein:
• data is collected by means of scientific instruments;
• the data is stored in archives at separate sites whose locations
can be in different places throughout the world;
• the data is managed by teams of scientists belonging to separate
organizations;
• an immense and increasing quantity (terabytes or petabytes) of
raw data is generated from the instruments;
• computer programs are used to analyze and make summaries of
the raw data, for example, to classify, calibrate and catalogue the
47
raw data representing celestial objects.
 Applications of web services
Cloud computing
• Cloud computing was introduced as a set of Internet-based
application, storage and computing services sufficient to
support most users’ needs,
• thus enabling them to largely or totally dispense with local
data storage and application software.
• Cloud computing also promotes a view of everything as a
service, from physical or virtual infrastructure through to
software, often paid for on a per-usage basis rather than
purchased.
• The concept is therefore essentially linked to a new
business model for computing where cloud suppliers offer a
range of computational, data and other services to customers
as required for their daily use 48
Figure 9.19
A selection of Amazon Web Services
Next lecture

•Peer-to-peer

Assignment

• Start building your distributed system and specify Webservice as communication

and middleware.
1. Apply whatever belongs to web service to your system
2. Submit a report explaining the DS and all the steps of implementing web service

Deadline

Next lecture

50