SUBJECT CODE : IT8074

Strictly as per Revised Syllabus of

Anna University
Choice Based Credit System (CBCS)
Semester - VII (CSE / IT)
Professional Elective-II

Service Oriented
Architecture
Pranjali Deshpande
M.E. (Comp. Engg.), Ph.D (Pursuing), DoT, SPPU.
Assistant Professor,Department of Computer Engineering,
MKSSS's Cummins College of Engineering for Women,
Pune

Soudamini Patil
M.E. (Computer Science and Engineering)
Formerly Assistant Professor,
Department of Computer Engineering,
MKSSS's Cummins College of Engineering for Women,
Pune

® ®
TECHNICAL
PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge

(i)
Service Oriented Architecture
Subject Code : IT8074

Semester - VII (CSE / IT) Professional Elective - II

ã Copyright with Authors

All publishing rights (printed and ebook version) reserved with Technical Publications. No part of this book
should be reproduced in any form, Electronic, Mechanical, Photocopy or any information storage and
retrieval system without prior permission in writing, from Technical Publications, Pune.

Published by :
® ®
Amit Residency, Office No.1, 412, Shaniwar Peth,
TECHNICAL Pune - 411030, M.S. INDIA, Ph.: +91-020-24495496/97
PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge Email : [email protected] Website : www.technicalpublications.org

Printer :
Yogiraj Printers & Binders
Sr.No. 10/1A,
Ghule Industrial Estate, Nanded Village Road,
Tal. - Haveli, Dist. - Pune - 411041.

ISBN 978-93-90041-48-0

9 789390 041480 AU 17

9789390041480 [1] (ii)

preface
The importance of Service Oriented Architecture is well known in various
engineering fields. Overwhelming response to our books on various subjects inspired us to
write this book. The book is structured to cover the key aspects of the subject Service
Oriented Architecture.
The book uses plain, lucid language to explain fundamentals of this subject. The book
provides logical method of explaining various complicated concepts and stepwise methods
to explain the important topics. Each chapter is well supported with necessary illustrations,
practical examples and solved problems. All the chapters in the book are arranged in a
proper sequence that permits each topic to build upon earlier studies. All care has been
taken to make students comfortable in understanding the basic concepts of the subject.
The book not only covers the entire scope of the subject but explains the philosophy of
the subject. This makes the understanding of this subject more clear and makes it more
interesting. The book will be very useful not only to the students but also to the subject
teachers. The students have to omit nothing and possibly have to cover nothing more.
We wish to express our profound thanks to all those who helped in making this book a
reality. Much needed moral support and encouragement is provided on numerous
occasions by our whole family. We wish to thank the Publisher and the entire team of
Technical Publications who have taken immense pain to get this book in time with quality
printing.
Any suggestion for the improvement of the book will be acknowledged and well
appreciated.

Authors
Pranjali Deshpande
Soudamini Patil

Dedicated to God.

(iii)
Syllabus
Service Oriented Architecture - IT8074

UNIT - I XML
XML document structure - Well-formed and valid documents - DTD - XML Schema - Parsing XML
using DOM, SAX - XPath - XML Transformation and XSL - Xquery. (Chapter - 1)

UNIT - II Service Oriented Architecture (SOA) Basics

Characteristics of SOA, Benefits of SOA, Comparing SOA with Client-Server and Distributed
architectures - Principles of Service Orientation - Service layers. (Chapter - 2)

UNIT - III Web Services (WS) And Standards

Web Services Platform - Service descriptions - WSDL - Messaging with SOAP - Service discovery -
UDDI - Service-Level Interaction Patterns - Orchestration and Choreography. (Chapter - 3)

UNIT - IV Web Services Extensions

WS-Addressing - WS-Reliable Messaging - WS-Policy - WS-Coordination - WS-Transactions - WS-
Security - Examples. (Chapter - 4)

UNIT - V Service Oriented Analysis and Design

SOA delivery strategies - Service oriented analysis - Service Modelling - Service oriented design -
Standards and composition guidelines - Service design - Business process design - Case Study.
(Chapter - 5)

(iv)
Table of Contents
Unit - I

Chapter - 1 XML (1 - 1) to (1 - 54)

1.1 Introduction....................................................................................................... 1 - 2
1.2 XML Document Structure .................................................................................. 1 - 7
1.3 Well-formed and Valid DSocuments ............................................................... 1 - 11
1.4 DTD .................................................................................................................. 1 - 13
1.5 XML Schema .................................................................................................... 1 - 19
1.6 Parsing XML using DOM, SAX, XPATH ............................................................. 1 - 32
1.7 XML Transformation & XSL ............................................................................. 1 - 44
1.8 XQuery ............................................................................................................. 1 - 50

Unit - II

Chapter - 2 Service Oriented Architecture (SOA) Basics

(2 - 1) to (2 - 48)

2.1 Introduction....................................................................................................... 2 - 2
2.2 Characteristics of SOA ..................................................................................... 2 - 13
2.3 Benefits of SOA................................................................................................ 2 - 28
2.4 Comparing SOA with Client-Server & Distributed Architectures .................... 2 - 33
2.5 Principles of Service Orientation ..................................................................... 2 - 42
2.6 Service Layers .................................................................................................. 2 - 43

Unit - III

Chapter - 3 Web Services (WS) and Standards (3 - 1) to (3 - 22)

3.1 Web Services Platform ...................................................................................... 3 - 3

(v)
 3.2 Service Descriptions (with WSDL) ..................................................................... 3 - 5
3.3 Messaging with SOAP ........................................................................................ 3 - 9
3.4 Service Discovery and Description Advertisement ......................................... 3 - 13
3.5 Orchestration .................................................................................................. 3 - 16

Unit - IV

Chapter - 4 Web Services Extensions (4 - 1) to (4 - 30)

4.1 WS-Addressing ................................................................................................. 4 - 2

4.1.1 End Point References .......................................................................................... 4 - 2
4.1.2 Message Information Headers ............................................................................ 4 - 3
4.1.3 Addressing and SOA ............................................................................................ 4 - 4
4.2 Reliable Messaging ............................................................................................ 4 - 5
4.2.1 RM Source, RM Destination, Application Source and Application Destination .. 4 - 6
4.2.2 Sequences ........................................................................................................... 4 - 7
4.2.3 Acknowledgments ............................................................................................... 4 - 8
4.2.4 Delivery Assurances............................................................................................. 4 - 9
4.2.5 Reliable Messaging and SOA ............................................................................. 4 - 11
4.3 WS-Policy ......................................................................................................... 4 - 13
4.3.1 The WS-Policy Framework................................................................................. 4 - 13
4.3.2 Policy Assertions and Policy Alternatives .......................................................... 4 - 14
4.3.3 Policy Assertion Types and Policy Vocabularies ................................................ 4 - 14
4.3.4 Policy Subject, Policy Scopes, Policy Expressions and Policy Attachments ....... 4 - 15
4.3.5 Policies and SOA ................................................................................................ 4 - 15
4.4 WS - Coordination ........................................................................................... 4 - 16
4.4.1 Coordinator Composition .................................................................................. 4 - 16
4.4.2 Coordination Types and Coordination Protocols .............................................. 4 - 17
4.4.3 Coordination Contexts and Coordination Participants ..................................... 4 - 18
4.4.4 The Activation and Registration Process ........................................................... 4 - 18
4.4.5 The Completion Process .................................................................................... 4 - 19
4.4.6 Coordination and SOA ....................................................................................... 4 - 20

(vi)
 4.5 WS-Transactions .............................................................................................. 4 - 21
4.5.1 Atomic Transaction Protocols ........................................................................... 4 - 22
4.5.2 The Atomic Transaction Coordinator ................................................................ 4 - 22
4.5.3 The Atomic Transaction Process ....................................................................... 4 - 23
4.5.4 Atomic Transaction and SOA ............................................................................. 4 - 24
4.6 WS-Security ..................................................................................................... 4 - 24
4.6.1 Identification, Authentication and Authorization ............................................. 4 - 25
4.6.2 Single Sign On .................................................................................................... 4 - 26
4.6.3 Confidentiality and Integrity ............................................................................. 4 - 26
4.6.4 Transport-Level Security and Message Level Security ...................................... 4 - 28
4.6.5 Encryption and Digital Signatures ..................................................................... 4 - 28
4.6.6 Security and SOA ............................................................................................... 4 - 29

Unit - V

Chapter - 5 Service Oriented Analysis and Design (5 - 1) to (5 - 34)

5.1 SOA Delivery Strategies ..................................................................................... 5 - 2

5.2 SOA Oriented Analysis ....................................................................................... 5 - 9
5.3 Service Modeling ............................................................................................. 5 - 10
5.4 Service Oriented Design .................................................................................. 5 - 13
5.5 Standards Composition Guidelines ................................................................. 5 - 15
5.6 Service Design ................................................................................................. 5 - 20
5.7 Business Process Design .................................................................................. 5 - 30

(vii)
 Notes

(viii)
 UNIT - I

1 XML
Syllabus
XML document structure - Well-formed and valid documents - DTD - XML Schema -
ParsingXML using DOM, SAX - XPath - XML Transformation and XSL – Xquery.

Contents
1.1. Introduction
1.2 XML Document Structure
1.3 Well-formed and Valid Documents
1.4 DTD
1.5 XML Schema
1.6 Parsing XML using DOM, SAX, XPATH
1.7 XML Transformation & XSL
1.8 XQuery

(1 - 1)
Service Oriented Architecture 1-2 XML

1.1 Introduction

Understanding a relation between XML and SOA

 IBM has defined SOA as an application framework that takes everyday business
applications and breaks it down into individual business functions and processes
called Services.

Fig. 1.1.1 SOA application framework requirements

 Service Oriented Architecture (SOA) provides a cost-effective solution for Enterprise

Application Integration.
 Service Oriented Architecture (SOA) is a style of software design where services are
provided to the other components by application components, through a
communication protocol over a network.
 A primitive requirement of SOA is to be independent of vendors, products and
technologies. Hence it is important that SOA provides the required application
services in the loosely coupled manner (including distributed components), in an
abstracted way (to hide the complexity of the code), across the platforms achieving
inter-operability of the components.
 To provide cross platform inter-operability, SOA needs a common platform to build
infrastructure on. This infrastructure needs to be supported to form a common base
of understanding the services and the abstraction. XML (Extensible Mark-up
Language) provides the following support to achieve the foundation for SOA.
 XML-based representations support data format that achieve information
interchange between service providers and requesters in an SOA.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-3 XML

 Using XML eliminates the challenge of working with different data formats in
different applications across multiple platforms.
 XML has the benefit of ease of representation, being text-based, flexible, and
extensible by nature.

What is XML ?
 eXtensible Mark-up Language (popularly known as XML) is a software - and
hardware-independent tool for storing and transporting data.
 XML is a mark-up language, which is mainly used to represent the structured data.
Structured data is the one which contains the data along with the tag / label to
indicate what is that data.
 It is like a data with tag as a column name in RDBMS. One may think why we need
to XML rather than simply documenting the data with simple tags. In short -
o XML is a mark-up language much like HTML.
o XML was designed to store and transport data.
o XML was designed to be self-descriptive.
o XML was designed to be both human- and machine-readable.
o XML is a W3C Recommendation.
 Although the XML and HTML both are mark-up languages used in web
technologies, there are some key difference between XML and HTML. These are -
o XML and HTML were designed with different goals.
o XML was designed to carry data - with focus on what data is.
o HTML was designed to display data - with focus on how data looks.
o XML tags are not predefined like HTML tags.

Sample XML file

 An XML data is stored in a flat file with .xml extension.
 An XML data is a character based plain data as shown in the Fig. 1.1.2

<?xml version="1.0" encoding="ISO8859-1" ?> <note>

<notebook> <to>Renu</to>
<note> <from>Rama</from>
<to>Jaya</to> <heading>Alert</heading>
<from>Seeta</from> <body>Petrol level went down</body>
<heading>Reminder</heading> </note>
<body>Don't forget to meet me this <note>
weekend!</body> <to>Rama</to>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-4 XML

</note> <from>Tanu</from>
<note> <heading>Message</heading>
<to>Shyam</to> <body>Eat your lunch on time</body>
<from>Jaya</from> </note>
<heading>Alert</heading> </notebook>
<body>Tomorrow is medicine day</body>
</note>

Fig. 1.1.2 Sample XML Data

 XML file can be generated using special editors as well as with very simple editors
like notepad (on windows) or gedit (on Linux and equivalents). Refer Fig. 1.1.3

Fig. 1.1.3 Sample XML file generated in notepad application

 XML files are normally used in the web applications. Hence browser applications
like Google Chrome, Firefox or Internet Explorer can be used to view the file. Refer
Fig. 1.1.4 below to see how xml file looks when opened in the browser.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-5 XML

Fig. 1.1.4 XML view in browser application (Google Chrome)

Why to use XML

 XML does not use predefined tags.
 XML is extensible.
 XML simplifies things.
o It simplifies data sharing
o It simplifies data transport
o It simplifies platform changes
o It simplifies data availability
 XML separates data from presentation.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-6 XML

Fig. 1.1.5 Using XML as a vehicle between various applications

Advantages of XML
 In XML document, the presence of the tags makes the message self-documenting;
that is, a schema need not be consulted to understand the meaning of the text.
 The format of the document is not rigid. The tag is required for items that are
ordered by weight or volume, and may be omitted for items that are simply ordered
by number.
 The ability to recognize and ignore unexpected tags allows the format of the data to
evolve over time, without invalidating existing applications.
 Similarly, the ability to have multiple occurrences of the same tag makes it easy to
represent multivalued attributes.
 XML allows nested structures. Such information would have been split into
multiple relations in a relational schema.
 Since the XML format is widely accepted, a wide variety of tools are available to
assist in its processing, including programming language APIs to create and to read
XML data, browser software, and database tools.

Domain and Industry specific XMLs

 There are pre-defined XMLs that can be used for various transaction data
operations. These formats are industry specific :
o Stocks and Shares
o Financial transactions
o Medical data
o Mathematical data

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-7 XML

o Scientific measurements
o News information
o Weather services

1.2 XML Document Structure

 Similar to HTML, every XML document is
based on a Document Structure
 A typical XML document begins with
<?xml..?>. This is the declaration of xml
which is optional, but is important to
indicate that it is an xml document. Usually
at this beginning line version of the xml is
indicated.
<?xml version=”1.0” ?>
 In the above example XML file, starts with
following line.
<?xml version="1.0" encoding="ISO8859-1" ?>
It is also called as XML Prolog.
 <?xml> is a pre-defined tag and it indicates
the viewer application/browser that the lines
appearing later in this file contain XML data.
 You can find that the above line does not
appear in the browser window.
Refer Fig. 1.2.1.
 XML is a mark-up language that does not
use predefines tags. Refer Fig. 1.1.2,
the mark-up tags like <notebook> or <note>
are user defined tag.
 In this example, <notebook> is a root node
and <note> s is child nodes of it.
 As a result of this, when the xml file is
opened in the browser, refers Fig. 1.2.1, the
browser application does not take any action Fig. 1.2.1 XML tree example

on these user defined tags and displays it as data.

 XML data can be represented using a tree like structure.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-8 XML

XML Document Structure

 XML documents form a tree structure that starts at "the root" and branches to "the
leaves". As shown in the Fig. 1.2.2.

Fig. 1.2.2 XML Tree Structure / XML DOM

 The syntax rules of XML are very simple and logical. Every XML document has -
o Elements - These are the user defined XML tags. For example : <note> </note>.
 The Element can hold information in following forms.
 An element can contain :
 Nothing • Text
 Attributes • Other Elements
 Or a mix of all the above
o Empty Element - When nothing is written inside <ELEMENT>
</ELEMENT>, it is treated as an empty element.
 It can also be referred as self-closing tag <ELEMENT/>
 Empty elements can have attributes. Refer Element Attributes section in
the later part.
o Element Text - It is the string data held inside the <ELEMENT>
</ELEMENT>. For example :
 <heading>Reminder</heading>. In this example Reminder is the Text data.
 <cost> 200 </cost>. Here 200 is the Text data.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1-9 XML

o Element Attributes -
 Like HTML, XML elements can have attributes.
e.g. <cost currency=”USD”> 200 </cost>
In this example, currency is an attribute of cost and attribute value is USD
 Attributes are always in name - value pair
 Attributes are designed to contain data (called as value) related to a
specific element.
 Attribute values must be enclosed inside single or double quotes.
 Attribute values can use character strings or entities supported by xml
encoding.
 There are various types of XML encodings available. E.g.
 Unicode/ISO-10646 encodings (UTF-8, UTF-16, ISO-10646-UCS-2,
and ISO-10646-UCS-4)
 8-bit Latin character encodings (ISO-8859-1 and ISO-8859-2 )
 XML Relations - Every element in the XML file has following type of possible
relations as -
o Root - XML Documents Must Have a Root Element. The highest level element
in the valid XML file is the root element.
o Parent - One element can be a parent of another element. A parent node
encloses all its child elements.
o Child - Every XML element enclosed inside another XML element is a child
element.
o Sibling - Sibling elements are children elements on the same level or Sibling
elements are those XML elements that have same parent element.
 XML documents are formed as element trees.
 An XML tree starts at a root element and branches from the root to child elements.
 All elements can have sub elements (child elements).
 The terms parent, child, and sibling are used to describe the relationships between
elements.
 Parents have children. Children have parents. Siblings are children on the same
level.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 10 XML

Document Object Model (DOM)

 The W3C Document Object Model (DOM) is a platform and language-neutral
interface that allows programs and scripts to dynamically access and update the
content, structure, and style of a document. Refer Fig. 1.2.2
 The DOM defines a standard for accessing and manipulating documents. i.e. the
XML DOM is a standard for how to get, change, add, or delete XML elements.
 The XML DOM defines a standard way for accessing and manipulating XML
documents. It presents an XML document as a tree-structure.
 Understanding the DOM is a must for anyone working with HTML or XML.
 All XML elements can be accessed through the XML DOM.
 The XML DOM is a standard for how to get, change, add, and delete XML elements.
 Example :
o Refer the sample XML file given in Fig 1.1.2 or 1.1.3, following code returns
the text value of the first <to> element in this XML document.
xmlDoc.getElementsByTagName("note")[0].childNodes[0].nodeValue;
o The value retuned by the above statement is Jaya.
o In this example ,
 xmlDoc - The XML DOM object created by the parser.
 getElementsByTagName("note")[0] - Get the first <note> element, index
starts at 0.
 childNodes[0] - The first child of the <note> element (the text node).
 nodeValue - The value of the node (the text itself), i.e Jaya.

Programming Interface of XML DOM

 The DOM models XML as a set of node objects. The nodes can be accessed with
JavaScript or other programming languages.
 The programming interface to the DOM is defined by a set standard properties and
methods.
 Properties are often referred to as something that is (i.e. node name is "note").
 Methods are often referred to as something that is done (i.e. delete "note").

XML DOM Properties - There are some typical DOM properties, if x is a node object,
then,
 x.nodeName - the name of x
 x.nodeValue - the value of x

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 11 XML

 x.parentNode - the parent node of x

 x.childNodes - the child nodes of x
 x.attributes - the attributes nodes of x

XML DOM Methods - There are some typical DOM methods, if x is a node object, then
 x.getElementsByTagName(name) - get all elements with a specified tag name
 x.appendChild(node) - insert a child node to x
 x.removeChild(node) - remove a child node from x

1.3 Well-formed and Valid Documents

 As we are aware of the fact that, XML tags are user defined and there is no way for
the browser application to understand the pre-defined meaning of these tags. Hence
it is required that XML file should follow some syntax rules for ensuring its
correctness. These are -
o Well-formed ness of XML document.
o Validity of document as per the syntax mentioned in DTD or Schema.

XML Naming Rules

 XML recommends Naming Rules for the elements in the XML document.
 Every XML element must follow these naming rules. These rules are -
o Element names are case-sensitive.
o Element names must start with a letter or underscore.
o Element names cannot start with the letters xml (or XML, or Xml, etc.).
o Element names can contain letters, digits, hyphens, underscores, and periods.
o Element names cannot contain spaces.
o Any name can be used; no words are reserved (except xml).

Best Naming Practices for XML

 Create descriptive names, like this: <person>, <firstname>, <lastname>.
 Create short and simple names, like this: <book_title> not like this:
<the_title_of_the_book>.
 Avoid "-". If you name something "first-name", some software may think you want
to subtract "name" from "first".
 Avoid ".". If you name something "first.name", some software may think that "name"
is a property of the object "first".

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 12 XML

 Avoid ":". Colons are reserved for namespaces (more later).

 Non-English letters like éòá are perfectly legal in XML, but watch out for problems
if your software doesn't support them.

XML Naming Styles

 There are no naming styles defined for XML elements. It is recommended to be
consistent while selecting a naming style.
 XML documents often have a corresponding database. A common practice is to use
the naming rules of the database for the XML elements.
 Some of the commonly used naming styles are as below :

Style Example Description

Lower case <postalcode> All letters lower case.

Upper case <POSTALCODE> All letters upper case.

Underscore <postal_code> Underscore separates words.

Pascal case <PostalCode> Uppercase first letter in each word.

Camel case <postalCode> Uppercase first letter in each word except the first.

Well Formed XML Documents

 An XML document with correct syntax is called "Well Formed". The syntax rules for
Well Formed document are as follows -
o XML documents must have a root element.
o XML elements must have a closing tag.
o XML tags are case sensitive.
o XML elements must be properly nested.
o XML attribute values must be quoted.

Importance of Well-Formed XML document

 With XML, errors are not allowed. Errors in XML documents stop XML
applications. The W3C XML specification states that a program should stop
processing an XML document if it finds an error. The reason is that XML software
should be small, fast, and compatible.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 13 XML

Valid XML Documents

 A "well formed" XML document is not the same as a "valid" XML document.
 A "valid" XML document must be well formed. In addition, it must conform to a
document type definition.
 There are two different document type definitions that can be used with XML :
o DTD - The original Document Type Definition
o XML Schema - An XML-based alternative to DTD
 A document type definition defines the rules and the legal elements and attributes
for an XML document.
1.4 DTD
 DTD stands for Document Type Definition. A DTD defines the structure and the
legal elements and attributes of an XML document.
 An XML document with correct syntax is called "Well Formed”. An XML document
validated against a DTD is both "Well Formed" and "Valid".
 The purpose of a DTD is to define the structure and the legal elements and
attributes of an XML document. A DTD file itself is a valid XML file.
Valid XML Documents
 A "Valid" XML document is "Well Formed", as well as it conforms to the rules of a
DTD :
 DTD is referred in XML document using <!DOCTYPE> directive
 The DOCTYPE declaration above contains a reference to a DTD file. The content of
the DTD file is shown and explained below.

<?xml version="1.0" encoding="ISO8859-1" ?>

<!DOCTYPE notebook SYSTEM "notebook.dtd">
<notebook>
<note>
<to>Jaya</to>
<from>Seeta</from>
<heading>Reminder</heading>
<body>Don't forget to meet me this weekend!</body>
</note>
<note>
<to>Shyam</to>
<from>Jaya</from>
<heading>Alert</heading>
<body>Tomorrow is medicine day</body>
</note>
</notepad>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 14 XML

 In the above example, notebook.dtd is a name of DTD is an external file.

XML DTD
 The purpose of a DTD is to define the structure and the legal elements and
attributes of an XML document :
 Example - notebook.dtd :
<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
 A browser application interprets the DTD as follows :
o !DOCTYPE notebook - Defines that the root element of the document is
notebook.
o !ELEMENT note - Defines that the note element must contain the elements:
"to, from, heading, body".
o !ELEMENT to - Defines the element to be of type "#PCDATA".
o !ELEMENT from - Defines the from element to be of type "#PCDATA".
o !ELEMENT heading - Defines the heading element to be of type "#PCDATA".
o !ELEMENT body - Defines the body element to be of type "#PCDATA".
o Here PCDATA is parse-able character data. Likewise there are other types of
elements also.
In-Line DTD
 A DOCTYPE declaration can also be used with in the xml file to define special
