Distributed Systems II CNDS Lecture 3 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.

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, rather than
built into the system.
3
 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 names
definitions, types, message, 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 – in particular, the types of the 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 document, 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 on the basis of 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.
• Out-In is a request-reply interaction initiated by the server.
9
Figure 9.12
Message exchange patterns for WSDL operations

Name Messages sent by

Client Server Delivery Fault message

Request Reply may replace Reply
In-Out
Request no fault message
In-Only
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 in
use.
13
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 document itself
30
 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)
Next lecture

•Coordination of web services

•Applications of web services
Assignment

Deadline

Next lecture
mr.ali.h.sh@gmail.com

40