characters or strings, used in the document. Below is the example of valid XML file
that has DTD as a part of XML file.
<?xml version="1.0" encoding="ISO8859-1" ?>
<!DOCTYPE notebook
[
<!ELEMENT notebook (note*)>
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 15 XML

<notebook>
<note>
<to>Jaya</to>
<from>Seeta</from>
<heading>Reminder</heading>
<body>Don't forget to meet me this weekend!</body>
</note>
<note>
<to>Shyam</to>
<from>Jaya</from>
<heading>Alert</heading>
<body>Tomorrow is medicine day</body>
</note>
<note>
<to>Renu</to>
<from>Rama</from>
<heading>Alert</heading>
<body>Petrol level went down</body>
</note>
<note>
<to>Rama</to>
<from>Tanu</from>
<heading>Message</heading>
<body>Eat your lunch on time</body>
</note>
</notebook>

XML Data Types

 The W3 defines a number of primitive DTD types. These types can be assigned to
attribute values.
 CDATA
o In a Document Type Definition (DTD) an attributes type can be set to be
CDATA.
o The resulting attribute within an XML document may contain arbitrary
character data.
o The DTD CDATA type is a string type with no restrictions placed on it, it can
contain any textual data (as long as it’s suitably escaped).
o Declaring a CDATA Attribute in a DTD
<!ATTLIST lnk a CDATA >
o Sample XML
<lnk a="character data"/>
<lnk a="character data &amp;"/>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 16 XML

Fig. 1.4.1 XML Data Types

 ENTITY
o In a Document Type Definition (DTD) an attributes type can be set to be
ENTITY.
o For a value to be a valid ENTITY the following must be true.
o It must conform to the EBNF for "Name". In simple terms this means a "Name"
has to start with a letter or ':' or '_'. The rest of the characters must be numbers,
letters ':', '_', '-', or '.' it can not contain any spaces.
o The value of the ENTITY attribute also has to match an ENTITY that has been
declared elsewhere within the DTD.
o Declaring an ENTITY Attribute in a DTD
<!ELEMENT MyElement EMPTY>
<!ATTLIST MyElement myEntityTest ENTITY #REQUIRED>
<!ENTITY myEntityA "Some Entity Value A">
<!ENTITY myEntityB "Some Entity Value B">
o Sample XML
<MyElement myEntityTest="myEntityA"/>
 ID
o In a Document Type Definition (DTD) an attributes type can be set to be ID.
o For a value to be a valid ID the following must be true.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 17 XML

o It must conform to the EBNF for "Name". In simple terms this means a "Name"
has to start with a letter or ':' or '_'. The rest of the characters must be numbers,
letters ':', '_', '-', or '.' it can not contain any spaces.
o It must be unique across all the ID values declared within the XML Document.
o An element may only have a single ID value declared against it.
o An attribute declared of type ID must be defined as either #IMPLIED or
#REQUIRED.
o Declaring an IDREF Attribute in a DTD.
<!ELEMENT artist EMPTY>
<!ATTLIST artist name CDATA #REQUIRED>
<!ATTLIST artist artistID ID #REQUIRED>
<!ELEMENT album EMPTY>
<!ATTLIST album name CDATA #REQUIRED>
<!ATTLIST album albumArtistID IDREF #IMPLIED>
<!ATTLIST album contributingArtistIDs IDREFS #IMPLIED>
o Sample XML
<artist name="Nick Cave" artistID="NC"/>
<artist name="Kylie Minogue" artistID="KM"/>
<artist name="PJ Harvey" artistID="PJH"/>
<artist name="Shane MacGowan" artistID="SM"/>
<album name="Murder Ballads" albumArtistID="NC" contributingArtistIDs="KM PJH
SM"/>
 IDREF
o In a Document Type Definition (DTD) an attributes type can be set to be
IDREF.
o For a value to be a valid IDREF the following must be true.
o It must conform to the EBNF for "Name". In simple terms this means a "Name"
has to start with a letter or ':' or '_'. The rest of the characters must be numbers,
letters ':', '_', '-', or '.' it can not contain any spaces.
o The value of the IDREF attribute has to match an ID value defined elsewhere
within the XML Document.
o Declaring an IDREF Attribute in a DTD
<!ELEMENT artist EMPTY>
<!ATTLIST artist name CDATA #REQUIRED>
<!ATTLIST artist artistID ID #REQUIRED>
<!ELEMENT album EMPTY>
<!ATTLIST album name CDATA #REQUIRED>
<!ATTLIST album albumArtistID IDREF #IMPLIED>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 18 XML

o Sample XML
<artist name="Nick Cave" artistID="NC"/>
<album name="Murder Ballads" albumArtistID="NC"/>
 NMTOKEN
o In a Document Type Definition (DTD) an attributes type can be set to be
NMTOKEN (name token).
o For a value to be a valid NMTOKEN the following must be true:-
o It must conform to the EBNF for "Nmtoken". In simple terms it can contain
numbers letters, and ':', '_', '-', or '.' it can not contain spaces or whitespace.
o Declaring an IDREF Attribute in a DTD
<!ELEMENT invoice EMPTY>
<!ATTLIST invoice invoiceID NMTOKEN #REQUIRED>
o Sample XML
<invoice invoiceID="45684"/>
 PCDATA
o In a Document Type Definition (DTD) an element can contain #PCDATA.
o PCDATA in this context means mixed content, elements may contain
character data, optionally interspersed with child elements.
o Sample PCDATA Usage within a DTD.
<!ELEMENT b (#PCDATA)>
o Sample XML
<b>character data</b>
o The element b may contain character data, and nothing else.
o If used correctly in conjunction with other element types it can allow the
element to contain mixed content.
o Sample PCDATA Usage within a DTD
<!ELEMENT c (#PCDATA|d|e)*>
o Sample XML
<c>character data <d/> more text <d/> and more <e/></c>
o However PCDATA is not the semantic term for character data, and must
appear as the first item within a 0-n choice.
A choice between independent DTD and In-line DTD -
 In-line DTD is easy to write and interpret. However, it is suitable only for the small
size XML files.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 19 XML

 In-line DTD exposes the structure of Data within the XML file. Hence it is
vulnerable to security attacks.
 The independent DTD is useful for large applications as it provides data and data
definition separately.
 The independent DTD is suitable when the data in XML file is large in size.
 As data and definition are in the separate files, the modifiability of both is easy, in
case of independent DTD.
 Validation and transformation of XML data is easy with in-line DTD over
independent DTD as it reduces number of files to be read.

1.5 XML Schema

 An XML Schema describes the structure of an XML document, just like a DTD. An
XML document validated against an XML Schema is both "Well Formed" and
"Valid".
 XML Schema is an XML-based alternative to DTD.
 The purpose of an XML Schema is to define the legal building blocks of an XML
document.
 XML schema defines
o The elements and attributes that can appear in a document.
o The number of (and order of) child elements.
o Data types for elements and attributes.
o Default and fixed values for elements and attributes.
 Sample XML Schema
<xs:element name="notebook">
<xs:complexType>
<xs:sequence>
<xs:element name =”note”>
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 20 XML

 The Schema above is interpreted like this :

o xs:element name="notebook"> defines the element called "notebook"
o <xs:element name="note"> defines the element called "note"
o <xs:complexType> the “notebook” and "note" elements are complex type
o <xs:sequence> the complex type is a sequence of elements
o <xs:element name="to" type="xs:string"> the element "to" is of type string (text)
o <xs:element name="from" type="xs:string"> the element "from" is of type string
o <xs:element name="heading" type="xs:string"> the element "heading" is of type
string
o <xs:element name="body" type="xs:string"> the element "body" is of type
string

Why Use an XML Schema ?

 XML Schemas are more powerful than DTD.
 XML Schemas are written in XML.
 XML Schemas are extensible to additions.
 XML Schemas support data types.
 XML Schemas support namespaces.
 With XML Schema, your XML files can carry a description of its own format.
 With XML Schema, independent groups of people can agree on a standard for
interchanging data.
 With XML Schema, XML data can be verified more correctly than DTD.
 XML Schemas Support Data Types.
 XML Schemas support various data types and XML schema data type is considered
easier as :
o It is easier to describe document content.
o It is easier to define restrictions on data.
o It is easier to validate the correctness of data.
o It is easier to define data facets (restrictions on data).
o It is easier to define data patterns (data formats).
o It is easier to convert data between different data types.
 XML Schemas use XML Syntax.
 XML Schemas are written in XML, hence

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 21 XML

o There is no need to learn new language or syntax to write XML Schemas.

o XML editors can be used to write XML schemas.
o XML parser can be used to parse XML Schema files.
o XML schema can be manipulated with the XML DOM.
o XML Schema can be transformed in other XML Schemas with XSLT.

XML Schemas are extensible

 As the XML schemas itself are in XML, they are extensible. This means :
o XML schemas can be reused.
o XML schemas can be extended to derive new data types from the standard
types.
o XML schemas allow a single XML file / document to refer to multiple schemas
at a time.
o XML Schemas Secure Data Communication over network.

Rules for XML well-formed ness

 A well-formed XML document is a document that conforms to the XML syntax rules
as follows :
o It must begin with the XML declaration.
o It must have one unique root element.
o Start-tags must have matching end-tags.
o Elements are case sensitive.
o All elements must be closed.
o All elements must be properly nested.
o All attribute values must be quoted.
o Entities must be used for special characters.
 Even if documents are well-formed they can still contain errors, and those errors can
have serious consequences.

An XML Schema
 The following example is an XML Schema file called "note.xsd" that defines the
elements of the XML document above ("note.xml") :
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="https://www.myXML.com"
xmlns="https://www.myXML.com"

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 22 XML

elementFormDefault="qualified">
<xs:element name="notebook">
<xs:complexType>
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
</xs:schema>
 The note element is a complex type because it contains other elements. The other
elements (to, from, heading, body) are simple types because they do not contain
other elements. You will learn more about simple and complex types in the
following chapters.
 A Reference to an XML Schema
This XML document has a reference to an XML Schema :
<?xml version="1.0"?>
<note
xmlns="https://www.myXML.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://www.myXML.com/xml notebook.xsd">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
 The <schema> Element
The <schema> element is the root element of every XML Schema :
<?xml version="1.0"?>

<xs:schema>
...
...
</xs:schema>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 23 XML

The <schema> element may contain some attributes. A schema declaration often looks
something like this :
<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="https://www.myXML.com"
xmlns="https://www.myXML.com"
elementFormDefault="qualified">
...
...
</xs:schema>
 The following fragment indicates that the elements and data types used in the
schema come from the "http://www.w3.org/2001/XMLSchema" namespace. It also
specifies that the elements and data types that come from the
"http://www.w3.org/2001/XMLSchema" namespace should be prefixed with xs :
xmlns:xs="http://www.w3.org/2001/XMLSchema"
 The below fragment indicates that the elements defined by this schema (note, to,
from, heading, body.) come from the "https://www.myXML.com" namespace.
targetNamespace="https://www.myXML.com"
 Following fragment indicates that the default namespace is
"https://www.myXML.com".
xmlns="https://www.myXML.com"
 This fragment indicates that any elements used by the XML instance document
which were declared in this schema must be namespace qualified.
elementFormDefault="qualified"

Referencing a Schema in an XML Document

 This XML document has a reference to an XML Schema :
<?xml version="1.0"?>

<note xmlns="https://www.myXML.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://www.myXML.com note.xsd">

<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 24 XML

 The following fragment specifies the default namespace declaration. This

declaration tells the schema-validator that all the elements used in this XML
document are declared in the "https://www.myXML.com" namespace.
xmlns="https://www.myXML.com"
 Once you have the XML Schema Instance namespace available you can use the
schemaLocation attribute. This attribute has two values, separated by a space. The
first value is the namespace to use. The second value is the location of the XML
schema to use for that namespace
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://www.myXML.com notebook.xsd"

XSD Simple Elements

 XML Schemas define the elements of your XML files.
 A simple element is an XML element that contains only text. It cannot contain any
other elements or attributes.
 What is a simple element ?
 A simple element is an XML element that can contain only text. It cannot contain
any other elements or attributes.
 However, the "only text" restriction is quite misleading. The text can be of many
different types. It can be one of the types included in the XML Schema definition
(boolean, string, date, etc.), or it can be a custom type that you can define yourself.
 One can also add restrictions (facets) to a data type in order to limit its content, or
you can require the data to match a specific pattern.

Defining a Simple Element

 The syntax for defining a simple element is:
<xs:element name="xxx" type="yyy"/>
where xxx is the name of the element and yyy is the data type of the element.
 XML Schema has a lot of built-in data types. The most common types are:
o xs:string
o xs:decimal
o xs:integer
o xs:boolean
o xs:date
o xs:time

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 25 XML

 Example :
Here are some XML elements
<lastname>Refsnes</lastname>
<age>36</age>
<dateborn>1970-03-27</dateborn>
And here are the corresponding simple element definitions:
<xs:element name="lastname" type="xs:string"/>
<xs:element name="age" type="xs:integer"/>
<xs:element name="dateborn" type="xs:date"/>

Default and Fixed Values for Simple Elements

 Simple elements may have a default value OR a fixed value specified.
 A default value is automatically assigned to the element when no other value is
specified.
 In the following example the default value is "red":
<xs:element name="color" type="xs:string" default="red"/>
 A fixed value is also automatically assigned to the element, and you cannot specify
another value. In the following example the fixed value is "red":
<xs:element name="color" type="xs:string" fixed="red"/>

XSD Attributes
 All attributes are declared as simple types.
 Simple elements cannot have attributes. If an element has attributes, it is considered
to be of a complex type. But the attribute itself is always declared as a simple type.
 The syntax for defining an attribute is :
<xs:attribute name="xxx" type="yyy"/>
where xxx is the name of the attribute and yyy specifies the data type of the
attribute.
 XML Schema has a lot of built-in data types. The most common types are :
o xs:string
o xs:decimal
o xs:integer
o xs:boolean
o xs:date
o xs:time

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 26 XML

Example :
 Here is an XML element with an attribute :
<lastname lang="EN">Smith</lastname>
And here is the corresponding attribute definition :
<xs:attribute name="lang" type="xs:string"/>

Default and Fixed Values for Attributes

 Attributes may have a default value OR a fixed value specified.
 A default value is automatically assigned to the attribute when no other value is
specified.
 In the following example the default value is "EN":
<xs:attribute name="lang" type="xs:string" default="EN"/>
 A fixed value is also automatically assigned to the attribute, and you cannot specify
another value. In the following example the fixed value is "EN":
<xs:attribute name="lang" type="xs:string" fixed="EN"/>

Optional and Required Attributes

 Attributes are optional by default. To specify that the attribute is required, use the
"use" attribute :
<xs:attribute name="lang" type="xs:string" use="required"/>

Restrictions on Content
 When an XML element or attribute has a data type defined, it puts restrictions on
the element's or attribute's content.
 If an XML element is of type "xs:date" and contains a string like "Hello World", the
element will not validate.
 With XML Schemas, you can also add your own restrictions to your XML elements
and attributes. These restrictions are called facets. You can read more about facets in
the next chapter.

XSD Restrictions/Facets
 Restrictions are used to define acceptable values for XML elements or attributes.
Restrictions on XML elements are called facets.

Restrictions on Values
 The following example defines an element called "age" with a restriction. The value
of age cannot be lower than 0 or greater than 120 :

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 27 XML

<xs:element name="age">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="120"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

Restrictions on a Set of Values

 To limit the content of an XML element to a set of acceptable values, we would use
the enumeration constraint.
 The example below defines an element called "car" with a restriction. The only
acceptable values are : Audi, Golf, BMW :
<xs:element name="car">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Audi"/>
<xs:enumeration value="Golf"/>
<xs:enumeration value="BMW"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The example above could also have been written like this :
<xs:element name="car" type="carType"/>
<xs:simpleType name="carType">
<xs:restriction base="xs:string">
<xs:enumeration value="Audi"/>
<xs:enumeration value="Golf"/>
<xs:enumeration value="BMW"/>
</xs:restriction>
</xs:simpleType>

Restrictions on a Series of Values

 To limit the content of an XML element to define a series of numbers or letters that
can be used, we would use the pattern constraint.
 The example below defines an element called "letter" with a restriction. The only
acceptable value is ONE of the LOWERCASE letters from a to z :
<xs:element name="letter">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[a-z]"/>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 28 XML

</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example defines an element called "initials" with a restriction. The only
acceptable value is THREE of the UPPERCASE letters from a to z :
<xs:element name="initials">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z][A-Z][A-Z]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example also defines an element called "initials" with a restriction. The
only acceptable value is THREE of the LOWERCASE OR UPPERCASE letters from a
to z :
<xs:element name="initials">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[a-zA-Z][a-zA-Z][a-zA-Z]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example defines an element called "choice" with a restriction. The only
acceptable value is ONE of the following letters: x, y, OR z :
<xs:element name="choice">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[xyz]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example defines an element called "prodid" with a restriction. The only
acceptable value is FIVE digits in a sequence, and each digit must be in a range from
0 to 9 :
<xs:element name="prodid">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 29 XML

Other Restrictions on a Series of Values

 The example below defines an element called "letter" with a restriction. The
acceptable value is zero or more occurrences of lowercase letters from a to z :
<xs:element name="letter">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([a-z])*"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example also defines an element called "letter" with a restriction. The
acceptable value is one or more pairs of letters, each pair consisting of a lower case
letter followed by an upper case letter. For example, "sToP" will be validated by this
pattern, but not "Stop" or "STOP" or "stop".
<xs:element name="letter">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([a-z][A-Z])+"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example defines an element called "gender" with a restriction. The only
acceptable value is male OR female:
<xs:element name="gender">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="male|female"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 The next example defines an element called "password" with a restriction. There
must be exactly eight characters in a row and those characters must be lowercase or
uppercase letters from a to z, or a number from 0 to 9:
<xs:element name="password">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[a-zA-Z0-9]{8}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 30 XML

Restrictions on Whitespace Characters

 To specify how whitespace characters should be handled, we would use the
whiteSpace constraint.
 This example defines an element called "address" with a restriction. The whiteSpace
constraint is set to "preserve", which means that the XML processor WILL NOT
remove any white space characters :
<xs:element name="address">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:whiteSpace value="preserve"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 This example also defines an element called "address" with a restriction. The
whiteSpace constraint is set to "replace", which means that the XML processor WILL
REPLACE all white space characters (line feeds, tabs, spaces, and carriage returns)
with spaces:
<xs:element name="address">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:whiteSpace value="replace"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 This example also defines an element called "address" with a restriction. The
whiteSpace constraint is set to "collapse", which means that the XML processor
WILL REMOVE all white space characters (line feeds, tabs, spaces, carriage returns
are replaced with spaces, leading and trailing spaces are removed, and multiple
spaces are reduced to a single space) :
<xs:element name="address">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:whiteSpace value="collapse"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Restrictions on Length
 To limit the length of a value in an element, we would use the length, maxLength,
and minLength constraints.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 31 XML

 This example defines an element called "username" with a restriction. The value
must be exactly eight characters :
<xs:element name="username">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:length value="8"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
 This example defines another element called "password" with a restriction. The
value must be minimum five characters and maximum eight characters:
<xs:element name="password">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="5"/>
<xs:maxLength value="8"/>
</xs:restriction>
</xs:simpleType>
</xs:element
Restrictions for Datatypes

Constraint Description
enumeration Defines a list of acceptable values.

fractionDigits Specifies the maximum number of decimal places allowed. Must be equal to or
greater than zero.

length Specifies the exact number of characters or list items allowed. Must be equal to or
greater than zero.

maxExclusive Specifies the upper bounds for numeric values (the value must be less than this
value).

maxInclusive Specifies the upper bounds for numeric values (the value must be less than or
equal to this value).

maxLength Specifies the maximum number of characters or list items allowed. Must be equal
to or greater than zero.

minExclusive Specifies the lower bounds for numeric values (the value must be greater than
this value).

minInclusive Specifies the lower bounds for numeric values (the value must be greater than or
equal to this value).

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 32 XML

minLength Specifies the minimum number of characters or list items allowed. Must be equal
to or greater than zero.

pattern Defines the exact sequence of characters that are acceptable.

totalDigits Specifies the exact number of digits allowed. Must be greater than zero

whiteSpace Specifies how white space (line feeds, tabs, spaces, and carriage returns) is
handled

1.6 Parsing XML using DOM, SAX, XPATH

XML Parsing
 XML Parsing is a technique of reading and identifying XML tags from an XML
document. Or
 XML parsing is functionality by an application to read an XML file using its DTD or
Schema and extract necessary data / information from it. Refer Fig. 1.6.1.
 The XML DOM (Document Object Model) defines the properties and methods for
accessing and editing XML.
 However, before an XML document can be accessed, it must be loaded into an XML
DOM object.
 All modern browsers have a built-in XML parser that can convert text into an XML
DOM object.

Fig. 1.6.1 XML Parsing

 There are three popular types of XML parsers namely

o DOM Parsers
o SAX
o XPATH
 DOM and SAX parse XML file by validating or a non-validating parser. A validating
parser checks the XML file against the rules imposed by DTD or XML Schema. A
non-validating parser doesn't validate the XML file against a DTD or XML Schema.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 33 XML

Both Validating and non-validating parser checks for the well-formed ness of XML
document.
 The SAX and DOM parsers are standards that are implemented in several different
languages.

Parsing XML file using DOM

 DOM parser is designed to work with XML as an object graph or an object tree
known as “Document Object Model (DOM)”. The DOM parsing performs following
actions -
o The parser traverses the input XML file and creates DOM objects according to
the nodes in the input XML file
o These DOM objects are linked together in a tree like structure to create DOM.
o Once the DOM object structure is created, it can be traversed to
get/update/delete data from it.
 At the core of the DOM API are the Document and Node interfaces. A Document is
a top level object that represents an XML document.
 The Document holds the data as a tree of Nodes, where a Node is a base type that
can be an element, an attribute, or some other type of content. Nodes represent a
single piece of data in the tree, and provide all of the popular tree operations.
 A node can be queried for its parent, its siblings, or its children. An XML document
can also be modified adding or removing Nodes.
 The DOM tree is composed of nodes and they are of 12 types :
o ATTRIBUTE_NODE,
o CDATA_SECTION_NODE,
o COMMENT_NODE,
o DOCUMENT_FRAGMENT_NODE,
o DOCUMENT_NODE,
o DOCUMENT_TYPE_NODE,
o ELEMENT_NODE,
o ENTITY_NODE,
o ENTITY_REFERENCE_NODE,
o NOTATION_NODE,
o PROCESSING_INSTRUCTION_NODE,
o TEXT_NODE

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 34 XML

Fig. 1.6.2 DOM Parsing

 Here is a sample code that explains the DOM Parsing

<!DOCTYPE html>
<html>
<body>
<p id="demo"></p>
<script>
var parser, xmlDoc;
//in-line XML data
var text ="<notebook>"+
"<note>"+
"<to>Jaya</to>"+
"<from>Seeta</from>"+
"<heading>Reminder</heading>"+
"<body>Don't forget to meet me this weekend!</body>"+
"</note>"+
"<note>"+
"<to>Maya</to>"+
"<from>Meeta</from>"+
"<heading>Welcome</heading>"+
"<body>Welcome to Mumbai</body>"+
"</note>"+
"</notebook>";

//Get Document Builder

parser = new DOMParser();

//Build Document
xmlDoc = parser.parseFromString(text,"text/xml");

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 35 XML

//Link the new root and data to display using .innerHTML

document.getElementById("demo").innerHTML =
xmlDoc.getElementsByTagName("from")[0].childNodes[0].nodeValue + " said to " +
xmlDoc.getElementsByTagName("to")[0].childNodes[0].nodeValue +" that " +
xmlDoc.getElementsByTagName("body")[0].childNodes[0].nodeValue ;
</script>
</body>
</html>
 The output is
Seeta said to Jaya that don’t forget to meet me this weekend!

DOM APIs
 In below example code, refer the file notebook.xml in Fig1. This example starts
fetching information and printing it on console.

//Get Document Builder

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();

//Build Document
Document document = builder.parse(new File("notebook.xml"));

//Normalize the XML Structure;

document.getDocumentElement().normalize();

//Here comes the root node

Element root = document.getDocumentElement();
System.out.println(root.getNodeName());

//Get all notes

NodeList nList = document.getElementsByTagName("note");

for (int temp = 0; temp < nList.getLength(); temp++)

{
Node node = nList.item(temp);
System.out.println(""); //Just a separator
if (node.getNodeType() == Node.ELEMENT_NODE)
{
//Print each employee's detail
Element eElement = (Element) node;

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 36 XML

System.out.println(eElement.getElementsByTagName("from").item(0).getTextContent() + " said

to " + eElement.getAttribute("to") + " that " +
eElement.getElementsByTagName("body").item(0).getTextContent());
}
}
Program Output :
Notebook
Seeta said to Jaya that Don't forget to meet me this weekend!
Jaya said to Shyam that Tomorrow is medicine day
Rama said to Renu that Petrol level went down
Tanu said to Rama that Eat your lunch on time
 Advantages of using DOM
o It is good when random access to widely separated parts of a document is
required.
o It supports both read and writes operations.
 Disadvantage of DOM
o It is memory inefficient Because DOM consumes more memory to construct
the XML tree Object in the memory corresponding to the input XML.

SAX Parser
 SAX (Simple API for XML) is an event-driven online algorithm for parsing XML
documents, with an API developed by the XML-DEV mailing list.
 SAX provides a mechanism for reading data from an XML document that is an
alternative to that provided by the Document Object Model (DOM).
 The DOM operates on the document as a whole—building the full abstract syntax
tree of an XML document But SAX parsers operate on each piece of the XML
document sequentially, issuing parsing events while making a single pass through
the input stream. So it is memory efficient.
 Unlike DOM, there is no formal specification for SAX. SAX processes documents
state-independently, in contrast to DOM which is used for state-dependent
processing of XML documents.
 Rather than building a complete representation of the document, a SAX parser fires
off a series of events as it reads the document from beginning to end. Those events
are passed to event handlers, which provide access to the contents of the document.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 37 XML

XML processing with SAX

 A parser that implements SAX (i.e., a SAX Parser) functions as a stream parser, with
an event-driven API. The user defines a number of callback methods that will be
called when events occur during parsing. The SAX events include
o XML Text nodes
o XML Element Starts and Ends
o XML Processing Instructions
o XML Comments

Fig.1.6.3 SAX Parser

Event Handlers
 There are three classes of event handlers :
o DTD Handlers, for accessing the contents of XML Document-Type Definitions.
o Error Handlers, for low-level access to parsing errors; and, by far the most
often used.
o Document Handlers, for accessing the contents of the document.
 A SAX processor will pass the following events to a Document Handler :
o The start of the document.
o A processing instruction element.
o A comment element.
o The beginning of an element, including that element's attributes.
o The text contained within an element.
o The end of an element.
o The end of the document.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 38 XML

 Advantages of SAX
o It is simple to program.
o It is memory efficient as SAX parser does not keep any of the document tree in
memory.
 Disadvantage of SAX
o The data is broken into pieces and clients never have all the information as a
whole unless they create their own data structure.
 DOM Vs. SAX
DOM SAX
Stores the entire XML document into memory Parses node by node.
before processing.

Occupies more memory. Doesn't store the XML in memory.

Insertion and deletion of node is possible. Insertion and deletion of node is not possible.

Traverse in any direction. Top to bottom traversing.

XPATH
 XPath (XML Path Language) is a query language for selecting nodes from an XML
document.
 In addition, XPath may be used to compute values (e.g., strings, numbers, or
Boolean values) from the content of an XML document. XPath was defined by the
World Wide Web Consortium (W3C).
 The primary purpose of XPath is to address the nodes of XML trees. XPath gets its
name from its use of a path notation for navigating through the hierarchical
structure of an XML document.
 XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and
XML attribute values.
 XPath is a major element in the XSLT standard. It can be used to navigate through
elements and attributes in an XML document.
 XPath is syntax for defining parts of an XML document.
 XPath uses path expressions to navigate in XML documents.
 XPath contains a library of standard functions.
 XPath is a major element in XSLT and in XQuery.
 XPath is a W3C recommendation.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 39 XML

XPath Path Expressions

 XPath uses path expressions to select nodes or node-sets in an XML document.
These path expressions look very similar with a traditional computer file system.
 XPath expressions can be used in JavaScript, Java, XML Schema, PHP, Python, C
and C++, and lots of other languages.
 XPath is Used in XSLT XPath is a major element in the XSLT standard.
 XPath uses path expressions to select nodes or node-sets in an XML document. The
node is selected by following a path or steps.
Selecting Nodes
 XPath uses path expressions to select nodes in an XML document. The node is
selected by following a path or steps. Following are the most useful path
expressions :
Expression Description
nodename Selects all nodes with the name "nodename".

/ Selects from the root node.

// Selects nodes in the document from the current node that match the
selection no matter where they are.

. Selects the current node.

.. Selects the parent of the current node.

@ Selects attributes.

 Some path expressions and the result of the expressions on the XML file.
(Refer Fig. 1.1.2)
Path Expression Result
note Selects all nodes with the name "note".

/notebook Selects the root element bookstore.

Note : If the path starts with a slash ( / ) it always represents an absolute

path to an element!

notebook/note Selects all note elements that are children of notebook

//note Selects all note elements no matter where they are in the document

notebook//note Selects all note elements that are descendant of the notebook element, no
matter where they are under the notebook element.

//@lang Selects all attributes that are named lang.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 40 XML

Predicates
 Predicates are used to find a specific node or a node that contains a specific value.
 Predicates are always embedded in square brackets.
 In the table below we have listed some path expressions with predicates and the
result of the expressions.

Path Expression Result

/notebook/note[1] Selects the first note element that is the child of the notebook element.

/notebook/note[last()] Selects the last note element that is the child of the notebook element.

/notebook/note[last()-1] Selects the last but one note element that is the child of the notebook
element.

/notebook/note[position()<3] Selects the first two note elements that are children of the notebook
element.

//title[@lang] Selects all the title elements that have an attribute named lang.

//title[@lang='en'] Selects all the title elements that have a "lang" attribute with a value of
"en".

Selecting Unknown Nodes

 XPath wildcards can be used to select unknown XML nodes.

Wildcard Description
* Matches any element node

@* Matches any attribute node

node() Matches any node of any kind

Selecting Several Paths

 By using the | operator in an XPath expression you can select several paths.
 Some path expressions and the result of the expressions :
Path Expression Result
//note/title | //note/price Selects all the title AND price elements of all note elements.

//title | //price Selects all the title AND price elements in the document.

/notebook/note/title | //price Selects all the title elements of the note element of the notebook
element AND all the price elements in the document.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 41 XML

XPath Axes
 An axis represents a relationship to the context (current) node, and is used to locate
nodes relative to that node on the tree.
Axis Name Result
ancestor Selects all ancestors (parent, grandparent, etc.) of the current node.

ancestor-or-self Selects all ancestors (parent, grandparent, etc.) of the current node and the
current node itself.

attribute Selects all attributes of the current node.

child Selects all children of the current node.

descendant Selects all descendants (children, grandchildren, etc.) of the current node.

descendant-or-self Selects all descendants (children, grandchildren, etc.) of the current node and the
current node itself.

following Selects everything in the document after the closing tag of the current node.

following-sibling Selects all siblings after the current node.

namespace Selects all name space nodes of the current node.

parent Selects the parent of the current node.

preceding Selects all nodes that appear before the current node in the document, except
ancestors, attribute nodes and namespace nodes.

preceding-sibling Selects all siblings before the current node.

self Selects the current node.

Location Path Expression

 A location path can be absolute or relative.
 An absolute location path starts with a slash (/) and a relative location path does not.
In both cases the location path consists of one or more steps, each separated by a
slash.
 Each step is evaluated against the nodes in the current node-set.
 A step consists of :
o An axis (defines the tree-relationship between the selected nodes and the
current node)
o A node-test (identifies a node within an axis)
o Zero or more predicates (to further refine the selected node-set)

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 42 XML

Example Result
child::note Selects all note nodes that are children of the current node.

attribute::lang Selects the lang attribute of the current node.

child::* Selects all element children of the current node.

attribute::* Selects all attributes of the current node.

child::text() Selects all text node children of the current node.

child::node() Selects all children of the current node.

descendant::note Selects all note descendants of the current node.

ancestor::note Selects all note ancestors of the current node.

ancestor-or- Selects all note ancestors of the current node - and the current as well if it is a
self::note note node.

child::*/child::price Selects all price grandchildren of the current node.

XPath Operators
 An XPath expression returns either a node-set, a string, a Boolean, or a number.
 Below is a list of the operators that can be used in XPath expressions.
Operator Description Example

| Computes two node-sets //note | //cd

+ Addition 6+4

- Subtraction 22-18

* Multiplication 6*4

div Division 8 div 4

= Equal Amount = 6.55

!= Not equal Amount != 6.55

< Less than Amount < 6.55

<= Less than or equal to Amount <= 6.55

> Greater than Amount > 6.55

>= Greater than or equal to Amount >= 6.55

or or Amount = 6.55 or amount = 9.70

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 43 XML

and and Amount > 8.00 and amount < 9.90

mod Modulus (division remainder) 9 mod 4

XPATH Example
 Here is a new XML file referred to understand the use of XPATH.
<?xml version="1.0" encoding="utf-8"?>
<mypage>
<devteam>
<release name="europe" launch="2012-01-05">
<sprint>
<page language="English">en.mypage.com</page>
<page language="German">de.mypage.com</page>
<page language="French">fr.mypage.com</page>
<page language="Polish">pl.mypage.com</page>
<page language="Spanish">es.mypage.com</page>
</sprint>
</release>
<release name="local" launch="2019-12-12">
<sprint>
<page language="English">en.local.mypage.com</page>
<page language="French">fr.local.mypage.com</page>
<page language="Vietnamese">vi.local.mypage.com</page>
<page language="Turkish">tr.local.mypage.com</page>
<page language="Spanish">es.local.mypage.com</page>
</sprint>
</release>
</devteam>
</mypage>

Fig. 1.6.4 Sample XML file (mypage.xml) for Agile Project - www.mypage.com

Fig. 1.6.5 XPath syntax and terminology

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 44 XML

The XPath expressions (Refer Fig. 1.6.5 for understanding the expressions below).
 Selects name attributes for all devteam, and
/mypage/devteam/release/@name
 Selects all sprint of all devteam
/mypage//sprint
 Selects addresses of all English mypage devteam (text of all page elements where
language attribute is equal to English).
/mypage/devteam/release/sprint/page[@language='English']/text()
 Selects addresses of all mypages (text of all page elements that exist under release
element with a name attribute of mypage).
/mypage/devteam/release[@name='mypage']/sprint/page/text()

Using XPATH in XML

 XPath is increasingly used to express constraints in schema languages for XML.
 The (now ISO standard) schema language Schematron pioneered this approach.
 A streaming subset of XPath is used in W3C XML Schema 1.0 for expressing
uniqueness and key constraints.
 In XSD 1.1, the use of XPath is extended to support conditional type assignment
based on attribute values, and to allow arbitrary Boolean assertions to be evaluated
against the content of elements.
 XForms uses XPath to bind types to values.

1.7 XML Transformation & XSL

 XSLT (Extensible Stylesheet Language Transformations) is a language for
transforming XML documents into other XML documents.
 The original document is not changed; rather, a new document is created based on
the content of an existing one.
 The other formats in which XSLT can transform an XML page contents are :
o HTML for web pages
o Plain text
o XSL Formatting Objects
o PDF
o PostScript
o PNG
 XSLT 1.0 is widely supported in modern web browsers.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 45 XML

 Typically, input documents are XML files, but

anything from which the processor can build
an XQuery and XPath Data Model can be used,
such as relational database tables or
geographical information systems.
 The XSLT processor takes one or more XML
source documents, plus one or more XSLT
stylesheets, and processes them to produce an
output document.
 The XSLT processor performs the
transformation as follows.
 First, assuming a stylesheet has already been
read and prepared, the processor builds a
source tree from the input XML document.
 It then processes the source tree's root node,
finds the best-matching template for that node
in the stylesheet, and evaluates the template's
contents.
 Instructions in each template generally direct
the processor to either create nodes in the
result tree, or to process more nodes in the
source tree in the same way as the root node.
Fig. 1.7.1. Process flow of XSLT
 Finally the result tree is serialized as XML or
HTML text.
 XSLT uses XPath to identify subsets of the source document tree and perform
calculations. XPath also provides a range of functions, which XSLT itself further
augments.

XSLT value extractions

 Extracting contents of elements and attributes of XML file is important for
o Creating HTML code for links and images.
o Creating the HTML title element.
o Creating data-centric XML that represent data-base like structures.

XSLT Syntax
 Root of an XSLT file stylesheet

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 46 XML

An XSLT program is an XML document. Its top-level skeleton looks like this :
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
....
</xsl:stylesheet>
 Mandatory "elements"
o An XML declaration on top of the file
o A stylesheet root tag, including version and namespace attributes as
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

 Usually the "xsl" prefix is used for XSLT tags, but you also can find "xs" or none if
you look at examples.

 XSLT must be well-formed and valid, i.e. obey the XSLT specification.

 XSLT files usually have the *.xsl extension and should have the text / xsl or
application/xml mime type when served by http (a web server).

Association of XML and an XSLT file

 One can directly associate a XSLT stylesheet with an XML file by using a so-called
processing instruction (similar principle as CSS stylesheets). This solution will work
with all modern web browsers.
<?xml version="1.0"?>
<?xml-stylesheet href="project.xsl" type="text/xsl" ?>
<newxml>
....
</newxml>

 Use a xml-stylesheet instruction if you plan to display XML contents directly in a

browser.
 Basic (!) use of XSLT means translating XML to HTML.
 Creating translation rules (aka templates) for each XML tag we want to translate.
 A simple translation rule (called "template" in XSLT)

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 47 XML

XSLT Structure

Fig. 1.7.2 XSLT Structure

XSLT Elements
 XSLT <xsl:template> Element
o An XSL style sheet consists of one or more set of rules that are called
templates.
o A template contains rules to apply when a specified node is matched.
o The match attribute is used to associate a template with an XML element.
o The match attribute can also be used to define a template for the entire XML
document.
o The value of the match attribute is an XPath expression (i.e. match="/" defines
the whole document).
e.g. <xsl:template match="/">
 XSLT<xsl:value-of> Element
o The <xsl:value-of> element can be used to extract the value of an XML element
and add it to the output stream of the transformation.
e.g. <xsl:value-of select="/News/Players/Player"/>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 48 XML

 XSLT <xsl:for-each> Element

o The <xsl:for-each> element allows you to do looping in XSLT.
o The <xsl:for-each> element can be used to select every XML element of a
specified node-set.
e.g. <xsl:for-each select="/News/Players">
<xsl:value-of select="Player"/>
</xsl:for-each>
 XSLT <xsl:sort> Element
o The <xsl:sort> element is used to sort the output. To sort the output, simply
add an <xsl:sort> element inside the <xsl:for-each> element in the XSL file.
e.g. <xsl:sort select="Player"/>
 XSLT <xsl:if> Element
o The <xsl:if> element is used to put a conditional test against the content of the
XML file.
e.g. <xsl:if test="expression">
...action if condition is true
</xsl:if>
 XSLT <xsl:choose> Element
o The <xsl:choose> element is used in conjunction with <xsl:when> and
<xsl:otherwise> to express multiple conditional tests. It is just like the switch()
in C,C++ or Java.
e.g. <xsl:choose>
<xsl:when test="expression">
... some output ...
</xsl:when>
<xsl:otherwise>
... some output ....
</xsl:otherwise>
</xsl:choose>
 XSLT <xsl:apply-templates> Element
 The <xsl:apply-templates> element applies a template to the current element or to
the current element's child nodes.
 If we add a "select" attribute to the <xsl:apply-templates> element, it will process
only the child elements that matches the value of the attribute. We can use the
"select" attribute to specify in which order the child nodes are to be processed.
e.g. <xsl:template match="Players">
<p>
<xsl:apply-templates select="Player"/>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 49 XML

XSLT Example
 XSLT uses XPath to identify subsets of the source document tree and perform
calculations. XPath also provides a range of functions, which XSLT itself further
augments.
 This example demonstrates the basics of setting up an XSLT transformation in a
browser. The example will take an XML document that contains information (Team,
list of Players and body text) about News and present it in a human readable form.
 The XML document (example.xml) contains the information about the News. Using
the ?xml-stylesheet? processing instruction, it links to the XSLT stylesheet
(example.xsl) via its href attribute.
 An XSLT stylesheet starts with the xsl:stylesheet element, which contains all the
templates used to create the final output.
 This example has two templates -
o Template that matches the root node
o Template that matches Player nodes.
 The template that matches the root node outputs the News's Team and then says to
process all templates (via apply-templates) that match Player nodes which are
children of the player’s node.
 Source / input file XML Document (example.xml).
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="example.xsl"?>
<News>
<Team>My News</Team>
<Players>
<Player>Jay</Player>
<Player>Ajay</Player>
<Player>Vijay</Player>
<Player>Sanjay</Player>

</Players>
<Body>This is my News text.</Body>
</News>
 XSL Stylesheet (example.xsl) :
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="text"/>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 50 XML

<xsl:template match="/">
News - <xsl:value-of select="/News/Team"/>
Players: <xsl:apply-templates select="/News/Players/Player"/>
</xsl:template>

<xsl:template match="Player">
- <xsl:value-of select="." />
</xsl:template>

</xsl:stylesheet>
 Open the example.xml in the browser application to see following output.
News - My News
Players :
- Jay
- Ajay
- Vijay
- SanjayS

1.8 XQuery
 XQuery (XML Query) is a query and functional programming language that queries
and transforms collections of structured and unstructured data, usually in the form
of XML, text and with vendor-specific extensions for other data formats (JSON,
binary, etc.).
 The language is developed by the XML Query working group of the W3C. The work
is closely coordinated with the development of XSLT by the XSL Working Group;
the two groups share responsibility for XPath, which is a subset of XQuery.
 The latest version of XQuery is XQuery 3.1 as a W3C Recommendation on March 21,
2017.
 XQuery provides the means to extract and manipulate data from XML documents
or any data source that can be viewed as XML, such as relational databases or office
documents.
 The language is based on the XQuery and XPath Data Model (XDM) which uses a
tree-structured model of the information content of an XML document, containing
seven kinds of nodes: document nodes, elements, attributes, text nodes, comments,
processing instructions, and namespaces.
 Query is the query language used to query the records in the XML document. It is
similar to the SQL query in RDBMS. It is the functional language independent of the

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 51 XML

format of the XML data in the document. This can be used to query XML document,
XML database or relational database with XML data.
 XQuery has following characteristics :
o It is a functional language used to retrieve the XML data from any document
or database.
o This is similar to SQL in RDBMS, and queries / traverses XML data.
o It uses XPaths to traverse through XML data to fetch the records.
o XQuery is supported by almost all database system.
 Though the expressions that we have seen above to point to different nodes, simply
writing the expression will not give the required results. Those expressions will
simply point to the nodes specified by the expressions. It should have proper
querying to pull the values at that node. That is done by XQuery.
 Consider the below XML document of addresses of different people in US. Let the
name of the document be address.xml. Now we know that if we need to access any
node element within this document, we have to use XPath expressions. But these
expressions cannot be written within this xml document. We need to have separate
file or platform for writing the expression. That means the expressions are written
outside the address.xml file.
<Contact>
<Address Name=”Rose”>
<ApartmentNum>APT 201 </ ApartmentNum>
<Street>Lakeside Village Drive </Street>
<Town> Clinton Township </Town>
<State> MI </State>
<Country> US </Country>
</Address>
<Address Name=”William”>
<ApartmentNum>APT 671 </ ApartmentNum>
<Street>Fraser Village Drive </Street>
<Town> Fraser Township </Town>
<State> NY </State>
<Country> US </Country>
</Address>
<Address Name=”Robert”>
<ApartmentNum>APT 232 </ ApartmentNum>
<Street>Seianna Drive </Street>
<Town> Danbury </Town>
<State> CT </State>
<Country> US </Country>
</Address>
</Contact>

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 52 XML

Advantages of XQuery
 XQuery can be used to traverse both tabular as well as hierarchical data, provided
they are in XML format.
 These can be used to traverse graphical and tree like structures.
 It can be used to transform XML documents.
 It can be used to traverse and build WebPages.

FLOWR Expressions
 XQuery gives the touch of query to above expression using FLWOR – ‘For Let
Where Order By Return’. i.e.;
o for : This clause selects all the elements under the given XPath expression.
o Let : It stores the elements selected in for clause into a variable $x. In XQuery
variables starts with ‘$’ symbol.
o where : This clause is used to indicate any predicates / conditions.
o order by : This clause will sort the result set.
o return : This clause will have the elements that need to be returned.

for $x in doc (“address.xml”)/Contact/Address

where $x/State=”NY”
return $x/Street
XQuery Data Types
 XQuery shares the same data types as XML Schema 1.0 (XSD).
 XSD String
 XSD Date
 XSD Numeric
 XSD Misc
XQuery Functions
 XQuery is built on XPath expressions. XQuery 1.0 and XPath 2.0 share the same data
model and support the same functions and operators.
o XPath Operators
o XPath Functions
o XQuery lets user to define own functions
 When XQuery uses XPath expressions, it will be written outside the xml document,
in a separate file or tool. Then the expression will not have any link with the xml file
that it is accessing.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 53 XML

 In order to make the expression to access the address.xml file, XQuery uses a
function doc(). This function creates a link between the XQuery and XPath. That
means the XPath expressions are written based on the file pointed by doc() function.
doc (“file_name”)
doc (“address.xml”)

Path Expressions
 Once doc function is used, the XQuery is now pointing to the xml file that it needs
to traverse. Now it can use XPath expressions to traverse the nodes within this xml
file. i.e.;
doc (“address.xml”)/Contact/Address/Street
doc (“address.xml”)/Contact/Address[State = “NY”]
 Above expression will select all the Addresses whose state is ‘NY’. That means, it
will select whole set of details like below.
<Address Name=”William”>
<ApartmentNum>APT 671 </ ApartmentNum>
<Street>Fraser Village Drive </Street>
<Town> Fraser Township </Town>
<State> NY </State>
<Country> US </Country>
</Address>
 Suppose we have to select only particular field from above list rather than selecting
whole details, say street of each addresses in ‘NY’, then we can modify the
expression like below :
doc (“address.xml”)/Contact/Address[State = “NY”]/Street
 This expression will pull all the streets in the addresses whose state is ‘NY’. This is
how we get particular element from the xml file using XPath’s expression and
predicate. But same can be done in XQuery using same XPath expression is little
different way.

XML Technology at a glance

 XML family is popular due to its ease and interoperability across the platforms.
XML data is a key ingredient for solutions that are based on service-oriented
architecture (SOA). SOA is an architectural style whose goal is to achieve loose
coupling among interacting software agents. Hence XML technology fits perfectly
for it. In the aforesaid unit we have explored.
 XML is a family of technologies designed to be used over the Internet. Here are few
quickly revisited (Refer Fig. 1.8.1)

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 1 - 54 XML

Fig. 1.8.1 XML Technology Family

 Extensible Stylesheet Language (XSL), which in turn comprises Extensible Stylesheet

Language Transformations (XSLT).
 XSL is an XML-based language for expressing stylesheets. XSLT is a language for
transforming XML documents into (typically) other XML documents, HTML, and
WML.
 Document Type Definition (DTD). Defines the rules that constrain an XML
document or a set of XML documents.
 XML Schema, a better brother of DTDs as the primary mechanism for constraining
XML data. An XML Schema, which is itself in the format of an XML document,
serves the same function as a DTD while correcting some of its limitations.
 XLink, XPath, and XPointer together provide the foundation for creating links and
asserting relationships within and among XML documents.
 XPath, widely used by XSLT, allows users to locate specific nodes or node sets
within XML documents.


TECHNICAL PUBLICATIONS® - An up thrust for knowledge

 UNIT - II

2 Service Oriented Architecture

(SOA) Basics
Syllabus
Characteristics of SOA, Benefits of SOA, Comparing SOA with Client-Server and Distributed
architectures - Principles of Service Orientation - Service layers

Contents
2.1 Introduction
2.2 Characteristics of SOA
2.3 Benefits of SOA
2.4 Comparing SOA with Client-Server & Distributed Architectures
2.5 Principles of Service Orientation
2.6 Service Layers

(2 - 1)
Service Oriented Architecture 2-2 Service Oriented Architecture (SOA) Basics

2.1 Introduction
 Large Enterprise of business applications (e.g. Core Banking & Credit Card
System, Insurance Systems, Mobile Service Providers and many more) are
normally designed with the help of various components, providing the business
specific functionalities.
 Software architecture refers to the fundamental structures of a software system
and the discipline of creating such structures and systems. Each structure
comprises software elements, relations among them, and properties of both
elements and relations.

Fig. 2.1.1 Understanding Software Architecture

 The software architecture of a program or computing system is a depiction of the
system that aids in understanding how the system will behave.
 Software architecture serves as the blueprint for both the system and the
development project execution. The architecture is the primary carrier of system
qualities such as performance, modifiability, and security
 Hence from the Software Development and deployment perspective the style of
Software Architecture is very much influential.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-3 Service Oriented Architecture (SOA) Basics

 It is an established and generic theory of Software Architecture design that

decomposition of large enterprise problems into collection of smaller & related
pieces can be used to address a variety of business problems.
 Readers must have seen some other software architectures like multi-tier software
architecture, where each layer addresses specific operation. e.g. in 3-tier
architecture we know the presentation layer, business-logic layer and data or
resource layer.
Application Architecture

o In information systems, applications architecture or application architecture is one

of several architecture domains that form the pillars of an enterprise architecture
(EA)
o An applications architecture describes the behaviour of applications used in a
business, focused on how they interact with each other and with users. It is
focused on the data consumed and produced by applications rather than their
internal structure.
o In application portfolio management, applications are mapped to business
functions and processes as well as costs, functional quality and technical quality in
order to assess the value provided.
o The applications architecture is specified on the basis of business and functional
requirements. This involves defining the interaction between application
packages, databases, and middleware systems in terms of functional coverage.
Application architecture is to an application development team what a blueprint is
to a team of construction workers. Different organizations document different
levels of application architecture.
o A single architecture document typically represents a distinct solution
environment. For example, an organization that houses both .NET and J2EE
solutions would very likely have separate application architecture specifications
for each.
o A key part of any application-level architecture is that it reflects immediate
solution requirements, as well as long-term, strategic IT goals. It is for this reason
that when multiple application architectures exist within an organization.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-4 Service Oriented Architecture (SOA) Basics

Enterprise Architecture

o Enterprise Architecture (EA) is "a well-defined practice for conducting enterprise

analysis, design, planning, and implementation, using a comprehensive approach
at all times, for the successful development and execution of strategy.
o Enterprise architecture applies architecture principles and practices to guide
organizations through the business, information, process, and technology changes
necessary to execute their strategies.
o These practices utilize the various aspects of an enterprise to identify, motivate,
and achieve these changes.
o Practitioners of enterprise architecture, enterprise architects, are responsible for
performing the analysis of business structure and processes and are often called
upon to draw conclusions from the information collected to address the goals of
enterprise architecture.

Fig. 2.1.2
o In larger IT environments, the need to control and direct IT infrastructure is
critical. When numerous, disparate application architectures co-exist and
sometimes even integrate, the demands on the underlying hosting platforms can
be complex and onerous.
o Therefore, it is common for a master specification to be created, providing a high-
level overview of all forms of heterogeneity that exist within an enterprise, as well
as a definition of the supporting infrastructure.
Service Oriented Architecture

 Service Oriented Architecture (SOA) is also a style of software design where

services are provided to the other components by application components,

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-5 Service Oriented Architecture (SOA) Basics

through a communication protocol over a network. It is influenced by technology

and automation solutions to the large enterprise applications.
 SOA is different from other contemporary software architectures in the manner in
which it achieves separation.
 When we say an SOA based technological implementation of businesses,
important to note at this stage that automation of the business processes is a key
influence for adopting SOA.
 Hence SOA represents a model in which automation logic is decomposed into
smaller, distinct units of logic. Collectively, these units achieve complete business
automation logic, but at the same time, these distinct units are distributed
individually.
 Simply, service-oriented architecture spans both enterprise and application
architecture domains. The benefit potential offered by SOA can only be truly
realized when applied across multiple solution environments.
 Service-Oriented Architecture (SOA) is a style of Software Architecture. It is
closely connected with Large Enterprise Applications or business applications.
 In short SOA is an architectural style for building software applications that
promotes loose coupling between software components so that they can be
reused. Applications in SOA are built based on services.
Understanding SOA

 Service-oriented architecture (SOA) is a style of software design where services

are provided to the other components by application components, through a
communication protocol over a network.
 SOA is an approach that helps large enterprise / business systems remain scalable
and flexible while growing. It consists of three major implementations -
o Services - That represents self-contained business functionalities and can be
implemented using any technology on any platform.
o Infrastructure - Sometimes called as Enterprise Service Bus (ESB) that allows us
to combine these services in easy and flexible manner
o Policies and processes - That manages large distributed systems that may be
heterogeneous, may be under maintenance or may have different owners.
 Service-oriented architecture integrates distributed, separately maintained and
deployed software components. It is enabled by technologies and standards that
facilitate components' communication and cooperation over a network, especially
over an IP network.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-6 Service Oriented Architecture (SOA) Basics

Fig 2.1.3 SOA spectrum

 SOA can be seen as part of the spectrum which ranges from the older concept of
distributed computing and modular programming, through SOA, and on to
practices of mashups, SaaS (Software As A Service), and cloud computing.
 SOA is also intended to be independent of vendors, products and technologies.
Core Values of SOA

 A manifesto was published for service-oriented architecture in October, 2009.

According to it six core values of SOA are listed as follows.
1. Business value is given more importance than technical strategy.
2. Strategic goals are given more importance than project-specific benefits.
3. Intrinsic interoperability is given more importance than custom integration.
4. Shared services are given more importance than specific-purpose
implementations.
5. Flexibility is given more importance than optimization.
6. Evolutionary refinement is given more importance than pursuit of initial
perfection.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-7 Service Oriented Architecture (SOA) Basics

Service in SOA

 A SOA service is a discrete unit of functionality that can be accessed remotely and
acted upon and updated independently, such as retrieving a e-wallet statement
online.
 SOA encourages individual units of logic to exist autonomously yet not isolated
from each other. Units of logic are still required to conform to a set of principles
that allow them to evolve independently, while still maintaining a sufficient
amount of commonality and standardization. Within SOA, these units of logic are
known as services.
 A service has four properties according to one of many definitions of SOA
o It logically represents a business activity with a specified outcome.
o It is self-contained.
o It is a black box for its consumers, meaning the consumer does not have to be
aware of the service's inner workings.
o It may consist of other underlying services.
 Services encapsulate logic within a distinct context to retain their independence.
Due to this the context can for a given service may be specific to a business task, a
business entity, or some other logical grouping.
 The concern addressed by a service can be small or large. Hence the size and
scope of the logic for the given service can vary. Further, service logic can
encompass the logic provided by other services. They are referred as collective
services when composed of many smaller services together.
 Different services can be used in conjunction to provide the functionality of a
large software application, a principle SOA shares with modular programming.
Logic encapsulation by Services

 Services encapsulate business logic within a distinct context. The context can be
specific to a business task, a business entity, or some other logical grouping. This
helps in retaining their independence within the system.
 The concern addressed by a service can be small or large. Hence the size and
scope of the service can be different. Also, the service logic of one service can
include logic provided by other services. In such scenario, it is referred as
collective service.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-8 Service Oriented Architecture (SOA) Basics

 A service can even encapsulate the entire process logic. In the latter two cases, the
larger scope represented by the services may encompass the logic encapsulated by
other services.
 Example : Building Automation Solutions using SOA.
o Business automation solutions are typically an implementation of a business
process.
o This process is comprised of logic that dictates the actions performed by the
solution. The logic is decomposed into a series of steps that execute in
predefined sequences according to business rules and runtime conditions.
o When building an automation solution consisting of services, each service can
encapsulate a task performed by an individual step or a sub-process comprised
of a set of steps.

Fig. 2.1.4 Different logics are implemented by different services within a process block

 The execution of business activities can be run as a service that use the logic and
also encapsulate included services. For this the including service they must form
distinct relationships with those services that want to use them.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2-9 Service Oriented Architecture (SOA) Basics

Awareness between services

 Within SOA, services can be used by other services or other programs. For this it
is mandatory for services to be aware about existence of other services. For this
purpose, Service descriptions are used.
 A service description establishes the name of the service and the data expected
and returned by the service. In SOA a service use other services in a loosely
coupled manner.
 Services must exchange information in order to interact and accomplish a
meaningful business task. Hence SOA needs a communications framework that
can achieve their loosely coupled relationship. Messaging framework is used to
achieve the communication between services.
 Refer Fig. 2.1.5 below. It shows that service A is aware of service B because it
holds service B’s service description.

Fig. 2.1.5 Awareness between services

Communication between services

 In SOA, communication between services is achieved through messages. These

messages exist as independent units of communication. This means that
messages, like services, should be autonomous. Hence, messages can be equipped
with enough intelligence to self-govern their parts of the processing logic.
(Refer Fig. 2.1.6).
 The services that provide service descriptions and the services that communicate
via messages form a basic architecture for SOA.
 This architecture appears similar to distributed architectures that support
messaging and a separation of interface from processing logic. However, SOA
differs from distributed architectures in the way how services, descriptions, and
messages are designed.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 10 Service Oriented Architecture (SOA) Basics

Fig. 2.1.6 Example of self-governing messages

Designing services

 Service-orientation is a distinct design approach that introduces commonly

accepted principles. These principles govern the positioning and design of our
architectural components in SOA.
 When service-oriented principles are applied to processing logic it results in
standardized service-oriented processing logic. Similarly, when a business
solution is comprised of units of service-oriented processing logic, it becomes a
service-oriented solution.

Fig. 2.1.7 Service-Oriented Principles

 Following are the popular service-oriented principles -

o Loose coupling - Services maintain a relationship that minimizes dependencies
and only requires that they retain an awareness of each other.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 11 Service Oriented Architecture (SOA) Basics

o Service contract - Services adhere to a communications agreement, as defined

collectively by one or more service descriptions and related documents.
o Autonomy - Services have control over the logic they encapsulate.
o Abstraction - Beyond what is described in the service contract, services hide
logic from the outside world.
o Reusability - Logic is divided into services with the intention of promoting
reuse.
o Composability - Collections of services can be coordinated and assembled to
form composite services.
o Statelessness - Services minimize retaining information specific to an activity.
o Discoverability - Services are designed to be outwardly descriptive so that
they can be found and assessed via available discovery mechanisms.
 To build service-oriented automation solutions on the basis of above service
oriented principles, an implementation platform is required that allows to bring
all these services together. The Web services technology is a good example of an
implementation platform for SOA.
Building services

 Web services can make the functional building-blocks accessible over standard
Internet protocols that are independent of platforms and programming languages.
 These services can represent either new applications or just wrappers around
existing legacy systems to make them network-enabled.
 Following are the major vendor platforms currently support the creation of
service-oriented solutions -
o Web services based on WSDL and SOAP (Simple Object Access Protocol)
o Messaging, e.g., with ActiveMQ, JMS, RabbitMQ
o RESTful HTTP, with Representational state transfer (REST) constituting its own
constraints-based architectural style
o OPC-UA (OPC Unified Architecture)
o WCF (Microsoft's implementation of Web services, forming a part of WCF)
o Apache Thrift
o gRPC (gRPC Remote Procedure Calls)
o SORCER (A distributed computing platform implemented in Java.)

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 12 Service Oriented Architecture (SOA) Basics

Primitive SOA

 SOA is a constantly growing field with various vendors developing SOA products
regularly.
 A baseline service-oriented architecture that is suitable to be realized by any
vendor is known as the primitive SOA.
 The fundamental characteristics of service encapsulation, loose-coupling, and
messaging, service-orientation principles and the Web services technology
together satisfy the implementation of a primitive SOA. Refer Fig. 2.1.8.

Fig. 2.1.8 Primitive SOA components

 However, despite the choice of technology platform and product vendor,

primitive SOA should satisfy the following properties.
o The ability for business automation logic to be partitioned into units so as to
properly represent services.
o The ability for these units of logic to be relatively independent of each other so
as to support the requirement for them to participate in different compositions.
o The ability for these units of logic to communicate with each other in such a
manner that their respective independence is preserved.

Note : In the next section we will discuss about the contemporary SOA.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 13 Service Oriented Architecture (SOA) Basics

2.2 Characteristics of SOA

 With the growing trend of digitization of businesses, created an opportunity to
bring out the SOA for business and enterprise applications to run the business.
Here running the business digitally means providing the business services and
creating the business processes for the same.
 For example, a traditional business of air travel booking was accessible to only
few like airline companies, travel companies and travel agents. But now the
business has implemented complete digitalization. As a result of this even a
commoner is able to schedule air travel based of destination and flight availability
from all airlines. Not limited to this one can book using various payment options
like bank payments, credit cards, UPIs, digital wallets etc. and can even cancel it.
And all this is available on fingertips using smartphones, laptops etc.
Contemporary SOA

 Because many opportunities in digitization of businesses and changing industry

trends, SOA based developments have shaped from primitive to contemporary
SOA. The result is an extended variation of service-oriented architecture is
referred as contemporary SOA.
 Broader spectrum of digitization is possible by implementing Contemporary SOA
that provides discrete yet bound functionalities called services.
 However, the founding principles of contemporary SOA remain same as primitive
SOA.
 Contemporary SOA is a complex and sophisticated architectural platform that
offers significant potential to solve many historic and current IT problems.
 By leveraging existing paradigms and technologies that support its overall vision,
contemporary SOA achieves this potential.
 There are some leading software vendors that are continuously involved in
developing new Web services specifications and more powerful XML and Web
services support into existing SOA suits.
 Here are the three primary influences of contemporary SOA. (Refer Fig. 2.2.1)
o First-generation Web services concepts
o Second-generation (WS-*) Web Services concepts
o Principles of service-orientation
Apart from these three fundamental XML concepts is another influencing factor.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 14 Service Oriented Architecture (SOA) Basics

Fig. 2.2.1 External influences of contemporary SOA

 The primary external influences that shape and affect contemporary SOA are first-
and second-generation Web services specifications and the principles of service-
orientation.

Characteristics of Contemporary SOA

 Contemporary SOA builds upon the primitive SOA model by predominance of
industry and technology advancements.
 Though implementation technology may be different, contemporary SOAs can be
associated with a set of common characteristics. There are nineteen such common
characteristics of contemporary SOA are as shown in Fig. 2.2.2.

Fig. 2.2.2 Common characteristics of contemporary SOA

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 15 Service Oriented Architecture (SOA) Basics

 Here is a brief description of what these common characteristics of contemporary

SOA are -
o Contemporary SOA is at the core of the service-oriented computing platform.
o This key characteristic is supported by orchestration, although not
automatically. WS -* specifications, such as WS-BPEL, provide a dialect capable
of expressing business process logic in an operational syntax resulting in a
process definition. Only through deliberate design, though, can these types of
process definitions actually be utilized to support service-oriented business
modeling.
o Contemporary SOA increases quality of service.
o Contemporary SOA evolved due to the need to implement enterprise-level
functionality. Hence it inherently should support QoS such as safely and
reliably. This relates to common quality of service requirements, such as :
 The ability for tasks to be carried out in a secure manner, protecting the
contents of a message, as well as access to individual services.
 Allowing tasks to be carried out reliably so that message delivery or
notification of failed delivery can be guaranteed.
 Performance requirements to ensure that the overhead imposed by SOAP
message and XML content processing does not inhibit the execution of a
task.
 Transactional capabilities to protect the integrity of specific business tasks
with a guarantee that should the task fail, exception logic is executed.
o The quality of service improvements provided by contemporary SOA are, for
the most part, realized via vendor implementations of individual WS -*
extensions.
 Contemporary SOA is fundamentally autonomous -
o The service-orientation principle of autonomy requires that individual services
be as independent and self-contained as possible with respect to the control
they maintain over their underlying logic.
o For example, message-level autonomy in SOA should be sufficiently intelligent
to control when processed by recipient services.
o Autonomy is one of the core service-orientation principles that can be applied
to numerous parts of SOA. Pursuing autonomy when building and assembling
service logic supports other SOA characteristics.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 16 Service Oriented Architecture (SOA) Basics

o Because contemporary SOA is built building upon and extending the primitive
SOA model, Contemporary SOA represents an architecture that promotes
service-orientation through the use of Web services.
 Contemporary SOA is based on open standards -
o This is a natural by-product of basing SOA on the Web services technology
platform and its ever-growing collection of WS -* specifications. The majority of
Web services specifications are open and vendor-neutral.
o It is the most significant characteristic of Web services is the fact that data
exchange is governed by open standards.
o After a message is sent from one Web service to another it travels via a set of
protocols that is globally standardized and accepted.
o Further, the message itself is standardized, both in format and in how it
represents its payload.
o The use of SOAP, WSDL, XML, and XML Schema allow for messages to be
fully self-contained and support the underlying agreement that to
communicate, services require nothing more than knowledge of each other’s
service descriptions.
o The use of an open, standardized messaging model eliminates the need for
underlying service logic to share type systems and supports the loosely
coupled paradigm.
o Contemporary SOAs fully leverage and reinforce this open, vendor-neutral
communications framework (Refer Fig. 2.2.3).

Fig. 2.2.3 Contemporary SOA supports open, vendor-neutral communications framework

o An SOA limits the role of proprietary technology to the implementation and

hosting of the application logic encapsulated by a service.
 Contemporary SOA supports vendor diversity -
o The open communications framework allows organizations to choose best
suitable technology environments for specific applications.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 17 Service Oriented Architecture (SOA) Basics

o For example, regardless of proprietary a development environment if it

supports the creation of standard Web services, it can be used to create a
non-proprietary service interface layer.
o This opens up interoperability opportunities with other, service capable
applications. (Refer Fig. 2.2.4)
o It has greatly influenced integration architectures that can encapsulate legacy
logic through service adapters, and utilize middleware advancements based on
Web services.
o This is really more of a benefit of SOA than an actual characteristic. Regardless,
it is primarily realized through the use of the open standards provided by the
Web services platform.

Fig. 2.2.4 Vendor diversity in Contemporary SOA

 Contemporary SOA fosters intrinsic interoperability -

o Regardless of whether an application actually has immediate
o Integration requirements, design principles can be applied to outfit services
with characteristics that naturally promote interoperability.
o The standardized communications framework provided by Web services
establishes the potential to foster limitless interoperability between services.
o To foster intrinsic interoperability among services requires forethought and
good design standards.
o Fosters intrinsic interoperability manages cost in long run and fulfills future
cross-application integration requirements.
o Although supported by a number of WS-* specifications, this characteristic is
not directly enabled by our identified influences.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 18 Service Oriented Architecture (SOA) Basics

Fig. 2.2.5 Intrinsically interoperable services of SOA

 Contemporary SOA promotes discovery -

o Service-level discoverability is one of our fundamental principles of service-
orientation. Implementing discoverability on an SOA level typically requires
the use of directory technologies, such as UDDI (one of the first-generation
Web services specifications).
o Few of the early implementations of SOA actually used service registries as
part of their environments.
o SOA supports and encourages the advertisement and discovery of services
throughout the enterprise and beyond.
o A serious SOA relies on some form of service registry or directory to manage
service descriptions.

Fig. 2.2.6 Registry for discovery of services

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 19 Service Oriented Architecture (SOA) Basics

 Contemporary SOA promotes federation -

o One of the most attractive aspects of SOA is its ability to introduce unity across
previously non-federated (or non-associated) environments.
o Federation is a state achieved by extending SOA into the realm of service-
oriented integration.
o A number of key WS -* extensions provide feature-sets that support the
attainment of federation.
o While Web services enable federation, SOA promotes it by establishing and
standardizing the ability to encapsulate legacy and non-legacy application logic
and by exposing it via a common, open, and standardized communications
framework.

Fig. 2.2.7 Federation of SOA

o The incorporation of SOA with previous platforms can lead to a variety of

hybrid solutions. The communication channels achieved by this form of
service-oriented integration are all uniform and standardized.
 Contemporary SOA promotes architectural composability-
o Composability is a deep-rooted characteristic of SOA that can be realized on
different levels.
o SOA supports the automation of flexible and highly adaptive business
processes.
o A business process can therefore be broken down into a series of services, each
responsible for executing a portion of the process.
o A broader example of composability is represented by the second-generation
Web services framework that is evolving out of the release of the numerous
WS-* specifications.
o While composability, on a service level, is one of our service-orientation
principles, for architecture to be considered composable requires that the
technology from which the architecture is built support this notion.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 20 Service Oriented Architecture (SOA) Basics

o For the most part, the specifications that comprise the WS-* landscape fully
enable architectural composability by allowing a given SOA to only implement
extensions it actually requires.

Fig. 2.2.8 Architectural composability of SOA

o Different solutions can be composed of different extensions and can continue to

interoperate as long as they support the common extensions required.
 Contemporary SOA fosters inherent reusability -
o Reusability is one of the primary principles of service-orientation and one that
can be applied across service-oriented solution environments.
o SOA promotes the creation of inherently reusable service logic within
individual services and across service compositions a benefit attainable
through quality service design.
o SOA establishes an environment that promotes reuse on many levels. Hence,
inherent reuse can be fostered when building service-oriented solutions.
o Collections of services that form service compositions can themselves be reused
by larger compositions.
o The emphasis placed by SOA on the creation of services that are agnostic to
both the business processes and the automation solutions that utilize them
leads to an environment in which reuse is naturally realized as a side benefit to
delivering services.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 21 Service Oriented Architecture (SOA) Basics

Fig. 2.2.9 Inherent reusability of SOA

 Contemporary SOA emphasizes extensibility -

o Given that Web services are composable and based on open standards,
extensibility is a natural benefit of WS platform. Several WS-* extensions
introduce architectural mechanisms that build extensibility into a solution.
o Extensibility is also a characteristic that is promoted throughout SOA as a
whole.
o Extending entire solutions can be accomplished by adding services or by
merging with other service-oriented applications.
o In SOA the loosely coupled relationship fostered among all services. It
minimizes inter-service dependencies. As a result of it extending logic can be
achieved with significantly less impact.
o Contemporary SOA represents an open, extensible, federated, composable
architecture that promotes service-orientation and is comprised of autonomous,
QoS-capable, vendor diverse, interoperable, discoverable, and potentially
reusable services, implemented as Web services.

Fig. 2.2.10 Extensibility of services in SOA

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 22 Service Oriented Architecture (SOA) Basics

 Contemporary SOA supports a service-oriented business modelling paradigm -

o Partitioning business logic into services that can then be composed has
significant implications as to how business processes can be modelled.
o Analysts can leverage these features by incorporating an extent of service-
orientation into business processes for implementation through SOAs.
o Services in SOA can be designed to express business logic. BPM models, entity
models, and other forms of business intelligence can be accurately represented
through the coordinated composition of business-centric services.
o This key characteristic is supported by orchestration, although not
automatically. WS -* specifications, such as WS-BPEL, provide a dialect capable
of expressing business process logic in an operational syntax resulting in a
process definition.
o Only through deliberate design, though, can these types of process definitions
actually be utilized to support service-oriented business modelling.

Fig. 2.2.11 Service Oriented Business Process Modelling (BPM)

 Contemporary SOA implements layers of abstraction -

o One of the characteristics that tend to evolve naturally through the application
of service-oriented design principles is that of abstraction.
o Typical SOAs can introduce layers of abstraction by positioning services as the
sole access points to a variety of resources and processing logic.
o When applied through proper design, abstraction can be targeted at business
and application logic.
o It is the mutual abstraction of business and technology that supports the
service-oriented business modelling paradigm establishes the loosely coupled
enterprise model.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 23 Service Oriented Architecture (SOA) Basics

o Service-orientation principles fully promote black box-type abstraction on a

service interface level. However, to coordinate logic abstraction into layers,
services must be designed and organized according to specific design
standards.

Fig. 2.2.12 Layers of abstraction in SOA

 Contemporary SOA promotes loose coupling throughout the enterprise –

Fig. 2.2.13 Loose coupling between business logic and application technology

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 24 Service Oriented Architecture (SOA) Basics

o A core benefit to building a technical architecture with loosely coupled services

is the resulting independence of service logic. Services only require an
awareness of each other, allowing them to evolve independently.
o Within an organization where service-orientation principles are applied to both
business modelling and technical design, the concept of loose coupling is
amplified.
o By implementing standardized service abstraction layers, a loosely coupled
relationship also can be achieved between the business and application
technology domains of an enterprise.
o This can accommodate business and technology-related change i.e.
organizational agility.
 Contemporary SOA promotes organizational agility -

Fig. 2.2.14 Response to organizational agility by SOA

o Change in an organization’s business logic can impact the application
technology that automates it. Change in an organization’s application

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 25 Service Oriented Architecture (SOA) Basics

technology infrastructure can impact the business logic automated by this

technology.
o The more dependencies that exist between these two parts of an enterprise, the
greater the extent to which change imposes disruption and expense.
o Whether the result of an internal reorganization, a corporate merger, a change
in an organization’s business scope, or the replacement of an established
technology platform, an organization’s ability to accommodate change
determines the efficiency with which it can respond to unplanned events.
o SOA offers the potential to increase organizational agility, by leveraging
service business representation, service abstraction, and the loose coupling
between business and application logic.
o Though the use of Web services, service-orientation principles, and WS -*
specifications support the concept of increasing an organization's agility, they
do not directly enable it. This important characteristic requires dedicated
analysis and design and relies on the realization of other SOA characteristics.
o Organizational agility is the most significant benefit that can be realized with
contemporary SOA.
 Contemporary SOA is a building block -
o Service-oriented application architecture will likely be one of several within an
organization committed to SOA as the standard architectural platform.
o Organizations standardizing on SOA work toward an ideal known as the
Service-Oriented Enterprise (SOE), where all business processes are composed
of and exist as services, both logically and physically.
o When viewed in the context of SOE, the functional boundary of an SOA
represents a part of this future-state environment,
 As a standalone unit of business automation
 As a service encapsulating some or all of the business automation logic
o SOA can establish an abstraction of business logic and technology that may
introduce changes to business process modelling and technical architecture,
resulting in a loose coupling between these models.
o These changes foster service-orientation in support of a service-oriented
enterprise.
 Contemporary SOA is an evolution -
o SOA defines an architecture that is related to but still distinct from its
predecessors.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 26 Service Oriented Architecture (SOA) Basics

o It differs from traditional client-server and distributed environments in that it

is heavily influenced by the concepts and principles associated with service-
orientation and Web services.
o It is similar to previous platforms in that it preserves the successful
characteristics of its predecessors and builds upon them with distinct design
patterns and a new technology set.
 Contemporary SOA is still maturing -
o Even though SOA is being positioned as the next standard application
computing platform, this transition is not yet complete.
o Despite the fact that Web services are being used to implement a great deal of
application functionality, the support for a number of features necessary for
enterprise-level computing is not yet fully available.
o Standards organizations and major software vendors have produced many
specifications to address a variety of supplementary extensions.
o Additionally, the next generation of development tools and application servers
promises to support a great deal of these new technologies.
o When SOA platforms and tools reach an adequate level of maturity, the
utilization of Web services can be extended to support the creation of
enterprise SOA solutions, making the ideal of a service-oriented enterprise
attainable.
 Contemporary SOA is an achievable ideal -
o A standardized enterprise-wide adoption of SOA is a state to which many
organizations would like to fast-forward.
o The reality is that the process of transitioning to this state demands an
enormous amount of effort, discipline, and, depending on the size of the
organization, a good amount of time.
o As companies adopt SOA during this evolution, many will need to retrofit their
environments (and their standards) to accommodate changes and innovations
as SOA-related specifications, standards, and products continue to mature.
Defining SOA
 Here is a set of some formal definitions of SOA based on the characteristics in this
unit. These are –
o Contemporary SOA represents an open, agile, extensible, federated,
composable architecture comprised of autonomous, QoS-capable, vendor
diverse, interoperable, discoverable, and potentially reusable services,
implemented as Web services.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 27 Service Oriented Architecture (SOA) Basics

o SOA can establish an abstraction of business logic and technology that may
introduce changes to business process modelling and technical architecture,
resulting in a loose coupling between these models.
o SOA is an evolution of past platforms, preserving successful characteristics of
traditional architectures, and bringing with it distinct principles that foster
service-orientation in support of a service-oriented enterprise.
o SOA is ideally standardized throughout an enterprise, but achieving this state
requires a planned transition and the support of a still evolving technology set.
 A supplementary definition that can be applied to both primitive and
contemporary SOA is as follows -
o SOA is a form of technology architecture that adheres to the principles of
service-orientation. When realized through the Web services technology
platform, SOA establishes the potential to support and promote these
principles throughout the business process and automation domains of an
enterprise
Separating concrete characteristics
 After removing the concrete SOA characteristics that are directly supported or
provided by identified external influences (Refer Fig. 2.2.1), here are the four
remaining characteristics of contemporary SOA. These are -
o Enterprise-wide loose coupling
o Support for service-oriented business modelling
o Organizational agility
o Layers of abstraction
 Incorporating the key qualities into SOA requires that some very fundamental
decisions be made, long before the building process of individual services
commence.
Relevance of SOA
 The primary goal of Service Oriented Architecture is to align business users with
Information Technologies (IT).
 Service-Oriented Architecture (SOA) enables increased business agility, improved
business workflows, extensible architecture, enhanced reuse, and a longer life
span of applications.
 Adopting Service Oriented Architecture realize many benefits.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 28 Service Oriented Architecture (SOA) Basics

2.3 Benefits of SOA

 IT community has been through and continuing to go through the effort of
changing its philosophy and technology in an effort to adopt SOA for businesses.
Definitely there are clear in adapting SOA. These benefits are articulated in a
thought process as follows -
o How SOA leads to improvements in automated solution construction
o How the proliferation of service-orientation ends up benefiting the enterprise
as a whole
 SOA benefits organizations in different ways, depending on their respective goals
and the manner in which SOA and its supporting cast of products and
technologies is applied. This list of common benefits is generalized and not
limited. It is just an indication of the potential that SOA can offer.

Fig. 2.3.1 Pictorial representation of SOA Benefits

Let’s discuss the benefits of SOA in details as follows -

 Improved integration (and intrinsic interoperability)
o SOA influences creation of solutions that consist of inherently interoperable
services.
o Utilizing solutions based on interoperable services is part of service-oriented
integration (SOI). This results in service-oriented integration architecture.
o Because of the vendor-neutral communications framework established by Web
services, it leads to the potential for enterprises to implement highly
standardized service descriptions and message structures.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 29 Service Oriented Architecture (SOA) Basics

o As a result of it, SOA based solution achieve intrinsic interoperability, and

cross-application integration. This enables the project into less of a custom
development effort, and more of a modelling exercise.
o The cost and effort of cross-application integration is significantly lowered
when applications being integrated are SOA-compliant.

Fig. 2.3.2 Integration & Interoperability benefit of SOA

 Inherent reuse
o Service-orientation promotes the design of services that are inherently reusable.
o Building service-oriented solutions fulfill immediate application-level
requirements. It supports a degree of reuse by future potential requestors.
o It also establishes an environment wherein investments into existing systems
can be leveraged and re-leveraged as new solutions.
o Building services to be inherently reusable results in a moderately increased
development effort and requires the use of design standards.
o Subsequently leveraging reuse within services lowers the cost and effort of
building service-oriented solutions.
o SOA compliance to web services and hence applications running on either
platform can also consume services running on the other as web services that
facilitate reuse.
o Properly designed implemented SOA application provide infrastructure that
makes reuse possibilities in heterogeneous environment such as C, C++,Java,
.Net etc.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 30 Service Oriented Architecture (SOA) Basics

o Managed environments can also wrap COBOL legacy systems and present
them as services. This has extended the useful life of many core legacy systems
indefinitely, no matter what language they originally used.

Fig. 2.3.3 Inherent re-use of SOA

 Streamlined architectures and solutions

o Common characteristics of contemporary SOA is a key enabler for SOA. Hence
it can lead to highly optimized automation environments, where only the
technologies required actually become part of the architecture.
o Realizing this benefit requires adherence to design standards that govern
allowable extensions within each application environment.
o Benefits of streamlined solutions and architectures include the potential for
reduced processing overhead and reduced skill-set requirements.
 Leveraging the legacy investment
o The industry-wide acceptance of the Web services technology set has spawned
a large adapter market, enabling many legacy environments to participate in
service-oriented integration architectures.
o This allows IT departments to work toward a state of cooperation. As a result,
previously isolated environments now can interoperate without requiring the
development of expensive and sometimes fragile point-to-point integration
channels.
o Though still riddled with risks relating mostly to how legacy back-ends must
cope with increased usage volumes, the ability to use what you already have
with service-oriented solutions that you are building now and in the future is
extremely attractive.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 31 Service Oriented Architecture (SOA) Basics

o Hence the cost and effort of integrating legacy and contemporary solutions is
lowered. The need for legacy systems to be replaced is potentially lessened.
 Establishing standardized XML data representation
o On its most fundamental level, SOA is built upon and driven by XML. As a
result, an adoption of SOA leads to the opportunity to fully leverage the XML
data representation platform.
o A standardized data representation format (once fully established) can reduce
the underlying complexity of all affected application environments.
o Some of such examples include :
 XML documents and accompanying XML Schemas (packaged within
SOAP messages) passed between applications or application components
fully standardize format and typing of all data communicated. The result
is a predictable and therefore easily extensible and adaptable
communications network.
 XML’s self-descriptive nature enhances the ability for data to be readily
interpreted by architects, analysts, and developers. The result is the
potential for data within messages to be more easily maintained, traced,
and understood.
 The standardization level of data representation lays the groundwork for
intrinsic interoperability. Specifically, by promoting the use of
standardized vocabularies, the need to translate discrepancies between
how respective applications have interpreted corporate data models is
reduced.
o With contemporary SOA, establishing XML data representation architecture
becomes a necessity, providing organizations the opportunity to achieve a
broad level of standardization.
o Hence the cost and effort of application development is reduced after a
proliferation of standardized XML data representation is achieved.
 Focused investment on communications infrastructure
o Because Web services establish a common communications framework for
SOA, SOA can centralize inter-application and intra-application
communication as part of standard IT infrastructure.
o This allows organizations to evolve enterprise-wide infrastructure by investing
in a single technology set responsible for communication.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 32 Service Oriented Architecture (SOA) Basics

o As a result, the cost of scaling communications infrastructure is reduced, as

only one communications technology is required to support the federated part
of the enterprise.
 “Best-of-breed” alternatives
o A key feature of service-oriented enterprise environments is the support of
“best-of-breed” technology.
o Because SOA establishes a vendor-neutral communications framework, it frees
IT departments from being chained to a single proprietary development and/or
middleware platform.
o The potential scope of business requirement fulfillment increases, as does the
quality of business automation.
 Organizational agility
o Agility is a quality inherent in just about any aspect of the enterprise. A simple
algorithm, a software component, a solution, a platform, a process - all of these
parts contain a measure of agility related to how they are constructed,
positioned, and leveraged.
o Much of service-orientation is based on the assumption that what you build
today will evolve over time. One of the primary benefits of a well-designed
SOA is to protect organizations from the impact of this evolution.
o Through proper design and standardization, the predictability of reuse and
interoperability within the enterprise leads to a reliable level of organizational
agility.
o A standardized technical environment comprised of loosely coupled,
composable, and interoperable and potentially reusable services establishes a
more adaptive automation environment that empowers IT departments to
more easily adjust to change. Interesting to know SOA facilitates all these
qualities.
o By abstracting business logic and technology into specialized service layers,
SOA can establish a loosely coupled relationship between these two enterprise
domains. This allows each domain to evolve independently and adapt to
changes imposed by the other.
o As a result, with SOA the cost and effort to respond and adapt to business or
technology related change is reduced.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 33 Service Oriented Architecture (SOA) Basics

Disadvantages
 SOA is not considered suitable for applications with GUI functionalities. Those
applications become more complex if they use SOA which requires heavy data
exchange. Also application requiring asynchronous communication can’t make
use of SOA. Also in case of standalone and short lived applications’
implementations, SOA will become an added burden.

2.4 Comparing SOA with Client-Server & Distributed Architectures

 Before we jump into comparing SOA with other traditional software architectures
like Client server and Distributed architecture, let’s first understand how these
systems evolved with technology advancements over the time.

Comparing with Client Server Architecture

 Client-Server Architecture Timeline

Fig. 2.4.1 Single tier Client Server Architecture

o About any environment in which one piece of software requests or receives
information from another can be referred to as “client-server.”

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 34 Service Oriented Architecture (SOA) Basics

o The industry term “client-server architecture” generally refers to a particular

generation of early environments (early 70s and 80s) during which the client
and the server played specific roles and had distinct implementation
characteristics.
o The original monolithic mainframe systems that empowered organizations to
get seriously computerized often are considered the first inception of
client-server architecture.
o Heavy mainframe back-ends served thin clients, are considered an
implementation of the single-tier client-server architecture.
o A new approach was introduced in late 80s, of delegating logic and processing
duties onto individual workstations, resulting in the birth of the fat client.
o It was also supported by the innovation of the Graphical User-Interface (GUI),
resulting in two-tier client-server architecture.
o This architecture had multiple fat clients, each with its own connection to a
database on a central server.

Fig. 2.4.2 Two tier Client Server Architecture

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 35 Service Oriented Architecture (SOA) Basics

o Client-side software performed the bulk of the processing, including all

presentation-related and most data access logic. (Refer Fig. 2.4.2).
o At this level of evolution of client-server architecture, we can compare the
primary characteristics of the two-tier client-server architecture with
corresponding parts of SOA. The comparison characteristics are -
 Application processing (inclusive of Processing Load, Database
Connectivity, Processing Cost, Communication)
 Technology
 Security
 Administration
 Client-Server Architecture Vs. SOA

Client-Server Architecture @ 2 Service Oriented Architecture

Tier

Application logic resides in the Processing in SOA is highly

client component; the client distributed. Each service has an
workstation is responsible for the explicit functional boundary and
Processing Load bulk of the processing with the related resource requirements.
database server typically
There is, therefore, no fixed
performing twenty percent of the
processing ratio for SOAs.
work.

With a large user-base generally It consists of multiple servers

requires that each client establish its supporting middleware for pooled
Database Connectivity
own / dedicated database database connections.
connection.

Proprietary database connections Because of the load balancing

are expensive, and the resource factor, services can be provided
Processing Cost demands sometimes overwhelm virtually without bottleneck.
database servers, imposing
processing latency on all users.

Communication is predictably Communication between service

synchronous, and these connections and requestor can be synchronous
are often persistent. or asynchronous.
When asynchronous message
patterns are utilized, it is more
Communication
streamlined
It promotes the stateless and
autonomous nature of services by
reducing the need for runtime
caching of state information.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 36 Service Oriented Architecture (SOA) Basics

The emergence of client-server In addition to the technology set

applications promoted the use of provided by client server
4GL programming languages, such architecture, SOA is supported by
as Visual Basic and PowerBuilder. standard set of Web technologies
(HTML, CSS, HTTP, etc.)
On the back-end, major database
Technology vendors, such as Oracle, Informix, Contemporary SOA brings an XML
IBM, Sybase, and Microsoft, data representation architecture be
provided robust RDBMSs that could established, along with a SOAP
manage multiple connections, while messaging framework, and a
providing flexible data storage and service architecture comprised of
data management features. the ever-expanding Web services
platform.

Security is centralized at the server Security is more significantly

level for database to protect data, complexity and is directly relational
safeguard data models & manage to the degree of security measures
user accounts. required.
Security is enabled for the client Multiple technologies are typically
Security executable that relates to specific involved, many of which comprise
business rules that dictate the the WS-Security framework.
execution of application logic.
Additionally, operating system-level
security can be incorporated to
achieve a single sign-on.

It has increasingly large Service-oriented solutions can have

maintenance costs associated with a variety of requestors; they are not
the distribution and maintenance of necessarily immune to client-side
application logic across user maintenance challenges. While their
workstations. distributed back-end does
accommodate scalability for
Maintenance issues spanned both
application.
client and server ends. Client
workstations were subject to Once SOAs evolve to a state where
Administration
environment-specific problems services are reused and become part
because different workstations may of multiple service compositions,
have different software programs the management of server resources
from one or many vendors and service interfaces can require
powerful administration tools,
There is an increased server-side
including the use of a private
demand on databases, especially
registry.
when a client-server application
expands to a larger user base.

 SOA is a radical departure from client-server architecture. Current SOAs still

employ some of the technologies originally used to build client-server
applications. Though more sophisticated, SOAs introduce complexity that sharply
contrasts the simplicity of two-tier client-server architecture.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 37 Service Oriented Architecture (SOA) Basics

Comparing with Distributed Internet Architecture

 Distributed Internet Architecture Timeline
o Multi-tier client-server architectures surfaced, in response to the costs and
limitations associated with the two-tier client server architecture. It brought out
component-based applications with newly evolved object-oriented technology.
(Refer Fig. 2.4.3)
o Distributing application logic among multiple components (few on client,
others on the server) reduced deployment headaches by centralizing a greater
amount of the logic on servers.
o Server-side components, now located on dedicated application servers, would
then share and manage pools of database connections, greatly improving
concurrent usage.

Fig. 2.4.3 Multi-tier client server architecture

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 38 Service Oriented Architecture (SOA) Basics

o This paradigm shifted expense and effort from deployment issues to

development and administration processes.
o Building components capable of processing multiple, concurrent requests were
more complex than a straight-forward executable intended for a single user.
o RPC technologies such as CORBA and DCOM allowed for remote
communication between components residing on client workstations and
servers.
o There was an increased maintenance effort resulting from the introduction of
the middleware layer.
o In the mid-to-late 90s, the arrival of the WWW as a viable medium for
computing technology, the multi-tiered client-server environments began
incorporating Internet technology.

Fig. 2.4.4 Distributed Internet Architecture

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 39 Service Oriented Architecture (SOA) Basics

o It replaced the custom software client component with the browser and
radically alters user-interface design, with major shift of application logic to the
server.
o With the development of www, Hyper Text Transport Protocol (HTTP)
replaced the proprietary RPC protocols used to communicate between the
user’s workstation and the server.
o From the late 90s to the mid-2000s, distributed Internet architectures
represented the default and most popular computing platform for custom
developed enterprise solutions.
• Distributed Internet Architecture vs. SOA
The comparison of SOA provided in this section is with traditional distributed
Internet architecture in the manner in which these are commonly designed.
Distributed Internet Architecture Service Oriented Architecture

Distributed Internet applications From a physical perspective,

place all of their application logic on service-oriented architecture is very
the server side. Client-side scripts similar to distributed Internet
intended to execute in response to architecture.
events on a Web page are
Provider logic resides on the server
downloaded from the Web server
end where it is broken down into
upon the initial HTTP request.
separate units.
No logic exists on the client
However, the entire modelling
workstation as the entire solution is
approach now takes into
centralized. The emphasis is
consideration the creation of
therefore on:
services that encapsulate some or
 How application logic should be all of these components. These
services are designed according to
partitioned ?
service-orientation principles and
Application Logic  Where the partitioned units of are strategically positioned to
processing logic should reside ? expose specific sets of functionality.
 How the units of processing The purpose of wrapping
logic should interact ? functionality within a service is to
expose that functionality via an
Traditional distributed applications
open, standardized interface -
consist of a series of components
irrespective of the technology used
that reside on one or more
to implement the underlying logic.
application servers.
The standardized interface supports
Components residing on the same the open communications
server communicate via proprietary framework that sits at the core of
APIs, as per the public interfaces SOA.
they expose. RPC protocols are used
The messaging framework used by
to accomplish the same
SOA is more sophisticated, bulkier,
communication across server
and tends to result in less
boundaries. This design-time

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 40 Service Oriented Architecture (SOA) Basics

dependence is a form of tight- individual transmissions.

coupling.
SOA fosters reuse and cross-
The messaging is taken care by application interoperability on a
though SOAP (Simple Object Access deep level by promoting the
Protocol) that supports RPC creation of solution-agnostic
(Remote Procedure Calls) services.

Distributed Internet architecture SOA, on the other hand, relies on

promotes the use of proprietary message-based communication.
communication protocols, such as
This involves the serialization,
DCOM and vendor
transmission, and deserialization of
implementations of CORBA for
SOAP messages containing XML
remote data exchange.
document payloads.
These technologies are considered
Processing steps can involve :
relatively efficient and reliable,
especially once an active connection  The conversion of relational
is made. data into an XML-compliant
They can support the creation of structure
stateful and stateless components
 The validation of the XML
that primarily interact with
synchronous data exchanges document prior and subsequent
(asynchronous communication is to transmission
supported by some platforms but  The parsing of the document
not commonly used).
and extraction of the data by
the recipient.
Application Processing
The processing overhead becomes a
significant design issue within
SOA.
At the transport layer of SOA,
Document and message modelling
conventions and the strategic
placement of validation logic are
important.
This messaging framework a wide
range of message exchange
patterns.
Though synchronous
communication is fully supported,
asynchronous patterns are
encouraged in SOA.
The WS-* specifications, such as
WS-Coordination and WS-BPEL are
widely used.

Initial architectures consisted of A contemporary SOA is built upon

Technology technology components like, server- XML data representation and the
side scripts, and raw Web Web services technology platform.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 41 Service Oriented Architecture (SOA) Basics

technologies - HTML and HTTP. Thus, XML and Web services are
optional for distributed Internet
Improvements in middleware
architecture but not for
allowed for increased processing
contemporary SOA.
power and transaction control.
The emergence of XML introduced
sophisticated data representation
that actually gave substance to
content transmitted via Internet
protocols.
The subsequent availability of Web
services allowed distributed Internet
applications to cross proprietary
platform boundaries.

To ensure the safe transportation of SOA relies heavily on the

information and the recognition of extensions and concepts established
user credentials traditional security by the WS-Security framework. the
architectures incorporate security models used within SOA
approaches such as delegation and emphasize the placement of
impersonation. security logic onto the messaging
level.
Encryption also is added to the
Security otherwise wide open HTTP protocol SOAP messages provide header
to allow data to be protected during blocks in which security logic can
transmission beyond the Web be stored. This approach is
server. required to preserve individual
autonomy and loose coupling
between services, as well as the
extent to which a service can
remain fully stateless.

Distributed Internet architecture has Enterprise-level SOAs typically

Web server and additional physical require additional runtime
environment that requires attention administration.
while solutions are in operation.
Problems with messaging
Because clients, whether local or frameworks can more easily go
external to an organization, connect undetected than with RPC-based
to these solutions using HTTP, the data exchanges.
Web server becomes the official first
This is because so many variations
point of contact.
Administration exist as to how messages can be
It must therefore be designed for interchanged. RPC communication
scalability - a requirement that has generally requires a response from
led to the creation of Web server the initiating component, indicating
farms that pool resources. success or failure.
Although WS -* extensions are
being positioned to better deal with
these situations, administration
effort is still expected to remain
high.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 42 Service Oriented Architecture (SOA) Basics

UDDI (Universal Description

Discovery and Integration) is used
for standardizing interface
repository.
It can be manually or
programmatically accessed to
discover service descriptions.

 Distributed internet architecture has much in common with SOA, including a

significant amount of its technology. However, SOA has distinct characteristics
relating to both technology and its underlying design principles. For example,
SOA introduces processing and security requirements that differ from distributed
internet architecture, and SOA administration is typically more complex due to its
reliance on messaging-based communication.

2.5 Principles of Service Orientation

 By SOA, we understand that service-orientation is based on the design of services
(i.e. processing logics)
 There is also no single governing standards body that defines the principles
behind service-orientation. Instead, there are many opinions, originating from
public IT organizations to vendors and consulting firms, about what constitutes
service-orientation.
 Service-orientation is said to have its roots in a software engineering theory
known as "separation of concerns." This theory is based on the notion that it is
beneficial to break down a large problem into a series of individual concerns. This
allows the logic required to solve the problem to be decomposed into a collection
of smaller, related pieces. Each piece of logic addresses a specific concern.
 Service-orientation can be viewed as a distinct manner in which to realize a
separation of concerns. The principles of service-orientation provide a means of
supporting this theory while achieving a foundation paradigm upon which many
contemporary SOA characteristics can be built.
 Principles of Service Orientation (aka Service-orientation design principles) are
proposed principles for developing the solution logic of services within service-
oriented architectures.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 43 Service Oriented Architecture (SOA) Basics

Principles of service orientation

This section focuses on the key principles of service orientation in SOA. These are as
follows -

Fig. 2.5.1 Principles of Service Orientation

 Service-orientation emphasizes loose coupling between units of processing logic
(services).
 Service-orientation encourages coarse-grained interfaces (service descriptions) so
that every unit of communication (message) contains as much information as
possible for the completion of a given task.
 Service-orientation expects the scope of a unit of processing logic (service) to vary
significantly.
 Service-orientation promotes the creation of activity-agnostic units of processing
logic (services) that are driven into action by intelligent units of communication
(messages).
 Service-orientation prefers that units of processing logic (services) be designed to
remain as stateless as possible.
 Service-orientation supports the composition of loosely coupled units of
processing logic (services).

2.6 Service Layers

 In Service Oriented Architecture (SOA), the service layer is the third layer in a
five-abstraction-layer model. (Refer Fig. 2.6.1)

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 44 Service Oriented Architecture (SOA) Basics

Fig. 2.6.1 SOA layer model

 The service layer can be considered as a bridge between the higher and lower
layers, and is characterized by a number of services that are carrying out
individual business functions.
 The service interface layer is located between the business process and application
layers.
 This is where service connectivity resides; hence it is the most dominant layer in
the service-oriented architecture.
 Before implementing the quality services of SOA (primarily enterprise-wide loose
coupling, support for service-oriented business modelling, organizational agility
and the layers of abstraction) Application architects should get clarity on the
below questionnaire. This list gets studied and answered during SOA analysis
phase. The list is as -
o What logic should be represented by services ?
o How should services relate to existing application logic ?
o How can services best represent business process logic ?
o How can services be built and positioned to promote agility ?
 Based on this questionnaire, the three layers of abstraction identified are
o Application Service Layer
o Business Service Layer
o Orchestration Service Layer

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 45 Service Oriented Architecture (SOA) Basics

 The positioning of these primary service layers is detailed out in the following
sections. (Refer Fig. 2.6.2)

Fig. 2.6.2 The three primary service layers of SOA

 Through abstraction implemented via distinct service layers, key contemporary

SOA characteristics can be realized especially like organizational agility.

Application service layer

 The application service layer establishes the ground level foundation that exists to
express technology-specific functionality. (Refer Fig. 2.6.2)
 Services that reside within this layer can be referred to simply as application
services.
 Their purpose is to provide reusable functions related to processing data within
new or legacy application environments.
 The application service layer consists of application services that represent
technology-specific logic.
 Application services commonly have the following characteristics :
o They expose functionality within a specific processing context.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 46 Service Oriented Architecture (SOA) Basics

o They draw upon available resources within a given platform.

o They are solution-agnostic.
o They are generic and reusable.
o They can be used to achieve point-to-point integration with other application
services.
o They are often inconsistent in terms of the interface granularity they expose.
o They may consist of a mixture of custom-developed services and third-party
services that have been purchased or leased.
 Typical examples of service models implemented as application services include
the following :
o Utility service
o Wrapper service
 When a separate business service layer exists, there is a strong motivation to turn
all application services into generic utility services.
 Aggregating application services is frequently done to accommodate integration
requirements. Application services that exist solely to enable integration between
systems often are referred to as application integration services or simply
integration services. Integration services often are implemented as controllers.
 Wrapper services most often are utilized for integration purposes. They consist of
services that encapsulate (“wrap”) some or all parts of a legacy environment to
expose legacy functionality to service requestors.
 Proxy service (aka auto-generated WSDL) simply provides a WSDL definition
that mirrors an existing component interface. It establishes an endpoint on the
component’s behalf, essentially allowing it to participate in SOAP communication.
 Application services are ideally reusable utility services composed by business
services, but also can exist as hybrid services that contain both business and
application logic.

Business Service Layer

 The business service layer introduces a service concerned solely with representing
business logic, called the business service.
 They are responsible for expressing business logic through service-orientation and
bring the representation of corporate business models into the Web services arena.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 47 Service Oriented Architecture (SOA) Basics

 Business services are always an implementation of the business service model.

The sole purpose of business services intended for a separate business service
layer is to represent business logic in the purest form possible. (Refer Fig. 2.6.2)
 The business service layer is comprised of business services, a direct
implementation of the business service model.
 Business services are ideally also controllers that compose application services to
execute their business logic.
 Business service layer abstraction leads to the creation of two further business
service models as follows -
o Task-centric business service
 It is a service that encapsulates business logic specific to a task or business
process. This type of service generally is required when business process
logic is not centralized as part of an orchestration layer.
 Task-centric business services have limited reuse potential.
o Entity-centric business service
 It is a service that encapsulates a specific business entity (such as an
invoice or timesheet).
 Entity-centric services are useful for creating highly reusable and business
process-agnostic services that are composed by an orchestration layer or
by a service layer consisting of task-centric business services (or both).
 Even though hybrid services contain business logic, they are not classified as
business services.

Orchestration service layer

 In SOA, Orchestration is more valuable than a standard business process, as it
allows to directly link process logic to service interaction within workflow logic.
(Refer Fig. 2.6.2)
 This combines business process modelling with service-oriented modelling and
design.
 Because orchestration languages (such as WS-BPEL) realize workflow
management through a process service model, orchestration brings the business
process into the service layer, positioning it as a master composition controller.
 The orchestration service layer introduces a parent level of abstraction that
alleviates the need for other services to manage interaction details required to
ensure that service operations are executed in a specific sequence.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 2 - 48 Service Oriented Architecture (SOA) Basics

 Within the orchestration service layer, process services compose other services
that provide specific sets of functions, independent of the business rules and
scenario-specific logic required to execute a process instance.
 Orchestration abstracts business rules and service execution sequence logic from
other services, promoting agility and reusability.

A reality check
 Theoretically there are clearly identified service layers in SOA; the real SOAs
rarely show such separation. In real scenario, one may come across following
kind of service compositions.
o Hybrid application services (services containing both business process and
application logic)
o Utility application services (services containing reusable application logic)
o Task-centric business services (services containing business process logic)
o Entity-centric business services (services containing entity business logic)
o Process services (services representing the orchestration service layer)
 To summarize
o SOAs are configured in different shapes and sizes, depending primarily on the
types of services from which they are comprised.
o Hybrid application services are found more commonly when service-oriented
environments include legacy distributed application logic.
o By strategically positioning business and process services, an enterprise’s
business logic can be abstracted successfully from the underlying application
logic.



TECHNICAL PUBLICATIONS® - An up thrust for knowledge

 UNIT - III

3 Web Services (WS)

and Standards
Syllabus
Web Services Platform - Service descriptions - WSDL - Messaging with SOAP - Service
discovery - UDDI - Service - Level Interaction Patterns - Orchestration and Choreography.

Contents
3.1 Web Services Platform
3.2 Service Descriptions (with WSDL)
3.3 Messaging with SOAP
3.4 Service Discovery and Description Advertisement
3.5 Orchestration

(3 - 1)
Service Oriented Architecture 3-2 Web Services (WS) and Standards

Points to remember
 Web service is a standardized medium to propagate communication between the
client and server applications on the World Wide Web. A web service is a software
module that is designed to perform a certain set of tasks.
 A web service is any piece of software that makes itself available over the internet
and uses a standardized XML messaging system.
 Used primarily as a means for businesses to communicate with each other and with
clients, Web services allow organizations to communicate data without intimate
knowledge of each other's IT systems behind the firewall.
 Unlike traditional client / server models, such as a Web server / Web page system,
Web services do not provide the user with a GUI. Web services instead share
business logic, data and processes through a programmatic interface across a
network. The applications interface, not the users. Developers can then add the Web
service to a GUI (such as a Web page or an executable program) to offer specific
functionality to users.
 The term Web services describes a standardized way of integrating Web-based
applications using the XML, SOAP, WSDL and UDDI open standards over an
Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer
the data, WSDL is used for describing the services available and UDDI is used for
listing what services are available.

 The client would invoke a series of web service calls via requests to a server which
would host the actual web service.
These requests are made through what is known as remote procedure calls. Remote
Procedure Calls (RPC) is calls made to methods which are hosted by the relevant
web service.
 As an example, Amazon provides a web service that provides prices for products
sold online via amazon.com. The front end or presentation layer can be in .Net or

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-3 Web Services (WS) and Standards

Java but either programming language would have the ability to communicate with
the web service.
The main component of a web service is the data which is transferred between the
client and the server and that is XML, XML (Extensible Markup Language) is a
counterpart to HTML and easy to understand the intermediate language that is
understood by many programming languages.
So when applications talk to each other, they actually talk in XML. This provides a
common platform for application developed in various programming languages to
talk to each other.
Web services use something known as SOAP (Simple Object Access Protocol) for
sending the XML data between applications. The data is sent over normal HTTP.
The data which is sent from the web service to the application is called a SOAP
message. The SOAP message is nothing but an XML document. Since the document
is written in XML, the client application calling the web service can be written in
any programming language.
 Modern day business applications use variety of programming platforms to develop
web-based applications. Some applications may be developed in Java, others in
.Net, while some other in Angular JS, Node.js, etc.
Most often than not, these heterogeneous applications need some sort of
communication to happen between them. Since they are built using different
development languages, it becomes really difficult to ensure accurate
communication between applications. Here is where web services come in. Web
services provide a common platform that allows multiple applications built on
various programming languages to have the ability to communicate with each
other.

3.1 Web Services Platform

The basic web service platform is XML + HTTP. All the standard web services work
using the following components -
 SOAP (Simple Object Access Protocol)
 UDDI (Universal Description, Discovery and Integration)
 WSDL (Web Services Description Language)

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-4 Web Services (WS) and Standards

Fig. 3.1.1 The process flow of a web service

Consider a simple account-management and order processing system. The accounting

personnel use a client application built with Visual Basic or JSP to create new
accounts and enter new customer orders.
The processing logic for this system is written in Java and resides on a Solaris
machine, which also interacts with a database to store information.
The steps to perform this operation are as follows -
 The client program bundles the account registration information into a SOAP
message.
 This SOAP message is sent to the web service as the body of an HTTP POST request.
 The web service unpacks the SOAP request and converts it into a command that the
application can understand.
 The application processes the information as required and responds with a new
unique account number for that customer.
 Next, the web service packages the response into another SOAP message, which it
sends back to the client program in response to its HTTP request.
 The client program unpacks the SOAP message to obtain the results of the account
registration process.
 Web services are means of encapsulating various extents of logic.
 Web services framework is flexible and adaptable. They can be designed to handle
the distributed environment or they can be fully SOA compliant.
 This flexibility makes Web services popular.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-5 Web Services (WS) and Standards

 To understand the concept of web services let’s consider the story of four friends : I
get a chance to meet my school friends, Devika and Aastha occasionally. We have
one more friend Neela, but we haven't met her for many years. We don't know
about the current details of Neela, so we decided to contact an agency called
"Reconnect".
 ln this scenario, reconnect agency is providing a service, so it can be considered as a
service provider. We want to avail the service so we are service requestors.
 To use the service offered by Reconnect we need to follow the below steps.
a. We need to find out or discover how to contact this agency.
b. We need to formulate the request by providing the information about Neela to
the Reconnect agency.
c. Forward this information or issue the request to agency.

3.2 Service Descriptions (with WSDL)

 To understand the concept of WSDL, let's continue the story of four friends.
 In order to provide searching request of Neela, Reconnect agency will first give us a
brochure, which explains
a. We need to fill a form including information about background details about
Neela, to avail the service.
b. After receiving the form, search will be performed.
c. The result of the search will be mailed to us.
 After filling the form the disclaimer needs to be signed which states that the results
are no guaranteed.
 A service description or WSDL definition is analogous to the use of brochure and
the form together.
 The WSDL establishes the terms of use for the service provider by defining exactly
the information it requires to perform its service and also whether or not a response
will be issued.
 Typically description documents are needed for the receiver services.
 The basic service description document is called the WSDL definition.
 The WSDL establishes the terms of use for the service provider by defining exactly
the information it requires to perform its service and also whether or not a response
will be issued.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-6 Web Services (WS) and Standards

 As shown in Fig. 3.2.1 WSDL establishes loosely coupled communication between

web services.

Fig. 3.2.1 WSDL definitions enable loose counting between services

Service endpoints and service descriptions :

 Service endpoint or endpoint is a point of
contact for a service provider.
 It includes :
1. Endpoint interface through which
requester can structure a request
message.
2. Address or physical location of
service.
 As shown in the Fig. 3.2.2 the WSDL
document which contains abstract and
concrete parts collectively describe a
service endpoint.
 As shown, service definition i.e. WSDL
definition is divided in two parts.
1. Abstract description
2. Concrete description
1. Abstract description : Fig. 3.2.2 WSDL document consisting
of abstract and concrete parts that
 It includes the interface characteristics of
collectively describe a service
web service for transmitting the messages endpoint
without reference to technology.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-7 Web Services (WS) and Standards

 Abstract description consists of three sections.

o Port Type
o Operation
o Message
 Port Type and Operations : In this section the messages are sorted according to
functions. These groups are called as operations. This facilitates high level view of
service interface.
 Operation to an action performed by service.
 As the basic communication in web services happens through messages, the
parameters are represented as messages.
 With this context, any operation contains set of input and output messages.

2. Concrete description :
 This section includes connection of abstract interface to implemented technology i.e.
a physical transport protocol.
 It consists of three parts.
o Binding
o Port
o Service
 Binding is a transport technology which is used by service for communication.
 For example : SOAP which described how physical connections can be established
with the service.
 Port is a physical address through which service can be accessed via specific
 Service in WSDL language is a group of endpoints.

Metadata and Service Contracts :

 WSDL definition contains technical information about interfacing of a service and
supporting data exchange type.
 WSDL definitions are dependent on XSD schema for formalizing the structure of
incoming and outgoing messages.
 One more supplementary document is a policy document which contains rules,
preferences and the over and above details of WSDL and XSD schema documents.
 These three service description documents i.e. WSDL definition, XSD schema and
policy comprise service metadata.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-8 Web Services (WS) and Standards

Fig. 3.2.3 A service contract comprised of a collection of service descriptions and possibly
additional documents
 As shown in Fig. 3.2.3, collection of these is used to establish a service contract
which is a set of conditions which must be met and accepted by potential service
requester for successful communication.

Semantic Descriptions :
 Typically the service description documents talks about the technical information
corresponding to data representation and processing requirements. But, they do not
say much about the behaviour characteristics of the service which is a challenging
part to explain in web service descriptions.
 Some of the examples of service semantic are behaviour and response of a service
under certain conditions suitable task for a service.
 Generally, this requires human intervention as sufficient semantic information need
to be conveyed in structured manner.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3-9 Web Services (WS) and Standards

 Semantic information is of a more importance when we need to deal with external

service providers.

3.3 Messaging with SOAP

 The services communicate through messages, so there should be use of standard
frame work, standard format and transport protocol.
 Simple object access protocol i.e. SOAP is a standard transport protocol for the
messages to be processed by web services.
 SOAP can handle sophisticated message structure for enterprise distributed
applications and enterprise SOA.
 To understand concept of SOAP let us consider the scenario of the communication
between trends explained in previous section : Devika has found out the agency and
now to send application form, she needs address of the company. So, she refers to
phone back and write mailing address on the envelope. In this case phone book can
be considered as a service registry, mailing address as a WSDL endpoint or port and
an envelope as a standard medium for transporting mail like SOAP. When the letter
is ready, we put it in a mailbox. Similarly, service requester handover SOAP
messages to SOAP nodes for actual transmission. The travel of letter from Devika to
the agency is equivalent to path of SOAP message from service requester to service
provider.
 Three important part of SOAP are :
1. Messages
2. Nodes
3. Message paths
 Please refer Fig. 3.3.1 for basic structure of SOAP.

Messages :
 The main aim of SOAP is to define a standard
message format.
 SOAP message format includes :
o Envelope
o Header
o Body
Fig 3.3.1 The basic structure of a
 The basic structure of SOAP message is shown in SOAP message
Fig. 3.3.1.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 10 Web Services (WS) and Standards

 Envelope is a container to pack the SOAP message.

 Header contains meta information and is an important part of structure.
 Body contains the actual message consists of XML formatted data. Body contents are
called as payload.
Header Blocks :
 To increase the level of independence, robustness and extensibility of messaging
framework in loosely coupled environment, header blocks are used.
 Header block contains the information through which the services can route the
message according to accompanying rules, instructions and properties.
 Following features can be included in the header blocks :
o Processing instructions executed by the receiver.
o Routing or work flow information present with message.
o Security measures to be implemented.
o Reliability rules associated with delivery of message.
o Context and transaction management information.
o The information which associates request messages with response message
which is known as correlation information.
Message Styles :
 SOA uses documents style messages to facilitate larger payloads, coarser interface
operations and reduced volume of message transmission between the services.
 SOAP specifications replace RPC protocols by serializing the calls between
distributed components to XML documents.
 After arrival, these XML documents are then deserialized in the supported format.

Attachments :
 The data which is difficult to format in XML document can be delivered by SOAP
attachment technology.
 The data is bundled in a specific encoding type in the specific format supported by
SOAP message.
 Typically binary files images ex. images are sent as SOAP attachments.

Faults :
 Exception handling is included in SOAP message in fault section.
 It is an optional section which is included in the body area.
 This section contains simple message used to deliver error condition information in
case of exception occurrence.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 11 Web Services (WS) and Standards

Nodes :
 SOAP messages need to be exchanged and processed by a physical communication
medium.
 This physical medium i.e. the programs which are used to transmit and receive
SOAP messages is called as SOAP nodes.
 Fig. 3.3.2 shows the structure of a SOAP node for the transmitting a SOAP message
received by the service logic.

Fig. 3.3.2 A SOAP node transmitting a SOAP message received by the service logic

 SOAP nodes must follow the processing standard catering to the supported version
of SOAP specification.

Node Types :
 The labels are given to identify the type of SOAP node.
 SOAP types or labels are called as concept.
 Following are the labels associated with SOAP nodes.
o SOAP sender - Node which transmits a message.
o SOAP receiver - Node which receives a message.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 12 Web Services (WS) and Standards

o SOAP intermediary - Node which receives and transmits a message and

process the message before transmission.
o Initial SOAP sender – First SOAP node which transmit a message.
o Ultimate SOAP receiver - Last SOAP node which receives a message.

SOAP Intermediaries :
 As shown in Fig. 3.3.3 intermediary node, this node plays role of SOAP receiver and
sender while processing a message.

Fig. 3.3.3 Different types of SOAP nodes involved with processing a message

Message Paths :
 It is a route taken by message from service to destination.
 As shown in Fig. 3.3.4, message part must have :
o At least one initial sender.
o One ultimate receiver.
o Zero or more intermediaries.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 13 Web Services (WS) and Standards

Fig. 3.3.4 A message path consisting of three Web services

 As shown in Fig. 3.3.5, a message path sometimes is decided at runtime. In such case
a header block processed by intermediaries dynamically decides the path of
message. (Fig. 3.3.5 on next page)

3.4 Service Discovery and Description Advertisement

 One service contact the other service to access its description.
 As number of service of increase inside in an outside the organization advertising
and discovering the services becomes essential.
 One of the way to accomplish this is keeping central directories and registries this is
keeping helpful for humans to locate latest transfer and already known service
description and to discover web services based on some criteria.

UDDI
 The above context of service discovery and description advertisement Universal
Description Discovery and Integration (UDDI) protocol is an approved OASIS
standard and key member of web services stack.
 UDDI in tested to structure the registered for keeping track of service description as
shown in Fig. 3.4.1.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 14 Web Services (WS) and Standards

Fig. 3.3.5 A message path determined at runtime

Fig. 3.4.1 Service description locations centralized in a registry

 The search of these registries can be done manually or they can be assessed
programmatically through standard API.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 15 Web Services (WS) and Standards

 Public registries are used to provide a central repository within an organization. It

includes details of all the services which are developed, leased or purchased by an
organization.
 Organizations can sign up in public registries to register their services
 The part of UDDI registry services are shown in Fig. 3.4.2.

Fig. 3.4.2 The basic structure of a UDDI business entity record

• The description of parts of regarding record can be given as :

1) Business entities and business services
 Business entities contain basic profile information about the organization.
Business service area within business entity gives description of services
offered by business entity.
2) Binding templates and tmodel.
 As shown in Fig. 3.4.2 Binding template contains the binding information of
abstract design and actual implementation defects.
 The information in binding template is not necessary release to actual
service. For example : It can be only the address of website.
 tmodel service points actual service description.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 16 Web Services (WS) and Standards

3.5 Orchestration
 To understand orchestration lets revisit the story of four friends. If new company
needs to be started the various types of car need to be handled for clearing. Some
new requirements are needed to facilitate this. These include : Need of extra help in
peak hours and in return of usage of space the help can be provided to gas pumping
station. To accomplish this various tasked and operations need to manage according
to the conditions. Some of the conditions include task allocation when extra workers
are presents etc. To handle this plan should be there to join individual steps with
processes partitioned by decision points. This is called as or orchestration which
manger individual process requirements and related resources.
 Orchestration is centrally controlled set of workflow logic which facilities
interoperability between two or more applications.
 Orchestration connects different process without the need of redevelopment of the
solutions.
 It helps to represent and express business logic in a standardized, receives based
venue.
 Fig. 3.5.1 describes the concept of orchestration.

Fig. 3.5.1 An orchestration controls almost every face of a complex activity

Business protocols and process definition

 Business protocols consist of business rules, conditions and events to define the
interoperation of participants to achieve the completion of business task.
 Process definitions contain details of the workflow logic expressed by an
orchestration.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 17 Web Services (WS) and Standards

 Process services and partner

services as shown in Fig. 3.5.2.
 Process definition includes the
process partial.
 The process is considered as a
service.
 The services which interact with
process service are called as
partner services or partner links.
Fig. 3.5.2 A process service coordinating and
 Process service and partner service exposing functionality from three partner services
can invoke each other based on
workflow logic as shown in Fig. 3.5.3.

Fig. 3.5.3 The process service, after first being invoked by a partner service, then invokes another
partner service

Basic activities and structured activities :

 Basic activities are the primitive activities in receive, invoke reply throw and wait
which are fundamental workflow activity.
 Structured activities like sequence switch flow pick provide the logic which combine
the basic activities.
Sequence, flows and links :
 Sequence contains a list which includes basic and structured activities which can
executed in a sequential order.
 Flows include group of related activities which can be executed concurrently. One
set of activities need not to wait for another set to finish.
 Links establish formal dependencies between activities. Before completion the
activities must ensure the outgoing incoming for establishment are met.
 Synchronization dependencies are the rules provided by links.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 18 Web Services (WS) and Standards

Orchestration and activities :

 Activity is a logical unit of work completed by service oriented solution.
 Single orchestration can be considered as a complex and long revenging activity.

Orchestration and co-ordination :

 Orchestration can incorporate WS-Business Activity and utilized WS-coordination
context management framework.

Orchestration and SOA :

 As shown in Fig. 3.5.4 orchestrations is a key integration enabler which acts as a
common point of integration for other application.

Fig. 3.5.4 Orchestration relating to other parts of SOA

 The organizational agility increases due to orchestration as the workflow logic can
be altered at a central location, business process can be merged it supports the
evolution of diversely featured enterprise.

Choreography
 Choreography is a collaboration process which allows intersection of the
organizations in partnership considering that an environment is not owned by any
one partner.
 To understand Choreography let’s consider the example of car washing company
example. After successful operation is some months the company was contracted by
the nearby companies to enhance the profit. But it was observed that this
partnership started affecting our business. So these in a need of new process which

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 19 Web Services (WS) and Standards

includes new conditions and constraints. So after discussion with Partner Company
the agreement was made for facilitating flexible collaboration process. This
collaboration process is called as Choreography.
 The web services choreography description language (WS-CDL) in the specification
which is used to facilitate information process is called as Choreography.
 Fig. 3.5.5 explains the concept of Choreography.

Fig. 3.5.5 A choreography enables collaboration between its participants

Collaboration :
 Public message exchange is the main characteristics of choreography.
 To facilitate this, there is need of establishment of organized collaboration between
services taking care that a single organization should not context the collaboration
logic.
Roles and Participants :
 Role of a web service within a specific choreography tells that what work the service
does and what it can do for a business task. Role is associated under WSDL
destination.
 Participants are the services which follow the same rules.
Relationships and channels
 Relationship is an exchange of two roles in choreography.
 Channel is the means of conversation. They do that by characteristic definition of
the message exchange between two roles.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 20 Web Services (WS) and Standards

Interaction and work units :

 Interaction is building block of choreography.
 The progress in choreography is represented by interaction completion.
 Work units specify the rules and constraints for successful completion of the
interaction.

Reusability, Composability and modularity

 Reliability is an important characteristics of choreography by which it can be used in
different business tasks.
 Modules are the sub tasks which can be refused by different choreographies.
Choreography can be assembled from different modules by import function.
 As shown in Fig. 3.5.6, choreographies can be assembled to composition.

Fig. 3.5.6 A choreography composed of two smaller choreographies

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 21 Web Services (WS) and Standards

Orchestration and Choreographies :

 The basic difference between orchestration and choreography is : Organization own
the logic behind orchestration whereas choreography is not owned by single entity.
 Orchestration is business specific application of choreography.
 As shown in Fig. 3.5.7 in orchestration composition logic is executed in controlled in
centralized manner whereas choreography considers that there is no single owner of
collaboration logic.

Fig. 3.5.7 A choreography enabling collaboration between two different orchestrations

Choreography and SOA :

 Fig. 3.5.8 shows how choreography is related to other parts of SOA.
 Choreography implements SOA occurs organization boundaries.
 It supports composability, reusability and extensively and helps to increase
organizational agency and discovery.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 3 - 22 Web Services (WS) and Standards

Fig. 3.5.8 Choreography relating to other parts of SOA




TECHNICAL PUBLICATIONS® - An up thrust for knowledge

 UNIT - IV

4 Web Services Extensions

Syllabus
WS-Addressing - WS-ReliableMessaging - WS-Policy - WS-Coordination – WS-Transactions
- WS-Security – Examples.

Contents
4.1 WS-Addressing
4.2 Reliable Messaging
4.3 WS-Policy
4.4 WS-Coordination
4.5 WS-Transactions
4.6 WS-Security

(4 - 1)
Service Oriented Architecture 4-2 Web Services Extensions

Points to remember
 To support the concepts of services oriented architecture WS.* extensions are used.
 They play important role in the areas of SOAP messaging framework, message level
security and certain and exchange of metadata.
 The first web services specification is WS-addressing.

4.1 WS-Addressing
 Consider the communication happening in Fig. 4.1.1.
 To understand addressing, consider the example of bill in shipping process.
 Irrespective of the in between stoppages, the destination as whoever is viewing it
will come to know the source from where it is coming, the address of destination,
the person to whom it must be delivered and the address where it should reach in
case of father delivery to the required destination.

Fig. 4.1.1 Addressing turns messages into autonomous units of communication

4.1.1 End Point References

 Endpoint reference is an extension in WS addressing which provides identifiers that
pin point a particular instance of a service and supplementary service metadata.
 Endpoint reference is dynamically generated.
 Please refer Fig. 4.1.2 to understand the mechanism of end point reference.
 Typically end point reference consists of the parts mentioned below :
1) Address : Web service URL
2) Reference properties :
 To understand this lets refer to the scenario mentioned at the beginning of
the section. In that the attention gives which indicates that the letter should
be directly delivered to account personal represents reference ID Property.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-3 Web Services Extensions

 Formally it can be defined as a set of property values associated with the

web service instance.
3) Reference parameters : The set of parameter values which facilities the further
interaction.
4) Service part type and part type : It provides the exact service description location
to the message recipient.
5) Policy : It describes the rules and behaviour information for current service
interaction.

Fig. 4.1.2 A SOAP message containing a reference to the instance of the service that sent it

4.1.2 Message Information Headers

 As explained in the example of car washing company. Sometimes due to certain
requirements services exchange need to break the fixed pattern in message exchange
pattern.
 This pattern is dynamic in nature.
 By inclusion of standards headers called as the message information or MI headers
message exchange related characteristics can be established.
 The mechanism is shown in Fig. 4.1.3.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-4 Web Services Extensions

Fig. 4.1.3 A SOAP message with message information headers specifying exactly how the
recipient service should respond to its arrival

 Typically the MI include :

1. Destination : The destination address for sending the message.
2. Source endpoint : An endpoint reference to the web services from which the
message in generalized.
3. Reply endpoint : The header which cells and allows which the message to decide
the destination address to which the reply should be sent.
4. Fault endpoint : This give ability to the message to set the address for sending
fault notification
5. Message id : It is value used to uniquely identify the message. It also identifies
retransmission of the message.
6. Relationship : This header includes the id of the message, to which reply is to be
sent.
7. Action : It contains URI value indicating message's purpose.

4.1.3 Addressing and SOA

 The benefits of addressing within SOA includes :
o It provides low level, transport standardization.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-5 Web Services Extensions

o It promotes open standards to achieve certain level of transport technology

independence.
o The inclusion of endpoint references and MI headers enhance the intelligence
of SOAP messages, due to which message level autonomy is increased.
 It helps web services to become intrinsically interoperable by
o Facilitating self-direction of pay load.
o By directing the behaviour of the recipient services.
o It facilitates reusable and generic service design standards by including task
specific logic into the message.
 It helps to discover additional service medata.
 Due to inclusion of MI headers dynamic determination of the logic and range of
interaction logic within complex activities increases.

Fig. 4.1.4 Addressing relating to other parts of SOA

4.2 Reliable Messaging

 To understand reliable messaging consider the scenario of can wash company Two
car wash companies located nearby have made an alliance. As a part of it they share
part time workers during peak hours. Rahul is one worker, who is very good at his
work but has bad memory. When the workers are asked to go to partner company
for help, generally the way Rahul forget this. So to handle this problem a system is
set in which when the workers will start from one company the call is made to

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-6 Web Services Extensions

sending company to tell them the number of workers arrived. This acknowledgment
builds reliability into resource sharing arrangement.
 As message transmission is a loosely coupled it’s difficult to know it the messages
are successful delivered in the
same sequence or there is failure
in delivered in the same sequence
or there is failure in delivery so
they need to retransmit or not.
 This problem is solved by reliable
messaging by means of
notification as shown in Fig. 4.2.1. Fig. 4.2.1 Reliable messaging provides a guaranteed
notification of delivery success or failure
 WS-Reliable messaging ensures :
1) Notification to service provider regarding success or failure of message
transmission.
2) The sequence in which the messages are sent are arriving in the same sequence or
not.

4.2.1 RM Source, RM Destination, Application Source and Application

Destination
 WS-reliable messaging clearly distinguishes between the process which is
responsible for initiating message transmission and the one which actually performs
the transmission.

Fig. 4.2.2 An application source, RM source, RM destination and application destination

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-7 Web Services Extensions

 As shown in the Fig. 4.2.2 the description of the various blocks are given as :
o Application source : It is a service application logic responsible for sending
the message to Reliable messaging (RM) source.
o RM source : It is a physical processor or node which performs actual wire
transmission.
o RM destination : It is a target processor or node that receives the message.
o Application destination : The message from RM destination as finally
delivered to application destination.

4.2.2 Sequences

Fig. 4.2.3 A sequence acknowledgement sent by the destination

after the successful delivery of a sequence of messages

 As shown in Fig. 4.2.3, sequence is responsible for the order of delivery of the
message.
 Every message in a sequence is labelled with message number.
 Message number identifies position of message in a sequence.
 The last message in the sequence is tagged by last message identifier.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-8 Web Services Extensions

4.2.3 Acknowledgments
 It is a notification system between RM destination and RM source as shown in
Fig. 4.2.4.
 When the last message, containing last message identifier reaches RM destination, it
issues a sequence acknowledgment.
 Acknowledgment message tells RM source which messages are arrived.
 A sequence acknowledgment sent by the RM destination after the successful
delivery of a sequence of messages.
 It is a job of RM source to match the number of received messages to original
messages.
 RM source will not wait for RM destination for the acknowledgment.
 Rather RM source can request the acknowledgment by RM destination by issue of
request acknowledgment at any time as shown in Fig 4.2.4.

Fig. 4.2.4 A request acknowledgement sent by the RM source to the RM destination,

indicating that the RM source would like to receive
an acknowledgement message before the sequence completes

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4-9 Web Services Extensions

 In case of failure, RM destinations transmit negative acknowledgments for

indication of failure condition to RM source as shown in Fig. 4.2.5.

Fig. 4.2.5 A negative acknowledgement sent by the RM destination to the RM source, indicating
a failed delivery prior to the completion of the sequence

4.2.4 Delivery Assurances

 Delivery assurances provide set of reliability rules for establishing set of reliability
policies.
 The four type of delivery assurances supported are :
1) AtMostOnce delivery assurance :
o Delivery of one or zero messages is assured.
o Error condition occurs if same message is delivered more than once as shown
in Fig. 4.2.6.
2) AtLeastOnce delivery assurance :
o Allows message delivery once or many times.
o Error condition occurs on delivery of zero messages as shown in Fig. 4.2.7.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 10 Web Services Extensions

Fig. 4.2.6 The AtMostOnce delivery assurance

Fig. 4.2.7 The AtLeastOnce delivery assurance

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 11 Web Services Extensions

3) ExactlyOnce delivery assurance :

o Ensures that message is delivered only once.
o Error condition occurs in case of delivery of zero or duplicates messages as
shown in Fig. 4.2.8.

Fig. 4.2.8 The ExactlyOnce delivery assurance

4) InOrder delivery assurance :

o Ensures delivery of messages in specific sequence.
o Error condition occurs in case of out of sequence delivery of messages as
shown in Fig. 4.2.9. (See Fig. 4.2.9 on next page)

4.2.5 Reliable Messaging and SOA

 Due to reliable messaging flexibility and the assurance of delivery of message
sequence including fault reporting is assured in service oriented solutions.
 It increases robustness of SOAP messaging implementation.
 Due to increase in delivery quality of SOAP messages, quality of cross application
communication channel is also increased.
 As shown in the Fig. 4.2.10, reliable messaging relates to other parts of SOA.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 12 Web Services Extensions

Fig. 4.2.9 The InOrder delivery assurance

Fig. 4.2.10 Reliable messaging relating to other parts of SOA

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 13 Web Services Extensions

4.3 WS-Policy
 Every task in any business should follow some rules and constraints.
 These rules and restrictions are subject to actual business level requirements, the
nature of data which can be exchanged and organizational security measures.
 To understand the concept of policy let us consider the scenario of process of car
wash when driver brings the car for washing they see the list of points like :
o After entering car wash area, turn-off the engine and exit the car.
o Beware; power washing equipment can be loud.
o We recommend that you wait inside the gas station until the car wash has
completed.
Among the above three, first is the rule to be followed by customers. A second
state the behaviourial characteristics of car wash, third is the company preference
for smooth work handling. These points form a policy.
 As shown in Fig. 4.3.1 the policies helps a service to express characteristics and
preferences and their implementation by enforcing rules and constraints in a custom
manner.

Fig. 4.3.1 Policies can express a variety of service properties, including rules

4.3.1 The WS-Policy Framework

 Fig. 4.3.2 shows the structure of policy description documents.
 It consists of three specifications :
1. WS-Policy
2. WS-Policy Attachments
3. WS-Policy Assertions
 Programmatic assessment of policies gives understanding of requirements and
restrictions of service providers to service requestor.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 14 Web Services Extensions

Fig. 4.3.2 The basic structure of a policy description

4.3.2 Policy Assertions and Policy Alternatives

 Policy description consists of one or more policy assertions.
 Policy assertions individually represent policy description.
 Service characteristics, preferences, capabilities, requirements and rules are the
examples of policy description.
 If policy assertions are grouped together, they are called as policy alternatives.
 Policy alternative contains one acceptable combination of policy assertions.
 Due to this, service provider can offer service requestor certain choice of policies.

4.3.3 Policy Assertion Types and Policy Vocabularies

 Policy vocabulary is collection of policy types in given policy.
 Categorization of policy assertions can be done in policy assertion types
 Policy assertions types attach specific XSD Schemas to policy assertions.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 15 Web Services Extensions

 Policy alternative vocabulary is the policy types included in specific policy

alternative.

4.3.4 Policy Subject, Policy Scopes, Policy Expressions and Policy

Attachments
 Policy subject indicates whether the policy is associated with web service, a message
or another resource.
 As single policy can have more than one subject, collection of policy’s subjects is
called as policy scope.
 Policy expressions include implementation of policy assertions using WS-Policy
language.
 Policy attachments physically bind policy expressions to policy scopes.

4.3.5 Policies and SOA

 Policies provide means of communication of constraints, rules and guidelines about
every aspect of service interaction in enterprise-level and service-oriented
environments.
 Policies enhance the expression of services.
 Policies facilitate the use of available metadata to the services but still retain their
respective independence.
 The relation of policies to other parts of SOA as is shown in Fig. 4.3.3.

Fig. 4.3.3 Policies relating to other parts of SOA

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 16 Web Services Extensions

4.4 WS - Coordination
 Every activity that takes place consists of small tasks which are executed for certain
time and possess certain context.
 The description of context is called as context information.
 As the complexity of activity increases the context information also increases.
 Typically the complexity of activity depends on : amount of participating services,
duration of activity, frequency of changes in activity, concurrent execution of the
multiple instances of activity.
 This scenario can be understood from Fig. 4.4.1.

Fig. 4.4.1 Coordination provides services that introduce controlled structure into activities

4.4.1 Coordinator Composition

 The framework for WS-coordination is called as coordinator service model.
 As shown in Fig. 4.4.2 the service controls composition of three other services.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 17 Web Services Extensions

Fig. 4.4.2 The coordinator service composition

 This coordination composition has following services :

o Activation service : It creates new context and associate this context to an
activity.
o Registration service : It allows participation service to use context information
from activation services.
o Protocol specific services : These represent protocol supported by
coordinator’s coordination type.
o Coordinator : It is called as coordination service.

4.4.2 Coordination Types and Coordination Protocols

 Coordination type tells the nature and the logic of the activity included in the
context information.
 The two coordination types are :
o WS-Atomic Transaction
o WS-Business Activity
 Coordination protocols consist of collection of behaviour and rules of variations in
coordination types.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 18 Web Services Extensions

4.4.3 Coordination Contexts and Coordination Participants

 Coordination context is collection of information that represents the activity and the
supplementary data used.
 In short it is the context created by activation service.
 Coordination context included the data of unique identifier representing activity,
expiration value and coordination type information.
 The participating service known as participant first requests the coordination
context from activation service.
 This context is used to register for one or more coordination protocols.

4.4.4 The Activation and Registration Process

 The WS-coordination registration process is shown in Fig. 4.4.3.
 The process is as follows :
o The application service first contact activation service through create
coordination context request.
o New set of context data is generated.
o After receiving ReturnContext message application service invites other
services to participate in coordination.
o This invitation contains the context information received from activation
service.
o The web service which has this context information can issue registration
request to the registration service.
o By this the services is enlisted in the coordination based protocol.
o The service officially becomes a participant after successful registration.
o In the next step registration service pass the location of coordination service to
a service.
o All participants are required to interact with this coordination service.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 19 Web Services Extensions

Fig. 4.4.3 The WS-Coordination registration process

4.4.5 The Completion Process

 The WS-Coordination completion process is shown in Fig. 4.4.3.
 As shown in the Fig. 4.4.3 the application service issues completion request message
to coordination service for request of coordination completion.
 After this request coordination issues own completion request to all coordination
participants.
 Participant service sends completion acknowledgment for message upon
completion of this activity.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 20 Web Services Extensions

Fig. 4.4.4 The WS-Coordination completion process

4.4.6 Coordination and SOA

 WS-Coordination provides the standard to management and interchange of context
information.
 The relation of coordination with other parts of SOA is shown in Fig. 4.4.4.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 21 Web Services Extensions

Fig. 4.4.5 Coordination as it relates to other parts of SOA

4.5 WS-Transactions
 Transactions are the important part of automated computed solutions.
 As shown in Fig. 4.5.1 atomic transactions are applied as part of an activity.

Fig. 4.5.1 Atomic transactions apply an all-or-nothing require part of an activity

ACID Transactions :
 The characteristics of ACID transactions are :
o Atomic : with scope of transaction all the changes succeed or none of them
succeed.
o Consistent : Data changes from request of transactions should not violate the
validity of associated data models.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 22 Web Services Extensions

o Isolated : Isolated execution environment should be assured even if multiple

transactions execute concurrently.
o Durable : Once the transaction is completed the result should not be affected
by failures.
4.5.1 Atomic Transaction Protocols
 Primary atomic transaction protocols are :
o Completion protocol : It is used is initiate commit or abort states.
o The Durable 2PC protocol : Services representing permanent data repositories
should register for this protocol.
o The volatile 2PC protocol : It is meant for services who manages temporary
data.
4.5.2 The Atomic Transaction Coordinator
 The coordinator controller service is called as atomic transaction coordinator when
ws-Atomic Transaction protocols are used with it.
 As shown in Fig. 4.5.2 the main role of atomic transaction coordinator is to manage
the participants and to decide transactions outcome.

Fig. 4.5.2 The atomic transaction coordinator service model

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 23 Web Services Extensions

4.5.3 The Atomic Transaction Process

 The atomic transaction coordinator has responsibility of deciding outcome of
transaction. This decision is done on the feedback from the participants.
 The feedback is given in two phases.

Fig. 4.5.3 The coordinator requesting that transaction participants prepare to vote

1. Prepare phase : As shown in Fig. 4.5.3 coordinator sends notification to the

participants and each participant is asked to issue a vote, consisting of commit
or abort request as shown in Fig. 4.5.4.

Fig. 4.5.4 The transaction participants voting on the outcome of the atomic transaction

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 24 Web Services Extensions

2. Commit phase : After receiving the atomic transaction coordinator review the
votes and decides whether to commit or rollback the transaction.
If all votes are for commit the transaction is declared as successful and further
commitment action is taken.
If any of the votes is abort or the participants fail to respond, transaction is
aborted and roll back is done as shown in Fig. 4.5.5.

Fig. 4.5.5 The coordinator aborting the transaction and

notifying participants to rollback all changes

4.5.4 Atomic Transaction and SOA

 The relation of atomic transaction to other parts of SOA is shown in Fig. 4.5.6.
(See Fig. 4.5.6 on next page)
 As number of services increased in an organization to ensure the quality atomic
transactions are very important.

4.6 WS-Security
 Service oriented applications need to handle the demands of protecting information.
 The three core specifications considered in security are -
o WS-security
o XML-Signature
o XML-Encryption
 In this section five security requirements are discussed : identification,
authentication, authorization, confidentiality and integrity.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 25 Web Services Extensions

Fig. 4.5.6 Atomic transaction relating to other parts of SOA

4.6.1 Identification, Authentication and Authorization

 The following steps are carried out in identification :
o First service requestor should provide the information about its origin or
owner. This is called as making a claim as shown in Fig. 4.6.1.
o Claims are identification information in SOAP header.
o A standardized header block is established by WS-Security for this purpose,
which is known as taken.

Fig. 4.6.1 An identity is a claim made regarding the origin of a message

Fig. 4.6.2 Authentication means proving an identity

 As shown in Fig. 4.6.2 through authentication the service needs to provide proof to
tell that claimed identify is true.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 26 Web Services Extensions

 As shown in Fig. 4.6.3 through authorization the recipient of the message can
determine what is requestor is allowed to do.

Fig. 4.6.3 Authorization means determining to what extent authentication applies

4.6.2 Single Sign On

 As services are independent from each other to handle the security context after the
authentication of requestor concept of single sign on is used.
 In single sign on service requestor is authenticated once and then shares its security
context information with other services.
 Implementation of single sign on is supported by the extensions.
o SAML (Security Assertion Markup Language)
o .Net Passport
o XACML (XML Access Control Markup Language)
 Consider the example of SAML, in SAML the single point of contact for service
request can also be considered as issuing authority.
 So the other services contacted by service requestor do not perform authentication
and authorization.
 After the services receive the request they contact issuing authority for
authentication and authorization.
 This information is provided in the form of assertion as shown in Fig. 4.6.4.

4.6.3 Confidentiality and Integrity

 As shown in Fig. 4.6.5 confidentiality protects the privacy of message contents.
 If the no service in the message path is able to see the contents of message then the
message is considered to be secure and confidential.
 If the message is tampered after departure from sender then integrity is achieved.
 This is shown in Fig. 4.6.6.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 27 Web Services Extensions

Fig. 4.6.4 A basic message exchange demonstrating single sign-on

(in this case, as implemented by SAML)

Fig. 4.6.5 Confidentiality means that the privacy of the message has been protected throughout
its message path

Fig. 4.6.6 Integrity means ensuring that a message's contents

have not changed during transmission

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 28 Web Services Extensions

4.6.4 Transport-Level Security and Message Level Security

 The technology used decides the extent of protection of the message in its path.
 Message level security ensures that the message is getting protected in its entire
path.
 To ensure this security measures are applied to message itself as shown in Fig. 4.6.7.

Fig. 4.6.7 Message-level security guarantees end-to-end message protection

4.6.5 Encryption and Digital Signatures

 XML Encryption and XML Signature extensions facilitate security control to ensure
confidential and integrity of the message.
 Through XML Encryption, entire message can be encrypted or specific part can also
be encrypted.
 Through XML signature uses special algorithm driven piece of information with
XML document which is known as digital signature.
 If the contents of the document are intact then only signatures verification by
receiving service will be successful.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 29 Web Services Extensions

 These two features are shown in Fig. 4.6.8.

Fig. 4.6.8 A digitally signed SOAP message containing encrypted data

4.6.6 Security and SOA

 Security features are important in message transmission for either protection of
message content of message recipient.
 WS - security provides the facility of using service oriented solutions for handling
sensitive and private data.
 It also restricts the service access.
 Fig. 4.6.9 shows the relationship of security with SOAP messages and web services.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 4 - 30 Web Services Extensions

Fig. 4.6.9 Security, as it relates to policies, SOAP messages and Web services




TECHNICAL PUBLICATIONS® - An up thrust for knowledge

 UNIT - V

5 Service Oriented Analysis

and Design
Syllabus
SOA delivery strategies - Service oriented analysis - Service modelling - Service oriented
design - Standards and composition guidelines - Service design - Business process design -
Case Study.

Contents
5.1 SOA Delivery Strategies
5.2 Service Oriented Analysis
5.3 Service Modelling
5.4 Service Oriented Design
5.5 Standards and Composition Guidelines
5.6 Service Design
5.7 Business Process Design

(5 - 1)
Service Oriented Architecture 5-2 Service Oriented Analysis and Design

5.1 SOA Delivery Strategies

 Typically service oriented solution of SOA delivery project consists of the phases as
shown in Fig. 5.1.1.

Fig. 5.1.1 Common phases of an SOA delivery lifecycle

 Please note that unlike the other phases, first two phases are termed as service
oriented as SOA characteristics and service orientation principles are used for
building the solution.
 These life cycle phases are described as below :
1. Service oriented analysis :
o In this first stage the scope of SOA is determined.
o Other activities include :
 Mapping of service layers
 Modeling of individual services as service candidates
2. Service oriented design :
o This is a standard driven phase which includes industry conventions and
service orientation principles for designing the services.
o For formal business process deformation is obtained among or layer in this
phase.
o In this phase service designer can decide the key decisions to be taken for
establishing the logic boundaries included in the services.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-3 Service Oriented Analysis and Design

3. Service development :
o This is an actual construction phase
o Choice of programming language in suitable development environment is
done.
o This helps in knowing the physical form of services and orchestrated business
process according to design.
4. Service testing :
o As the services can be reused the rigorous testing is required before the
deployment.
o Some key factors which can be considered one types of service requestors,
fulfillment of policy assertions, communication of service semantics by service
descriptions, case in composition, data type related etc.
5. Service deployment :
o In this phase the installation and configuration of distributed components is
done along with service interfaces, middleware products on production
servers.
o Some of the issues which may be faced are distribution of services,
infrastructural adequacy for fulfilling processing requirements, effect of new
services on existing services, version management, scalability requirement
analysis, etc.
6. Service administration :
o This phase focuses on various applications management and administration
concerns for distributed and component based application.
o The issues which may be faced in this phase are :
 Monitoring of the services.
 Version control management of service description documents.
 Tracing and management of messages.
 Detection of performance bottlenecks.

SOA Delivery Strategies

 The SOA delivery life cycle phases can be organize according to the preferences
fulfillment of immediate project specific requirements and coordinate application,
business and process service delivery.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-4 Service Oriented Analysis and Design

 Catering to this strategies which can be used are :

1. Top-down
2. Bottom-up
3. Agile

The Top-down Strategy

 Fig. 5.1.2 shows common top down strategy process steps.

Fig. 5.1.2 Common top-down strategy process steps

 Please note that it is assumed that business requirements are already collected and
defined.
 The stepwise description can be given as :

Step 1 : Define relevant enterprise - wide ontology

o Ontology is useful for classification of information sets processed by an
organization.
o Due to ontology common vocabulary and relation of information sets is
achieved.
o The large organizations with multiple business areas can have different
ontologies.

Step 2 : Align relevant business models (including entity models) with new of revised
ontology.
o In this step business models are adjusted to represent the ontology given by
ontology in business modeling terms.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-5 Service Oriented Analysis and Design

Step 3 : Perform service oriented analysis

o This is a service oriented analysis phase.

Step 4 : Perform service oriented design

o This is a service oriented design process in which service layers are formally
defined.

Step 5 : Develop the required services

o In this step, based on design specifications service development is done.

Step 6 : Test the services and all service operations

o In this step, necessary quality assurance checks are done for service operation.

Step 7 : Deploy the services

o In this step, the solution deployment is done.

Advantages of top-down approach :

 The top down approach facilitates high quality service architecture.
 The design and parameters around each service is analysed which maximizes
reusability potential and enabling streamlined composition.

Disadvantages of top-down approach :

 Time and money is the constraint.
 Significant investment is needed by the organizations without immediate results.
The bottom-up strategy :
 The common bottom up strategy process steps are
 In this approach the service are built according to need.
 The services include application logic for servicing immediate requirement of
solution.
 The stepwise description of the bottom up strategy can be given as :

Step 1 : Model required application services

o In this step application requirements are defined.
o The requirement include establishment of point-to-point integration channel
between legacy systems as B2B solutions.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-6 Service Oriented Analysis and Design

Step 2 : Design the required application services

o Some services which are modeled in step 1 are delivered need purchase or
lease is third party wrapper services.
o Custom application services should undergo design process where consisting
is ensured by application of design standard.

Step 3 : Develop the required application services

o In this step application services are developed following respective service
descriptions and design specifications.

Step 4 : Test the services

o Whether the services are tested to ensure that if the processing requirements
use fulfilled.

Step 5 : Deploy the services

o In this step deployment of application services is done is production.

Fig. 5.1.3 Common bottom-up strategy process stops

Advantages of bottom-up strategy

 Majority organizations follow this.
 Organizations add web services to existing application environment to have benefits
of web service technology set.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-7 Service Oriented Analysis and Design

Disadvantages of bottom up strategy

 It is not a valid approach to achieve contemporary SOA.
 Bottom-up approach facilitates effective creation of web services but
implementation of proper SOA needs inclusion of new standardized service layers.

The agile strategy

 Fig. 5.1.4 shows the sample agile strategy process.
 It is more complex than top down and bottom up strategies explained earlier as the
balance need to be achieved between inclusion of service oriented design principles
to business analysis environment without waiting for integrating web services
technology in technical environment.
 The process can be described by following steps :
Step 1 : Begin the top down analysis, focusing first on the key parts of the ontology
and related business entities.
o It follows top down analysis with narrowing the focus.
o The business models related to business logic are given immediate priority.

Step 2 : When the top down analysis has sufficiently progressed, perform service
oriented analysis.
o In this step, it is determined that ongoing top down analysis is enough
matured to proceed with creation of business service models.

Step 3 : Perform service oriented design.

o In this step service layers are defined and individual services are designed.

Step 4, 5 and 6 : Develop, test and deploy the services.

o In this step the services are developed their testing is done and deployment is
carried out.

Step 7 : As the top-down analysis continues to progress, revisit business services.

o In this step review business between is carried out and their design is
compared with current state of business models.
Advantages and disadvantages of agile strategy :
 This approach takes the advantage of top down and bottom up approach.
 This result is increased efforts in delivery.
 Additional maintenance is required to ensure the alignment of services with
business models.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-8 Service Oriented Analysis and Design

Fig. 5.1.4 Sample agile strategy process

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5-9 Service Oriented Analysis and Design

5.2 SOA Oriented Analysis

 Service oriented analysis is the
process of representing business
automation requirements through
service orientation.
 The goals of service oriented
analysis are :
o Service operation candidates
defining.
o Grouping service operation
candidates based on context.
o Service boundary definition.
o Identification of
encapsulated logic
o Ensuring context of
encapsulated logic.
o Depending composition
model.

The service oriented analysis process :

 The service oriented analysis
process is a sub process of SOA
delivery life cycle.
 Fig. 5.2.1 shows the tasks included
in the service oriented analysis
process.
 Three steps as shown in the
diagram can be explained as :

Step 1 : Define business automation

requirements.
o The scope of service oriented
analysis includes creation of Fig. 5.2.1 A high-level service-oriented
services in support of service analysis process

oriented solution.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 10 Service Oriented Analysis and Design

o The requirements collection for the given scope and their documentation is
needed.
o For defining high level automation process the requirements should be
properly defined.

Step 2 : Identify existing automation systems.

o For the requirements gathered is step 1 existing application logic need to be
identified.
o This information is required to identify application service candidates in
step 3.

Step 3 : Model candidate’s services

o Service modeling is a process for identification of operation candidates and
grouped into logical context.
o These groups result in service candidates which in turn are grouped to create
compose model.

5.3 Service Modeling

 To understand the concept service modeling first we need to understand the terms
services and service candidates.
 We know that the output of service oriented analysis stage is what we need to
design and implement in next phases.
 At analysis stage design cannot be implemented.
 It is just an analysis which proposes a logic which can be used as an input in so
design phase.
 So we can say that abstract candidates are produced which may or may not be
present in concrete design.
 Hence we create service candidates and not the services.
 Add service operations cannot state but we can propose service operation
candidates.
 With this context we say that result of service modeling process is service
candidates and service operation candidates.

Process description
 The sample service modelling process consists of 12 steps as shown in Fig. 5.3.1.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 11 Service Oriented Analysis and Design

Fig. 5.3.1 A sample service modeling process

 The stepwise description can be given as :

Step 1 : Decompose the business process

o In this step business process is broken into granular process step 1 based on
process’s workflow logic.

Step 2 : Identify business service operation candidates

o This step includes identification of the steps in business process which cannot
be part of the logic need to consider by service candidate.
o The examples of these process include manual process steps which cannot be
automated and process steps performed by existing legacy logic.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 12 Service Oriented Analysis and Design

Step 3 : Abstract orchestration logic

o This step include identification of parts of processing logic which can be
abstracted by orchestration layer examples are business rules, conditional
logic, exception logic and sequence logic.

Step 4 : Create business service candidates

o In this step the processing steps which can be grouped according to logical
context are determined each context is a service candidate.

Step 5 : Refine and apply principles of service orientation

o In this step the key service orientation principles are applied to understand the
underlying logic of each service operation candidates and make necessary
adjustments.

Step 6 : Identify candidate service compositions

o In this step the set of common scenarios are identified.
o This is beneficial for understanding if grouping of process steps in appropriate
to figure out relation between orchestration and business service layers, for
identifying potential service composition etc.

Step 7 : Revise business service operation grouping

o In this step the grouping done in step 6 is revised and revisited and revision of
organization of service operation candidates is done if required.

Step 8 : Analyze application processing requirements

o This is an optional step and is suitable for complex business process.
o The aim of this step is to study in detail the underlying processing
requirements of service candidates to extract some more technology centre
service candidates.

Step 9 : Identify application service operation candidates

o In this step application logic processing requirement is broken in series of
steps, labeling will be done based on performing function.

Step 10 : Create application service candidates

o In this step processing steps are grouped based on the context for example the
primary context can be logical relationship between operation candidates.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 13 Service Oriented Analysis and Design

Step 11 : Revise candidate’s service compositions.

o The step takes input from step 5 to revisits the identified scenarios.
o Due to this mapping of elaborate activities is done.
Step 12 : Revise application service operation grouping.
o Due to results of mapping the scenarios from step 11 some changes in
grouping and definition of application service operation candidates is done.
This step is used to handle it.
5.4 Service Oriented Design
 Service oriented design is a process in which physical service designs are derived
from logical service candidates and assembled with abstract compositions to
implement a business process.
 The goals of this process are :
o Figure out set of architectural extensions
o Setting boundaries of architecture
o Identification of design standards
o Defining abstract service interface designs
o Identification of potential service compositions.
o Assessment of the support for service oriented principles
o Find out support for characteristics of contemporary SOA.
The service oriented design process
 The high level service oriented design process is shown in Fig. 5.4.1.
 The step wise description is as follows :
Step 1 : Compose SOA
o In SOA the individual instance of service oriented architecture can be
composed.
o Following steps are carried out to accomplish this task.
1. Choosing service layers
2. Positioning core SOA standards
3. Choosing SOA extensions
Step 2 to 4 : Design services
o Designing the services consists of three separate processes.
 Entity-centric business service design process
 Application service design process
 Task centre business service design process.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 14 Service Oriented Analysis and Design

Fig. 5.4.1 A high-level service-oriented design process

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 15 Service Oriented Analysis and Design

Step 5 : Design service oriented business process

o In this step formal and executable deformation of workflow logic which can be
translated into creation of WS-BPFL process definition is generated.

5.5 Standards Composition Guidelines

 The technology components that are to be taken care of while composing SOA are :
o XML data representation architecture and
o Industry standards used for building web services
o A platform to host and process XML data and web services as shown in
Fig. 5.5.1.

Fig. 5.5.1 The most fundamental components of an SOA

 While composing SOA following points should be taken focused on :

o Types of services to be built and their organization in service layers.
o Supporting standards
o Available extensions
 Steps for composing SOA are shown in Fig. 5.5.2.
 The steps can be described as :

Step 1 : Choose service layers

o This step include :
 Deciding design configurations for service layers for standardize logic
representation.
 Study candidate service layers produced in service oriented analysis
phase.

Step 2 : Position core standards

o This step include :
 Core standard assesment in SOA
 Implementation of these standards supports various features and
requirements.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 16 Service Oriented Analysis and Design

Fig. 5.5.2 Suggested steps for composing a preliminary SOA

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 17 Service Oriented Analysis and Design

Step 3 : Choose SOA extensions

o This step include :
 Choosing of contemporary SOA characteristics
 To find out which WS - * specifications to be included.

Considerations for choosing service layers

Fig. 5.5.3 Designated service layers organize and standardize Web services within SOA.

 As shown in Fig. 5.5.3 this step includes configuration of service layer within your
environment.
 To take the decisions like whether to build business services and other decisions
related to service layers.
 Some guidelines which are very helpful are :
o Existing configuration : For the standardized service layered within
enterprise, new service designs can be added.
o Required standards : New type of services or service layers can be built
according to written design standards which are applicable to the current and
future projects.
o Service composition performance : Carrying out performance tests in
essential which deciding multi-level service layer configuration to handle the
validation deserialization and serialization steps to process contents of soft
messages.
o Service deployment : While designing service layered the latency can be
induced in deployment due to centrally located reusable services. Redundant
deployment of the services can be done to address this problem.
o Service versioning : The versioning system should be in place to handle the
additional extensions to complete the features set.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 18 Service Oriented Analysis and Design

o Business services and XSD schema design : To consider existing set of XSD
schema is important while using the entity centric business services as they
process document entities accompanied by entity centric schema.
o Business Service maintenance : To cater with agile delivery strategy ongoing
maintenance of business service is required separate administration process is
needed for keeping the business logic representation of the services in
synchronization.
Consideration for positioning core SOA standards :
 Establishment of standards is very important in SOA composition. Some standards
which can which can be used are described in this section.
Industry standards and SOA
 The SOA should be standardized in fundamental layer of technology architecture
w.r.t versions
 The core specifications found in SOA are shown in Fig. 5.5.4.

Fig. 5.5.4 The operational relationship between core SOA specifications

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 19 Service Oriented Analysis and Design

XML and SOA

 In contemporary SOA data representation is done through XML.
 Any SOA is considered as successful if it builds on and is in alignment and
underlying XML data representation.
 With this context various issues which can be faced are RPC style versus document
style SOAP messages.
 In traditional data representation architectures, XML documents are modified
according to data model.
 Due to this, the communications framework be need to use RPC style SOAP
messages, which results in conflict with document style messaging model used by
some WS - * specifications.
The WS-I basic profile
 Basic profile is set of mature and core specifications to support web services
platform.
 Evaluations of specification are done on version to version bases.
 Typically versions 1.0 and 1.1 are the versions by which the organizations
standardize the specifications as :
WSDL 1.1, SOAP 1.1, UDDI 2.0, XML 1.0, XML schema 1.0
WSDL and SOA
 WSDL definition creation is important part in SOA delivery life cycle.
 Some issues related to WSDL design within SOA are :
 Standardized use of name spaces :
o Name space standardization is important as WSDL documents contain
elements with different specifications like SOAP, XML schema and WSDL
specification.
 Modular service definitions :
o WSDL documents can be modularized for reusing and centralized
maintenance.
 Compatibility of granularity :
o XML document granularity relates to a service interface granularity but WSDL
first approach may conflict with existing XML document structure.

XML schema and SOA

 XML schema definitions (XSD schemes) are responsible for establishing data
integrity in service oriented architecture.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 20 Service Oriented Analysis and Design

XSD schemas can be utilized in support of SOA as follows :

Modular XSD schemas :

 By dividing XSD schemas flexible data representation architecture can be
established and at run time the modules can be assembled using include/import
statements.

Document style messages and XSD schemas :

 Document style messages are more intelligence heavy so require more validations
 Due to this extensible or redefined schemas need to be used.

SOAP and SOA

 SOAP messages are as fundamental as WSDL definitions.
 Two primary areas in which SOAP messaging is affected are :
1. SOAP message style and data types :
o The preferred payload structure and data type system are affected by SOA.
2. SOAP headers
o WSDL definition provides partial description of SOAP messages and they do
not give the information of SOAP header blocks which are implemented
through WS - * extensions.
Name spaces and SOA
 Name spaces in SOA should be considered as identified of business technology
domain so additional standards are needed so ensure the proper use of name spaces
in XML documents outside of WSDL definition boundaries.
UDDI and SOA
 UDDI is a central discovery mechanism in and across SOA.
 Hence based on scope and design service oriented architecture, UDDI is one of the
technology as which is established as overall so environment.

5.6 Service Design

 It is very important to design the services properly to achieve the accuracy in
representing the context and function of corresponding service candidates.
 The balanced service design should be able to encapsulate require amount of logic
conform to service oriented principles and meet business requirements
 According to four main types of service layers the design sequence described in this
section includes :

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 21 Service Oriented Analysis and Design

1. Entity - centric business services

2. Application services
3. Task centric business services
4. Process services

Fig. 5.6.1 Entity-centric services establish the business service layer

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 22 Service Oriented Analysis and Design

 While designing the care should be taken to adher to the firm set of design
standards to achieve successful SOA.
1. Entity centric business service design :
 As shown in Fig. 5.6.1 the purpose of entity centric business service is accurate
representation of data entities in organizational business model.
 These services can be reused by any application which wants to access or manage
information of particular entity.
 The step by step design process description of entity centric business service design
is shown in Fig. 5.6.2. (See Fig. 5.6.2 on next page)
 Please note that the order of executions these step can be altered according to the
need.
 But at the end the case should be taken to apply the design standards equally to all
the operations.
 The process can be described step by step as follows :
Step 1 : Review existing services :
o It is necessary to confirm that the service which is getting designed in required
or not.
o It is should be ensured that if these exists a service which is providing all the
functionalities or the context in the operation candidates.

Step 2 : Define the message schema types :

o The formal definition of the messages to be processed by service is essential at
the beginning a design.
o This is done by formalizing the message structures definitions in WSDL type
area.
o XSD schema is beneficial. This is an entity centric schema which is basis of
WSDL definition.

Step 3 : Derive an abstract service interface

o To define service interface following three steps are carried out
1. Generic structure and reusability of operation candidate is ensured and set
of operation names is established by studying data structures in step 2.
2. Port Type or interface area is created in WSDL document and operation
construct is used to populate it.
3. By defining the message construct the within child part element do the
formalization of input and output values of respective operation logic.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 23 Service Oriented Analysis and Design

Fig. 5.6.2 The entity-centric business service design process

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 24 Service Oriented Analysis and Design

Step 4 : Apply principles of service-orientation

o Apply the principles of service orientation i.e. reusability, autonomy,
statelessness, and discoverability.
Step 5 : Standardize and refine the service interface
o Following action can be taken to achieve a standard service design.
 Take review of existing design standards and apply the appropriate ones.
 Revise service design to support some contemporary SOA characteristics
 Consider WSI basic profile.

Application service design

 As shown in Fig. 5.6.3 application services occupy bottom sub layer of composed
service layer.
 They carry out the task given to them by business and orchestration layer.

Process Description
 Fig. 5.6.4 shows the step of application service design process.
 The stepwise description can be given as follows :

Step 1 : Review existing services

o Before designing new application service existing inventory need to be
checked to check if the functionality required by service candidates already
exist in some form or not.

Step 2 : Confirm the context

o In view of immediate business requirement fulfillment it may happen that
context by established context by existing service might not be considered.
o To address this candidate grouping is reevaluated and compared with existing
design.

Step 3 : Derive an initial service interface

o First service interface can be designed by following steps
1. We need to ensure the generisity and reusability of the logic partitions by
operation candidates.
2. Use XSD schema constructs to document input and output value of
operation candidate.
3. Abstract service definition is completed by adding prototype area.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 25 Service Oriented Analysis and Design

Fig. 5.6.3 Application service establish the bottom sub-layer of the service layer

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 26 Service Oriented Analysis and Design

Fig. 5.6.4 The application service design process

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 27 Service Oriented Analysis and Design

Step 4 : Apply principles of service orientation

o In this step four principles of service orientation i.e. reusability, autonomy,
statelessness and discoverability are addressed.
o It should be ensured that :
 Operation candidates should be generic and reusable.
 Underlying application logic does not impose dependencies an service.
 Due to interfacing with variety of platforms and implemention
environment stateless application service design can be carried out be
maximum upfront analysis.
 Discovery mechanism will ensure that the design will not overlap with the
existing designs.

Step 5 : Standardize and refine the service interface

o To achieve standard and streamlined service design following actions can be
taken.
 Application of existing design standards
 Review any SOA characteristic and check the support provided to it in the
design.
 Incorporate WS I basic profile

Step 6 : Outfit the service candidate with speculative features.

o To enhance the usability adding features to service design.

Step 7 : Identify technical constraints

o Application services should take low level, read world considerations into
account.

Task centric business service design

 As reuse is not the primary good only service operation candidates are considered
in these service, so it is easy to design than as compared to previous two.
 Fig. 5.6.5 shown the position of task centric business services.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 28 Service Oriented Analysis and Design

Fig. 5.6.5 Task-centric business services can comprise the business service layer,
along with entity-centric neighbors

Process description
 Fig. 5.6.6 shows the task centric business service design process.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 29 Service Oriented Analysis and Design

Fig. 5.6.6 The task-centric business service design process

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 30 Service Oriented Analysis and Design

 The stepwise description can be given as follows :

Step 1 : Define workflow logic
o In this step the logic for every positive interaction scenario is defined
o Traditional modelling approaches are used for this step for activity diagram
Step 2 : Derive the service interface
o Following step are carried out to do this
1. Set of corresponding operations are derived
2. Include activity diagrams and workflow logic
3. Do the documentation of input and output values and populate types
sections with XSD schema types.
4. Build WSDL definition by creation of prototype

Step 3 : Apply principles of service orientation

o Consider the principles of service orientation i.e. reuse atomicity, statefullness
and discoverability.
Step 4 : Standardize and refine the service interface
o Following action can be taken achieve standard service design.
 Include existing design and standards
 Ensure the support of service interface design to SOA characteristic
 Consider WS I profile standards and best practice.
Step 5 : Identify required processing
o In this step it is ensured that needed underlying service layers are in place to
supporting processing requirements.

5.7 Business Process Design

Service oriented business process design

 The first part of process is to correctly interpret the collected business process
requirements
 The second part includes the implementation of these requirements
 In traditional way the business process was done by analysis modeling tools. The
diagrams were used by architects and developers for implementation.
 The logic realization can only be done through workflow diagrams and the related
documents which is the drawback of this system.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 31 Service Oriented Analysis and Design

Fig. 5.7.1 A concrete definition of a process service designed using a process modeling tool

 The gap can be eliminated by operational business modeling languages like WS-
BPEL, through which technical analyst and architects graphically create business
process diagrams.
 The requirement of using these tools is uses should have sufficient knowledge of
these tools.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 32 Service Oriented Analysis and Design

 Fig. 5.7.1 explains this, where analysts vision of the process of front end and
computer executable process on back end is given to architects and developers for
immediate implementation.

Process description :
 Similar to task-centric business service design the high level process of designing
business process can be formulated as shown in Fig. 5.7.2.
 These steps is the guideline WS-BPEL process definition
 The stepwise description can be given as follows :

Step 1 : Map out interaction scenarios

o In this step message exchange process service is designed which includes :
 Generated workflow logic from service modelling process
 Creation of process service candidates
 Creation of existing service design

Step 2 : Design the process service interface

o In this step service definition for the process service is defined.
o Even if WSDL definition is autogenerated to receive and reuse it following
guidelines are used.
 Moving XSD schema to separate file as we need to document the input
and output values for each operation and populate the types section is
XSD scheme.
 Building WSDL definition by creation of prototype area.
 Adding meta information through documentation element.
 Application of additional design standards

Step 3 : Formalize partner service conversations

o In this step WS-BPEL process definition is done by using following steps :
1. Define participating partner service and assign the role to it.
2. In early partner service partner link type construct should be added at the
end.
3. In the process definition create partner link element.
4. For incoming and outgoing message exchange with partner services define
variable element.

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 33 Service Oriented Analysis and Design

Fig. 5.7.2 A high-level process for designing business processes

TECHNICAL PUBLICATIONS® - An up thrust for knowledge

Service Oriented Architecture 5 - 34 Service Oriented Analysis and Design

Step 4 : Define process logic

o This step is a process which completes the process definition by using the
existing information like workflow intelligence and transpose and implement
it in WS-BPFL process definition.

Step 5 : Align interaction scenarios and refine process

o This is an optional step which facilities for revisiting the interaction scenario
and review WS-BPFL process.
o Some of the advantages of alignment of interaction scenario with process
logic.
 Service interaction maps are useful in future maintenance and knowledge
transfer.
 Useful test cases are generated from service interaction maps.
 In case while implementing WS-BPFL activities new at process logic
activities are generated discovery of new exception conditions can be
addressed through WS-BPFL process definition.




TECHNICAL PUBLICATIONS® - An up thrust for knowledge