DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING · CS6659/ARTIFICIAL INTELLIGENCE M.I.E.T. /CSE/ III...

M.I.E.T. ENGINEERING COLLEGE

(Approved by AICTE and Affiliated to Anna University Chennai)

TRICHY – PUDUKKOTTAI ROAD, TIRUCHIRAPPALLI – 620 007

DEPARTMENT OF COMPUTER SCIENCE AND

ENGINEERING

COURSE MATERIAL

CS6659 ARTIFICIAL INTELLIGENCE

IV YEAR - VII SEMESTER




DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SYLLABUS (THEORY)

Sub. Code : CS6659 Branch / Year / Sem : CSE/IV/VII Sub.Name : ARTIFICIAL INTELLIGENCE Staff Name : S.MANIKANDAN

L T P C 3 0 0 3

UNIT I INTRODUCTION TO Al AND PRODUCTION SYSTEMS 9

Introduction to AI-Problem formulation, Problem Definition -Production systems, Control

strategies, Search strategies. Problem characteristics, Production system characteristics -

Specialized production system- Problem solving methods - Problem graphs, Matching, Indexing

and Heuristic functions -Hill Climbing-Depth first and Breath first, Constraints satisfaction -

Related algorithms, Measure of performance and analysis of search algorithms.

UNIT II REPRESENTATION OF KNOWLEDGE 9

Game playing - Knowledge representation, Knowledge representation using Predicate

logic, Introduction to predicate calculus, Resolution, Use of predicate calculus, Knowledge

representation using other logic-Structured representation of knowledge.

UNIT III KNOWLEDGE INFERENCE 9

Knowledge representation -Production based system, Frame based system. Inference -

Backward chaining, Forward chaining, Rule value approach, Fuzzy reasoning - Certainty factors,

Bayesian Theory-Bayesian Network-Dempster - Shafer theory.

UNIT IV PLANNING AND MACHINE LEARNING 9

Basic plan generation systems - Strips -Advanced plan generation systems – K strips -

Strategic explanations -Why, Why not and how explanations. Learning- Machine learning,

adaptive Learning.

UNIT V EXPERT SYSTEMS 9

Expert systems - Architecture of expert systems, Roles of expert systems - Knowledge Acquisition –

Meta knowledge, Heuristics. Typical expert systems - MYCIN, DART, XOON, Expert systems shells.

TEXT BOOKS: 1. Kevin Night and Elaine Rich, Nair B., ╉Artificial )ntelligence ゅS)Eょ╊, Mc Graw (ill- 2008.

(Units- I,II,VI & V) に. Dan W. Patterson, ╉)ntroduction to A) and ES╊, Pearson Education, にどど7. (Unit-III). REFERENCES: な. Peter Jackson, ╉)ntroduction to Expert Systems╊, ぬrd Edition, Pearson Education, にどど7. 2. Stuart Russel and Peter Norvig ╉A) – A Modern Approach╊, にnd Edition, Pearson Education

2007. ぬ. Deepak Khemani ╉Artificial )ntelligence╊, Tata Mc Graw (ill Education にどなぬ. 4. http://nptel.ac.in

SUBJECT IN-CHARGE HOD

http://nptel.ac.in/

CS6659/ARTIFICIAL INTELLIGENCE

M.I.E.T. /CSE/ III /ARTIFICIAL INTELLIGENCE




DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

COURSE OBJECTIVE

1. Study the concepts of Artificial Intelligence.

2. Learn the methods of solving problems using Artificial Intelligence.

3. Introduce the concepts of Expert Systems and machine learning.

4. To understand the contemporary techniques in machine learning.

COURSE OUTCOMES

1. Identify problems that are amenable to solution by AI methods.

2. Recognize appropriate AI methods to solve a given problem.

3. Able to interpret the problem in the given logic.

4. Implement basic AI algorithms.

5. Assess critically the technique presented and apply them to real world problems.

Prepared by Verified By

STAFF NAME HOD

(S.MANIKANDAN)

Approved by

PRINCIPAL

Sub. Code : CS6659 Branch/Year/Sem : CSE/IV/VII

Sub Name : ARTIFICIAL INTELLIGENCE Staff Name : S.MANIKANDAN






UNIT I

INTRODUCTION TO Al AND PRODUCTION SYSTEMS

Introduction to AI-Problem formulation, Problem Definition -Production systems, Control

strategies, Search strategies. Problem characteristics, Production system characteristics -

Specialized production system- Problem solving methods - Problem graphs, Matching, Indexing

and Heuristic functions -Hill Climbing-Depth first and Breath first, Constraints satisfaction -

Related algorithms, Measure of performance and analysis of search algorithms.

1.1 XML Structure

This page provides a description of XML structure including the document parts, the prologue, and provides a simple XML example document.

1.1.1 Document Parts

Prolog Document Element (root element)

1.1.2 The Prologue

The prologue, equivalent to the header in HTML, may include the following:

An XML declaration (optional) such as:

<?xml version="1.0"?>

A DTD or reference to one (optional). An example reference to an external DTD file:

<!DOCTYPE LANGLIST SYSTEM "langlist.dtd">

Processing instructions - An example processing instruction that causes style to be determined by a style sheet:

<?xml-stylesheet type="text/css" href="xmlstyle.css"?>

1.1.3 An XML Document

Therefore a complete well formed XML document may look like:

<?xml version="1.0"?> <LAND>



<FOREST> <TREE>Oak</TREE> <TREE>Pine</TREE> <TREE>Maple</TREE> </FOREST> <MEADOW> <GRASS>Bluegrass</GRASS> <GRASS>Fescue</GRASS> <GRASS>Rye</GRASS> </MEADOW> </LAND>

The LAND element, above, is the root element.

The below document is not an XML document since it does not qualify by the rules of a well formed document. There is more than one top level element which disqualifies the document from being well formed.

<?xml version="1.0"?> <FOREST> <TREE>Oak</TREE> <TREE>Pine</TREE> <TREE>Maple</TREE> </FOREST> <MEADOW> <GRASS>Bluegrass</GRASS> <GRASS>Fescue</GRASS> <GRASS>Rye</GRASS> </MEADOW>

1.1.4 Defining Display

If the HTML document is not linked to a style sheet, the XML document will be displayed with tags included. The elements and tags may be color coded to aid in viewing the document. The document is displayed without tags according to the style sheet if a link to one is specified. The following document shows a document with a link to a cascading style sheet:

<?xml version="1.0"?> <?xml-stylesheet type="text/css" href="xmlstyle.css"?> <DATABASE> <TITLE>List of Items Important to Markup Languages</TITLE> <TITLE2>Languages</TITLE2> <LANGUAGES>SGML<LANGUAGES> <LANGUAGES>XML</LANGUAGES> <LANGUAGES>HTML<LANGUAGES> <TITLE2>Other</TITLE2> <OTHER>DTD<OTHER> <OTHER>DSSL<OTHER> <OTHER>Style Sheets</OTHER> </DATABASE>

The below line, which is a part of the XML document above, is a processing instruction and is a part of the prolog.



<?xml-stylesheet type="text/css" href="xmlstyle.css"?>

The style sheet, "xmlstyle.css", may look like:

DATABASE { display: block } TITLE { display: block; font-family: arial; color: #008000; font-weight: 600; font-size: 22; text-align: center } TITLE2 { display: block; font-family: arial; color: #000080; font-weight: 400; font-size: 20 } LANGUAGES { display: block; list-style-type: decimal; font-family: arial; color: #000000; font-weight: 400; font-size: 18 } OTHER { display: block; list-style-type: square; font-family: arial; color: #0000ff; font-weight: 200; font-size: 14 }

1.2 XML - Validation

Validation is a process by which an XML document is validated. An XML document is said to be valid if its contents match with the elements, attributes and associated document type declaration(DTD), and if the document complies with the constraints expressed in it. Validation is dealt in two ways by the XML parser. They are:

Well-formed XML document Valid XML document

1.2.1 Well-formed XML document

An XML document is said to be well-formed if it adheres to the following rules:

Non DTD XML files must use the predefined character entities for amp(&), apos(single quote), gt(>), lt(<), quot(double quote).

It must follow the ordering of the tag. i.e., the inner tag must be closed before closing the outer tag.



Each of its opening tags must have a closing tag or it must be a self ending tag.(<title>....</title> or <title/>).

It must have only one attribute in a start tag, which needs to be quoted. amp(&), apos(single quote), gt(>), lt(<), quot(double quote) entities other than these must

be declared.

Example

Example of well-formed XML document:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE address [ <!ELEMENT address (name,company,phone)> <!ELEMENT name (#PCDATA)> <!ELEMENT company (#PCDATA)> <!ELEMENT phone (#PCDATA)> ]> <address> <name>Tanmay Patil</name> <company>TutorialsPoint</company> <phone>(011) 123-4567</phone> </address>

Above example is said to be well-formed as:

It defines the type of document. Here, the document type is element type. It includes a root element named as address. Each of the child elements among name, company and phone is enclosed in its self

explanatory tag. Order of the tags is maintained.

1.2.2 Valid XML document

If an XML document is well-formed and has an associated Document Type Declaration (DTD), then it is said to be a valid XML document. We will study more about DTD in the chapter XML - DTDs

1.4 XML - DTDs

The XML Document Type Declaration, commonly known as DTD, is a way to describe XML language precisely. DTDs check vocabulary and validity of the structure of XML documents against grammatical rules of appropriate XML language.

An XML DTD can be either specified inside the document, or it can be kept in a separate document and then liked separately.

Syntax

Basic syntax of a DTD is as follows:

<!DOCTYPE element DTD identifier [

http://www.tutorialspoint.com/xml/xml_dtds.htm

http://www.tutorialspoint.com/xml/xml_dtds.htm



declaration1 declaration2 ........ ]>

In the above syntax,

The DTD starts with <!DOCTYPE delimiter. An element tells the parser to parse the document from the specified root element. DTD identifier is an identifier for the document type definition, which may be the path to

a file on the system or URL to a file on the internet. If the DTD is pointing to external path, it is called External Subset.

The square brackets [ ] enclose an optional list of entity declarations called Internal Subset.

1.4.1 Internal DTD

A DTD is referred to as an internal DTD if elements are declared within the XML files. To refer it as internal DTD, standalone attribute in XML declaration must be set to yes. This means, the declaration works independent of external source.

Syntax

The syntax of internal DTD is as shown:

<!DOCTYPE root-element [element-declarations]>

where root-element is the name of root element and element-declarations is where you declare the elements.

Example

Following is a simple example of internal DTD:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE address [ <!ELEMENT address (name,company,phone)> <!ELEMENT name (#PCDATA)> <!ELEMENT company (#PCDATA)> <!ELEMENT phone (#PCDATA)> ]> <address> <name>Tanmay Patil</name> <company>TutorialsPoint</company> <phone>(011) 123-4567</phone> </address>

Let us go through the above code:

Start Declaration- Begin the XML declaration with following statement

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>



DTD- Immediately after the XML header, the document type declaration follows, commonly referred to as the DOCTYPE:

<!DOCTYPE address [

The DOCTYPE declaration has an exclamation mark (!) at the start of the element name. The DOCTYPE informs the parser that a DTD is associated with this XML document.

DTD Body- The DOCTYPE declaration is followed by body of the DTD, where you declare elements, attributes, entities, and notations:

<!ELEMENT address (name,company,phone)> <!ELEMENT name (#PCDATA)> <!ELEMENT company (#PCDATA)> <!ELEMENT phone_no (#PCDATA)>

Several elements are declared here that make up the vocabulary of the <name> document. <!ELEMENT name (#PCDATA)> defines the element name to be of type "#PCDATA". Here #PCDATA means parse-able text data.

End Declaration - Finally, the declaration section of the DTD is closed using a closing bracket and a closing angle bracket (]>). This effectively ends the definition, and thereafter, the XML document follows immediately.

Rules

The document type declaration must appear at the start of the document (preceded only by the XML header) — it is not permitted anywhere else within the document.

Similar to the DOCTYPE declaration, the element declarations must start with an exclamation mark.

The Name in the document type declaration must match the element type of the root element.

1.4.2 External DTD

In external DTD elements are declared outside the XML file. They are accessed by specifying the system attributes which may be either the legal .dtd file or a valid URL. To refer it as external DTD, standalone attribute in the XML declaration must be set as no. This means, declaration includes information from the external source.

Syntax

Following is the syntax for external DTD:

<!DOCTYPE root-element SYSTEM "file-name">

where file-name is the file with .dtd extension.

Example

The following example shows external DTD usage:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>



<!DOCTYPE address SYSTEM "address.dtd"> <address> <name>Tanmay Patil</name> <company>TutorialsPoint</company> <phone>(011) 123-4567</phone> </address>

The content of the DTD file address.dtd are as shown:

<!ELEMENT address (name,company,phone)> <!ELEMENT name (#PCDATA)> <!ELEMENT company (#PCDATA)> <!ELEMENT phone (#PCDATA)>

1.4.2.1 Types

We can refer to an external DTD by using either system identifiers or public identifiers.

System Identifiers

A system identifier enables you to specify the location of an external file containing DTD declarations. Syntax is as follows:

<!DOCTYPE name SYSTEM "address.dtd" [...]>

It contains keyword SYSTEM and a URI reference pointing to the location of the document.

Public Identifiers

Public identifiers provide a mechanism to locate DTD resources and are written as below:

<!DOCTYPE name PUBLIC "-//Beginning XML//DTD Address Example//EN">

1.3 XML - Namespaces

A Namespace is a set of unique names. Namespace is a mechanism by which element and attribute name can be assigned to group. The Namespace is identified by URI (Uniform Resource Identifiers).

1.3.1 Namespace Declaration

A Namspace is declared using reserved attributes. Such an attribute name must either be xmlns or begin with xmlns: shown as below:

<element xmlns:name="URL">

Syntax

The Namespace starts with the keyword xmlns. The word name is the Namespace prefix. The URL is the Namespace identifier.



Example

Namespace affects only a limited area in the document. An element containing the declaration and all of its descendants are in the scope of the Namespace. Following is a simple example of XML Namespace:

<?xml version="1.0" encoding="UTF-8"?> <cont:contact xmlns:cont="www.tutorialspoint.com/profile"> <cont:name>Tanmay Patil</cont:name> <cont:company>TutorialsPoint</cont:company> <cont:phone>(011) 123-4567</cont:phone> </cont:contact>

Here, the Namespace prefix is cont, and the Namespace identifier (URI) as www.tutorialspoint.com/profile. This means, the element names and attribute names with the cont prefix (including the contact element), all belong to the www.tutorialspoint.com/profile namespace.

XML Namespaces provide a method to avoid element name conflicts.

1.3.2 Name Conflicts

In XML, element names are defined by the developer. This often results in a conflict when trying to mix XML documents from different XML applications.

This XML carries HTML table information:

<table> <tr> <td>Apples</td> <td>Bananas</td> </tr> </table>

This XML carries information about a table (a piece of furniture):

<table> <name>African Coffee Table</name> <width>80</width> <length>120</length> </table>

If these XML fragments were added together, there would be a name conflict. Both contain a <table> element, but the elements have different content and meaning.

A user or an XML application will not know how to handle these differences.

Solving the Name Conflict Using a Prefix

Name conflicts in XML can easily be avoided using a name prefix.

This XML carries information about an HTML table, and a piece of furniture:



<h:table> <h:tr> <h:td>Apples</h:td> <h:td>Bananas</h:td> </h:tr> </h:table> <f:table> <f:name>African Coffee Table</f:name> <f:width>80</f:width> <f:length>120</f:length> </f:table>

In the example above, there will be no conflict because the two <table> elements have different names.

XML Namespaces - The xmlns Attribute

When using prefixes in XML, a namespace for the prefix must be defined.

The namespace can be defined by an xmlns attribute in the start tag of an element.

The namespace declaration has the following syntax. xmlns:prefix="URI".

<root> <h:table xmlns:h="http://www.w3.org/TR/html4/"> <h:tr> <h:td>Apples</h:td> <h:td>Bananas</h:td> </h:tr> </h:table> <f:table xmlns:f="http://www.w3schools.com/furniture"> <f:name>African Coffee Table</f:name> <f:width>80</f:width> <f:length>120</f:length> </f:table> </root>

In the example above:

The xmlns attribute in the first <table> element gives the h: prefix a qualified namespace.

The xmlns attribute in the second <table> element gives the f: prefix a qualified namespace.

When a namespace is defined for an element, all child elements with the same prefix are associated with the same namespace.

Namespaces can also be declared in the XML root element:

<root xmlns:h="http://www.w3.org/TR/html4/" xmlns:f="http://www.w3schools.com/furniture"> <h:table>



<h:tr> <h:td>Apples</h:td> <h:td>Bananas</h:td> </h:tr> </h:table> <f:table> <f:name>African Coffee Table</f:name> <f:width>80</f:width> <f:length>120</f:length> </f:table> </root>

Note: The namespace URI is not used by the parser to look up information.

The purpose of using an URI is to give the namespace a unique name.

However, companies often use the namespace as a pointer to a web page containing namespace information.

1.3.3 Uniform Resource Identifier (URI)

A Uniform Resource Identifier (URI) is a string of characters which identifies an Internet Resource.

The most common URI is the Uniform Resource Locator (URL) which identifies an Internet domain address. Another, not so common type of URI is the Universal Resource Name (URN).

1.3.4 Default Namespaces

Defining a default namespace for an element saves us from using prefixes in all the child elements. It has the following syntax:

xmlns="namespaceURI"

This XML carries HTML table information:

<table xmlns="http://www.w3.org/TR/html4/"> <tr> <td>Apples</td> <td>Bananas</td> </tr> </table>

This XML carries information about a piece of furniture:

<table xmlns="http://www.w3schools.com/furniture"> <name>African Coffee Table</name> <width>80</width> <length>120</length> </table>

1.5 XML schemas



An XML Schema describes the structure of an XML document. The XML Schema language is

also referred to as XML Schema Definition (XSD).The purpose of an XML Schema is to define

the legal building blocks of an XML document, just like a DTD.

An XML Schema defines elements that can appear in a document, defines attributes that can

appear in a document, defines which elements are child elements, defines the order of child

elements, defines the number of child elements, defines whether an element is empty or can

include text, defines data types for elements and attributes, defines default and fixed values for

elements and attributes.

Two Types of Schemas:

Simple Type

Complex Type

1.5.1 Simple Type

A simple element is an XML element that can contain only text. It cannot contain any other

elements or attributes.

Rules for XML structure

All XML elements must have a closing tag. XML tags are case sensitive, All XML elements

must have a proper nesting, All XML Documents must contain a single root element, Attribute

values must be quoted, Attributes may only appear once in the same start tag, Attribute values

cannot contain references to external entities, All entities except amp, lt, gt, apos, and quot must

be declared before they are used.

XML Schema has a lot of built-in data types. The most common types are:

xs:string

xs:decimal

xs:integer

xs:boolean

xs:date

xs:time

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"/>



1.5.2 Complex type:

A complex element is an XML element that contains other elements and/or attributes.

Look at this simple XML document called "note.xml":


<note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget to submit the assignment this monday!</body>

</note>

Example:

The following example is a DTD file called "note.dtd" that defines the elements of the XML

document above ("note.xml"):

<!ELEMENT note (to, from, heading, body)><!ELEMENT to (#PCDATA)>

<!ELEMENT from (#PCDATA)>

<!ELEMENT heading (#PCDATA)>

<!ELEMENT body (#PCDATA)>

The following example is an XML Schema file called "note.xsd" that defines the elements of the

XML document above ("note.xml"):


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.w3schools.com" xmlns="http://www.w3schools.com"

elementFormDefault="qualified">

<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:schema>

Structuring with schemas



A Simple XML Document:

We‘ll talk about a shirt. There‘s actually a lot we can talk about with regard to a shirt: size, color,

fabric, price, brand, and condition, among other properties. The Following example shows one

possible XML rendition of a document describing a shirt. Of course, there are many other

possible ways to describe a shirt, but this example provides a foundation for our further

discussions.

<?xml version=”1.0”?>

<shirt>

<model>Zippy Tee</model>

<brand>Tommy Hilbunger</brand>

<price currency=”USD”>14.99</price>

<on_sale/>

<fabric content=”60%”>cotton</fabric>

<fabric content=”40%”>polyester</fabric>

<options>

<colorOptions>

<color>red</color>

<color>white</color>

</colorOptions>

<sizeOptions>

<size>Medium</size>

<size>Large</size>

</sizeOptions>

</options>

<description> This is a <b>funky</b> Tee shirt similar to the Floppy Tee shirt </description>

</shirt>

1.6 X-Files XLINK

XPATH

XQuery

1.6.1 XLINK

XLink Syntax

In HTML, we know (and all the browsers know!) that the <a> element defines a hyperlink.

However, this is not how it works with XML. In XML documents, you can use whatever element

names you want - therefore it is impossible for browsers to predict what hyperlink elements will



be called in XML documents. The solution for creating links in XML documents was to put a

marker on elements that should act as hyperlinks.

Example:


<homepages xmlns:xlink="http://www.w3.org/1999/xlink">

<homepage xlink:type="simple" xlink:href="http://www.w3schools.com">Visit

W3Schools</homepage><homepage xlink:type="simple" xlink:href="http://www.w3.org">Visit

W3C</homepage>

</homepages>

1.6.2 XPATH

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. XPath is a W3C Standard.

XPath Terminology

Nodes:

In XPath, there are seven kinds of nodes: element, attribute, text, namespace, processing-

instruction, comment, and document (root) nodes. XML documents are treated as trees of nodes.

The root of the tree is called the document node (or root node).

Relationship of Nodes

Parent

Children

Siblings

Ancestors

Descendants



Predicates

Selecting Unknown Nodes



Selecting Several Paths

1.6.3 XQuery

XQuery is the language for querying XML data. XQuery for XML is like SQL for databases.

XQuery is built on XPath expressions. XQuery is supported by all the major database engines

(IBM, Oracle, Microsoft, etc.). XQuery is a W3C Recommendation.

<title lang="en">XQuery Kick Start</title>

<author>James McGovern</author>

<author>Per Bothner</author>

<author>Kurt Cagle</author>

<author>James Linn</author>

<author>Vaidyanathan Nagarajan</author>

<year>2003</year>

<price>49.99</price>

</book>

- <book category="WEB">

<title lang="en">Learning XML</title>

<author>Erik T. Ray</author>

<year>2003</year>


</book>

</bookstore>



Functions

XQuery uses functions to extract data from XML documents. The doc() function is used to open

the "books.xml" file:

doc("books.xml"), Path Expressions

XQuery uses path expressions to navigate through elements in an XML document.The following

path expression is used to select all the title elements in the "books.xml" file:

doc("books.xml")/bookstore/book/title(/bookstore selects the bookstore element, /book selects all

the book elements under the bookstore element, and /title selects all the title elements under each

book element), The XQuery above will extract the following:

<title lang="en">Everyday Italian</title>

<title lang="en">Harry Potter</title>



Predicates

XQuery uses predicates to limit the extracted data from XML documents. The following

predicate is used to select all the book elements under the bookstore element that have a price

element with a value that is less than 30: doc("books.xml")/bookstore/book[price<30]The

XQuery above will extract the following:

<book category="CHILDREN">

<title lang="en">Harry Potter</title>

<author>J K. Rowling</author>

<year>2005</year>


</book>

With FLWOR

FLWOR is an acronym for "For, Let, Where, Order by, Return". The for clause selects all book

elements under the bookstore element into a variable called $x.The where clause selects only

book elements with a price element with a value greater than 30.The order by clause defines the

sort-order. Will be sort by the title element.The return clause specifies what should be returned.

Here it returns the title elements.

Example: doc ("books.xml")/bookstore/book[price>30]/title

The following FLWOR expression will select exactly the same as the path expression above:

for $x in doc("books.xml")/bookstore/book where $x/price>30 return $x/title



The result will be:



With FLWOR you can sort the result:

For $x in doc ("books.xml")/bookstore/book where $x/price>30 order by $x/title return $x/title.

XPointer

XPointer allows links to point to specific parts of an XML document XPointer uses XPath expressions to navigate in the XML document XPointer is a W3C Recommendation

Example: <foobar id="foo"> <bar/> <baz> <bom a="1"/> </baz> <bom a="2"/> </foobar>

Results as the following examples:

xpointer (id("foo")) => foobar xpointer(/foobar/1) => bar xpointer(//bom) => bom (a=1), bom (a=2) element (/1/2/1) => bom (a=1) (/1 descend into first element (foobar), /2 descend into second child element (baz), /1 select first child element (bom)) The element () scheme introduces positional addressing of child elements. This is similar to a simple XPath address, but subsequent steps can only be numbers representing the position of a descendant relative to its branch on the tree.



Parsing XML – using DOM, SAX – XML Transformation and XSL – XSL Formatting – Modeling Databases in XML.

UNIT II BUILDING XML- BASED APPLICATIONS

2.1 XML Processing (OR) XML Parsing • The Java API for XML Processing (JAXP) includes the basic facilities for working with

XML documents.

• There are two types of XML Parsers namely Document Object Model (DOM), Simple API for XML Parsing (SAX).

2.1.1 XML DOM • The XML DOM views an XML document as a tree-structure.

• The tree structure is called a node-tree.

• All nodes can be accessed through the tree.

• Their contents can be modified or deleted, and new elements can be created.

• The nodes in the node tree have a hierarchical relationship to each other.

• The terms parent, child, and sibling are used to describe the relationships.

• Parent nodes have children.

• Children on the same level are called siblings (brothers or sisters).

• In a node tree, the top node is called the root.

• Every node, except the root, has exactly one parent node.

• A node can have any number of children.

• A leaf is a node with no children. Siblings are nodes with the same parent.

2.1.2 SAX



• SAX (Simple API for XML) is an event-driven model for processing XML.

• The SAX model is quite different when comparing with DOM.

• 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.

Event Handlers • There are three classes of event handlers:

• DTDHandlers : for accessing the contents of XML Document-Type Definitions;

• ErrorHandlers : for low-level access to parsing errors; and, the most often used,

• DocumentHandlers : for accessing the contents of the document.

• A SAX processor will pass the following events to a DocumentHandler:

1. The start of the document.

2. A processing instruction element.

3. A comment element.

4. The beginning of an element, including that element's attributes.

5. The text contained within an element.

6. The end of an element.

7. The end of the document.

Example for SAX <xml> <body> <script type="text/javascript"> try //Internet Explorer { xmlDoc=new ActiveXObject("Microsoft.XMLDOM"); } catch(e) { try //Firefox, Mozilla, Opera, etc. { xmlDoc=document.implementation.createDocument("","",null); } catch(e) { alert(e.message) } } try { xmlDoc.async=false; xmlDoc.load("books.xml"); document.write("xmlDoc is loaded, ready for use");



} catch(e) {alert(e.message)} </script> </body> </xml> 2.1.3 DOM versus SAX

DOM SAX

Type of interface Object-based Event-based

Object model Created automatically Must be created by application

Element sequencing Preserved Ignored in favour of single events

Use of memory Higher Lower

Speed of initial data retrieval

Slower Faster

Stored information Better for complex structures

Better for simple structures

Validation Optional Optional

Ability to update XML document

Yes (in memory) No

2.2 XML Presentation Technologies 2.2.1 XSL and XSLT • XSL stands for EXtensible Style sheet Language.

• XSLT stands for XSL Transformations.

• XSLT is the most important part of XSL.

• XSLT transforms an XML document into another XML document.

• XSLT uses XPath to navigate in XML documents.

• XSLT is a W3C Recommendation.

• We want to transform the following XML document ("cdcatalog.xml") into XHTML:

<?xml version="1.0" encoding="ISO-8859-1"?> <catalog> <cd> <title>Empire Burlesque</title> <artist>BobDylan</artist> <country>USA</country> <company>Columbia</company> <price>10.90</price> <year>1985</year> </cd> </catalog> Then you create an XSL Style Sheet ("cdcatalog.xsl") with a transformation template:



<?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <body> <h2>My CD Collection</h2> <table border="1"> <tr bgcolor="#9acd32"> <th align="left">Title</th> <th align="left">Artist</th> </tr> <xsl:for-each select="catalog/cd"> <tr> <td><xsl:value-of select="title"/></td> <td><xsl:value-of select="artist"/></td> </tr> </xsl:for-each> </table> </body> </html> </xsl:template> </xsl:stylesheet> • Link the XSL Style Sheet to the XML Document

• Add the XSL style sheet reference to your XML document ("cdcatalog.xml"):

<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="cdcatalog.xsl"?> <catalog> <cd> <title>Empire Burlesque</title> <artist>Bob Dylan</artist> <country>USA</country> <company>Columbia</company> <price>10.90</price> <year>1985</year> </cd> </catalog> <xsl:template> element • An XSL style sheet consists of one or more set of rules that are called templates.

• A template contains rules to apply when a specified node is matched.

• The <xsl:template> element is used to build templates.

• The match attribute is used to associate a template with an XML element.

The <xsl:for-each> Element • The XSL <xsl:for-each> element can be used to select every XML element of a specified

node-set.

The <xsl:value-of> Element • The <xsl:value-of> element can be used to extract the value of an XML element.



<xsl:sort> Element • 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. Eg: <xsl:sort select="artist"/>

XSLT <xsl:if> Element • The <xsl:if> element is used to put a conditional test against the content of the XML file.

eg: <xsl:for-each select="catalog/cd"> <xsl:if test="price > 10"> <tr> <td><xsl:value-of select="title"/></td> <td><xsl:value-of select="artist"/></td> <td><xsl:value-of select="price"/></td> </tr> </xsl:if> </xsl:for-each> • The result is:

2.2.2 XFORMS • XForms is the next generation of HTML forms.

• XForms is richer and more flexible than HTML forms.

• XForms will be the forms standard in XHTML 2.0.

• XForms is platform and device independent.

• XForms separates data and logic from presentation.

• XForms uses XML to define form data.

• XForms stores and transports data in XML documents.

• XForms contains features like calculations and validations of forms.

• XForms reduces or eliminates the need for scripting.

• XForms is a W3C Recommendation.

The XForms Model • The XForms model is used to describe the data.

• The data model is an instance (a template) of an XML document.

<xforms> <model>



<instance> <person><fname/><lname/></person> </instance> <submission id="form1" action="submit.asp" method="get"/> </model> <input ref="fname"><label>First Name</label></input> <input ref="lname"><label>Last Name</label></input> <submit submission="form1"> <label>Submit</label> </submit> </xforms>

2.2.3 XHTML • XHTML stands for EXtensible HyperText Markup Language

• XHTML is almost identical to HTML

• XHTML is stricter than HTML

• XHTML is HTML defined as an XML application

• XHTML is supported by all major browsers

The Most Important Differences from HTML Document Structure • XHTML DOCTYPE is mandatory

Strict Transitional Frameset • The xmlns attribute in <html> is mandatory

• <html>, <head>, <title>, and <body> are mandatory.

XHTML Elements • XHTML elements must be properly nested

• XHTML elements must always be closed

• XHTML elements must be in lowercase

• XHTML documents must have one root element

XHTML Attributes • Attribute names must be in lower case

• Attribute values must be quoted

• Attribute minimization is forbidden.



Syntax: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Title of document</title> </head> <body> some content </body> </html> 2.3 XSL-FO (XSL Formatting Objects) What is XSL-FO? • XSL-FO is a language for formatting XML data

• XSL-FO stands for Extensible Style sheet Language Formatting Objects

• XSL-FO is a W3C Recommendation

• XSL-FO is now formally named XSL

• XSL-FO (XSL Formatting Objects) is a replacement for CSS.

• XSL-FO is an XML-based mark-up language describing the formatting of XML data for output to screen, paper or other media.

XSL-FO Documents • XSL-FO documents are XML files with output information.

• They contain information about the output layout and output contents.

• XSL-FO documents are stored in files with a .fo or a .fob file extension.

• It is also quite common to see XSL-FO documents stored with an .xml extension, because this makes them more accessible to XML editors.

2.3.1 XSL-FO Document Structure <?xml version="1.0" encoding="ISO-8859-1"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="A4">  </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference="A4">  </fo:page-sequence> </fo:root> • The <fo:root> element is the root element of XSL-FO documents.

• The <fo:layout-master-set> element contains one or more page templates.



• Each <fo:simple-page-master> element contains a single page template. Each template must have a unique name (master-name).

• One or more <fo:page-sequence> elements describe the page contents. The master-reference attribute refers to the simple-page-master template with the same name

XSL-FO Areas • The XSL formatting model defines a number of rectangular areas (boxes) to display

output.

• All output (text, pictures, etc.) will be formatted into these boxes and then displayed or printed to a target media.

• The following types of areas:

• Pages

• Regions

• Block areas

• Line areas

• Inline areas

XSL-FO Pages • XSL-FO output is formatted into pages.

• XSL-FO Pages contain Regions.

XSL-FO Regions • Each XSL-FO Page contains a number of Regions:

– region-body (the body of the page)

– region-before (the header of the page)

– region-after (the footer of the page)

– region-start (the left sidebar)

– region-end (the right sidebar)

– XSL-FO Regions contain Block areas.

XSL-FO Block Areas • XSL-FO Block areas define small block elements (the ones that normally starts with a

new line) like paragraphs, tables and lists.

• XSL-FO Block areas can contain other Block areas, but most often they contain Line areas.

XSL-FO Line Areas • XSL-FO Line areas define text lines inside Block areas.



• XSL-FO Line areas contain Inline areas.

XSL-FO Inline Areas • XSL-FO Inline areas define text inside Lines (bullets, single character, graphics, and

more).

XSL-FO Output • XSL-FO defines output inside <fo:flow> elements.

• XSL-FO Page, Flow, and Block

• "Blocks" of content "Flows" into "Pages" and then to the output media.

• XSL-FO output is normally nested inside <fo:block> elements, nested inside <fo:flow> elements, nested inside <fo:page-sequence> elements:

Syntax: <fo:page-sequence> <fo:flow flow-name="xsl-region-body"> <fo:block>  </fo:block> </fo:flow> </fo:page-sequence> Example: <?xml version="1.0" encoding="ISO-8859-1"?> <fo:root: xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:page-sequence master-reference="A4"> <fo:flow flow-name="xsl-region-body"> <fo:block>Hello W3Schools</fo:block> </fo:flow> </fo:page-sequence> </fo:root>

The output from this code would be something like this:

XSL-FO Lists • XSL-FO uses List Blocks to define lists.

• There are four XSL-FO objects used to create lists:

– fo:list-block (contains the whole list)

– fo:list-item (contains each item in the list)

– fo:list-item-label (contains the label for the list-item - typically an <fo:block> containing a number, character, etc.)

– fo:list-item-body (contains the content/body of the list-item - typically one or more <fo:block> objects)

• An XSL-FO list example:

<fo:list-block> <fo:list-item> <fo:list-item-label> <fo:block>*</fo:block>

Hello W3Schools



</fo:list-item-label> <fo:list-item-body> <fo:block>Volvo</fo:block> </fo:list-item-body> </fo:list-item> • The output from this code would be:

* Volvo

XSL-FO Tables • XSL-FO uses the <fo:table-and-caption> element to define tables.

• The XSL-FO table model is not very different from the HTML table model.

• There are nine XSL-FO objects used to create tables:

– fo:table-and-caption

– fo:table

– fo:table-caption

– fo:table-column

– fo:table-header

– fo:table-footer

– fo:table-body

– fo:table-row

– fo:table-cell

Syntax: <fo:table-and-caption> <fo:table> <fo:table-column column-width="25mm"/> <fo:table-header> <fo:table-row> <fo:table-cell> <fo:block font-weight="bold">Car</fo:block> </fo:table-cell> <fo:table-cell> <fo:block font-weight="bold">Price</fo:block> </fo:table-cell> </fo:table-row> </fo:table-header> Example: <fo:table-body> <fo:table-row> <fo:table-cell> <fo:block>Volvo</fo:block> </fo:table-cell> <fo:table-cell> <fo:block>$50000</fo:block>



</fo:table-cell> </fo:table-row> </fo:table-body> </fo:table> </fo:table-and-caption> • The output from this code would something like this:

Car Price

Volvo $50000

2.3.2 XML FO ARCHITECTURE

2.4 Modeling Databases in XML 2.4.1 XML DATABASES

XML stands for EXtensible Markup Language

XML was designed to describe data.

XML tags are not predefined unlike HTML

XML DTD and XML Schema define rules to describe data

XML example of semi structured data

The database We can model the database with a document node and its associated element node: <?xml version=“1.0” ?> <myDatabase> table1 table2 ... tablen </myDatabase> Order of tables is immaterial The table Each table of the database is represented by an element node with the records as its children: <customer> record1 record2



... recordm </customer> Again, order of the records is immaterial, since the relational data model defines no ordering on them. The record A record is also represented by an element node, with its fields as children: <custRec> field1 field2 ... fieldm </custRec> The name is arbitrary, since the relational data model doesn't define a name for a record type The field A field is represented as an element node with a data node as its only child: <custName type="t"> d </custName> If d is omitted, it means the value of the fields is the empty string. The value of t indicates the type of the value. 2.4.2 XML API with database



Characteristics of SOA, Comparing SOA with Client-Server and Distributed architectures – Benefits of SOA -- Principles of Service orientation – Service layers.

UNIT III

SERVICE ORIENTED ARCHITECTURE

What is architecture? The definition was abstract (theoretical) in nature, but specif icall y explained the

technology, boundaries, rules, limitations, and design characteristics that apply to all situations.

Application architecture Application architecture specif icall y explained the high-level, providing abstract

(conceptual) physical and logical representations of the technology. Others include more detail, such as common data models, communication flow diagrams, application-wide security requirements, and aspects of infrastructure.

Enterprise architecture Enterprise architectures often contain a long- term vision of how the organization plans

to evolve its technology and environments. Service-oriented architecture Service-oriented architecture spans both enterprise and application architecture domains. The term "SOA" does not necessarily imply a particular architectural scope. An SOA can refer to application architecture and the approach used to standardize

technical architecture across the enterprise. Because of the composable nature of SOA (meaning that individual application-level architectures can be comprised of different extensions and technologies). It is absolutely possible for an organization to have more than one SOA. The term "SOA" implies the contemporary (modern) SOA model (based on Web services and service-orientation principles).

3.1 Common characteristics of SOA SOA is at the core of the service-oriented computing platform. SOA increases quality of service. SOA is fundamentally autonomous. SOA is based on open standards. SOA supports vendor diversity. SOA fosters intrinsic interoperability. SOA promotes discovery. SOA promotes federation. SOA promotes architectural composabili ty. SOA fosters inherent reusabil ity. SOA emphasizes extensibility. SOA supports a service-oriented business modelling paradigm.



SOA implements layers of abstraction. SOA promotes loose coupling throughout the enterprise. SOA promotes organizational agilit y. SOA is a building block. SOA is an evolution. SOA is still maturing. SOA is an achievable ideal. Defining SOA SOA represents an open, live, extensible, federated (joined together), composable

architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, potentially reusable services, and implemented as Web services.

3.1.1 Separating concrete characteristics- Benefits of SOA SOA is at the core of the service-oriented computing platform. SOA is a building block. SOA is an evolution. SOA is still maturing. SOA is an achievable ideal. By trimming (decoration) these items, along with some extra wording, we end up with the

following set of concrete characteristics:

Based on open standards Architecturally composable Capable of improving QoS SOA supports: Vendor diversity Intrinsic interoperabili ty Discoverabili ty Federation Inherent reusabili ty Extensibility Service-oriented business modelling Layers of abstraction Enterprise-wide loose coupling Organizational agility (liveliness).

3.2 SOA VS CLIENT-SERVER ARCHITECTURE Any environment in which one piece of software requests or receives information from

another can be referred to as "client-server." The term "client-server architecture" generally refers to a client and the server played specif ic roles and had distinct implementation characteristics.

3.2.1 Single-tier client-server architecture



Systems natively supported both synchronous and asynchronous communication. This approach was used primarily to allow the server to continuously receive characters

from the terminal and only upon certain conditions would the server actually respond. 3.2.2 Two-tier client-server architecture

This new approach introduced the concept of delegating (hand over) logic and processing duties onto individual workstations, it is called as fat client. Further supported by the innovation of the graphical user-interface (GUI), two-tier client-server was considered as a huge step forward and went on to dominate (take over) the IT world. The common configuration of this architecture consisted of multiple fat clients, each with its own connection to a database on a central server. Client-side software performed the bulk of the processing, including all presentation-related and most data access logic.



3.2.3 The primary characteristics of the two-tier client-server architecture Application logic Client-server environments may use application logic into the client software. This result

used to controls the user experience, as well as the back-end resources. One exception is the distribution of business rules. A popular trend was to embed and maintain business rules by means of stored procedures and triggers on the database. The presentation layer VS service-oriented solutions: Any piece of software capable of exchanging SOAP messages according to required service can be classified as a service requestor. Within the server environment, it will don’t preclude (stop) the use of database triggers or stored procedures. However, service-oriented design principles, often dictating the partitioning of processing logic into autonomous units. This facili tates specific design qualities, such as interoperability, composability and reusabili ty. SOA supports the ultimate goal of promoting reuse and loose coupling across application boundaries.

Application processing Because most client-server application logic resides in the client component, the client

workstation is responsible for the bulk of the processing based on 80/20 ratio often is used as a rule of thumb. Communication is predictably synchronous, and these connections are often persistent. (Kept active until the user exits the application). The clients are assigned the majority of processing responsibil ities; so the client-side executables are fully stateful in nature.



Processing in SOA is highly distributed. In modelling a technical service-oriented architecture, have many choices as to how we can position and deploy services. Enterprise solutions consist of multiple servers with web services and supporting middleware. Therefore, no fixed processing ratio for SOAs. Communication between service and requestor can be synchronous or asynchronous. This promotes the stateless and autonomous nature of services.

Technology The client-server applications can use 4GL programming languages, such as Visual Basic

and PowerBuilder. Traditional 3GL languages, such as C++, were also still used. On the back-end, major database vendors, such as Oracle, Informix, IBM, Sybase, and Microsoft, provided robust (healthy) RDBMSs that could manage multiple connections, while providing flexible data storage and data management features.

The technology set used by SOA are web technologies (HTML, CSS, HTTP, etc.), XML data representation architecture along with a SOAP messaging framework, and Web services platform.

Security Client-server architecture has server level security it relates to specif ic business rules that

dictate the execution of application logic. Operating system-level security can be incorporated to achieve the user's operating

system login account information. In SOA, data is protected via a single point of authentication, establishing a single connection between client and server. In the distributed SOA, this is not possible. So we have to use WS-Security framework.

Administration Maintenance issues spanned both client and server ends. Client workstations were

subject to environment-specific problems. Further, there were increased server-side demands on databases.

Because service-oriented solutions can have a variety of requestors, they are not necessarily immune (unaffected) to client-side maintenance challenges.

While their distributed back-end does accommodate new administration demands. 3.3 SOA VS DISTRIBUTED INTERNET ARCHITECTURE The costs and limitations associated with the two-tier client server architecture, the

concept of building component-based Multi-tier client-server architectures can be made. The multi-tier client-server architecture can split client executables into number of components. Distributing application logic among multiple components (some residing on the client, others on the server) reduced deployment headaches.



3.3.1 Typical multi-tier client-server architecture

Building components capable of processing multiple, concurrent requests at a time. Replacing client-server database connections was the client-server remote procedure call (RPC) connection. RPC technologies such as CORBA and DCOM allowed for remote communication between components.

3.3.2 A typical distributed Internet architecture Distributed Internet architecture also introduced a new physical tier, the Web server. This resulted in HTTP replacing proprietary RPC protocols used to communicate

between the user's workstation and the server.



3.3.3 The primary characteristics of the two-tier client-server architecture Application logic The emphasis (importance) is therefore on:

How application logic should be partitioned Where the partitioned units of processing logic should reside How the units of processing logic should interact

Traditional distributed applications consist of a series of components that reside on one or more application servers. Components residing on the same server communicate via APIs. RPC protocols are used to accomplish the same communication across server boundaries. This is made possible through the use of local proxy stubs that represent components in remote locations.

In SOA, The creation of services that encapsulate some or all of these components.

These services are designed according to service-orientation principles. Next, how services exchange information? Web services communicate with SOAP messages. Even though SOAP supports RPC-style message structures, the majority of service-oriented Web service designs rely on document-style messages. Through the use of SOAP headers, message contents can be accompanied by a wide range of Meta information, processing instructions, and policy rules.



Application processing Distributed Internet architecture promotes the use of proprietary communication

protocols, such as DCOM and vendor implementations of CORBA for remote data exchange. They can support the creation of stateful and stateless components that primarily interact with synchronous data exchanges (asynchronous communication is supported by some platforms but not commonly used). SOA, on the other hand, relies on message-based communication. This involves the serialization, transmission, and de-serialization of SOAP messages. Processing steps can involve the conversion of relational data into an XML-compliant structure, the validation of the XML document prior and subsequent to transmission, and the parsing of the document and extraction of the data by the recipient. SOAP servers can effectively replace RPC-style communication channels within service-oriented application environments. Further supporting services are WS-* specifications, such as WS- Coordination and WS-BPEL, as well as custom solutions.

Technology Initial architectures consisted of components, server-side scripts, and raw Web

technologies, such as HTML and HTTP. Many current distributed applications use XML and Web services.

Security To ensure the safe transportation of information and the recognition of user credentials,

while preserving the original security context, traditional security architectures can be used. In SOA, how security is incorporated and applied. We have to use WS-Security framework, and the security models.

Administration

Maintaining component-based applications, keeping track of individual component instances, tracing local and remote communication problems, monitoring server resource demands and the standard database administration tasks. Enterprise-level SOAs typically require additional runtime administration. Exception handling with messaging frameworks can be more complex and less robust. Although WS-* extensions are being positioned to better deal with these situations. Other maintenance tasks, such as resource management (similar to component management), are also required. UDDI is one of the technologies used for standardizing interface repository, which can be manually or programmatically accessed to discover service descriptions.

3.4 Principles of Service orientation 3.4.1 COMMON PRINCIPLES OF SERVICE-ORIENTATION The principles of service-orientation provide a means of supporting and achieving a foundation paradigm based upon building of SOA characteristics. Services are reusable: Regardless of whether immediate reuse opportunities exist;

services are designed to support potential reuse.



Services share a formal contract: For services to interact, they need not share anything but a formal contract that describes each service and defines the terms of information exchange. Services are loosely coupled: Services must be designed to interact without the need for tight, cross-service dependencies. Services abstract underlying logic: The only part of a service that is visible to the outside world is what is exposed via the service contract. Underlying logic, beyond what is expressed in the descriptions that comprise the contract, is invisible and irrelevant to service requestors. Services are composable: Services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers. Services are autonomous: The logic governed by a service resides within an explicit boundary. The service has control within this boundary and is not dependent on other services for it to execute its governance. Services are stateless: Services should not be required to manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere. Services are discoverable: Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic.

Services are reusable Figure: A reusable service exposes reusable operations.

Service

s share a formal contract Service contracts provide a formal definition of:

• The service endpoint • Each service operation • Every input and output message supported by each operation • Rules and characteristics of the service and its operations

Figure: Service contracts formally define the service, operation, and message components of a service-oriented architecture.



Services are loosely coupled Figure: Services limit dependencies to the service contract, allowing underlying provider and requestor logic to remain loosely coupled.

Services abstract underlying logic Figure: Service operations abstract the underlying (fundamental) details of the functionality they expose.



. Services are composable Figure: The UpdateEverything operation encapsulating a service composition.

Services are autonomous Two types of autonomy:

• Service-level autonomy (underlying logic is under complete control of resources)

• Pure autonomy (underlying logic is under complete control of services)

Figure: Autonomous services have control over underlying resources.



Services are stateless Figure: Stateless and stateful stages a service passes through while processing a message.

Services are discoverable

• Discovery helps avoid the accidental creation of redundant services or services.



3.5 Service layers 3.5.1 SERVICE LAYER GUIDELINES

3.5.2 Application Layer Guidelines

Overview

When providing application functionality through services, it is important to separate the service functionality into a separate service layer. This chapter will help you to understand how the service layer fits into the application architecture, and learn the steps for designing the service layer. This includes guidance on the common issues you face when designing the service layer, and the key patterns and technology considerations for the service layer.

Within the service layer, you define and implement the service interface and the data contracts (or message types). One of the more important concepts to keep in mind is that a service should never expose details of the internal processes or the business entities used within the application. In particular, you should ensure that your business layer entities do not unduly influence your data contracts. The service layer should provide translator components that translate data formats between the business layer entities and the data contracts.

Figure 1 show how a service layer fits into the overall design of your application.

The services layer will usually include the following:

Service interfaces. Services expose a service interface to which all inbound messages are sent. You can think of a service interface as a façade that exposes the business logic implemented in the application (typically, logic in the business layer) to potential consumers.



Message types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. The services layer will also usually include data types and contracts that define the data types used in messages.

3.52 Business Layer Guidelines

Overview

This chapter describes the key guidelines for designing the business layer of an application. It will help you to understand how the business layer fits into the typical layered application architecture, the components it usually contains, and the key issues you face when designing the business layer. You will see guidelines for design, the recommended design steps, relevant design patterns, and technology options. Figure 1 show how the business layer fits into typical application architecture.

The business layer will usually include the following:

Application façade. This optional component typically provides a simplified interface to the business logic components, often by combining multiple business operations into a single operation that makes it easier to use the business logic. It reduces dependencies because external callers do not need to know details of the business components and the relationships between them.

Business Logic components. Business logic is defined as any application logic that is concerned with the retrieval, processing, transformation, and management of application



data; application of business rules and policies; and ensuring data consistency and validity. To maximize reuse opportunities, business logic components should not contain any behavior or application logic that is specific to a use case or user story. Business logic components can be further subdivided into the following two categories:

o Business Workflow components. After the UI components collect the required data from the user and pass it to the business layer, the application can use this data to perform a business process. Many business processes involve multiple steps that must be performed in the correct order, and may interact with each other through an orchestration. Business workflow components define and coordinate long running, multistep business processes, and can be implemented using business process management tools. They work with business process components that instantiate and perform operations on workflow components. For more information on business workflow components, see Chapter 14 "Designing Workflow Components."

o Business Entity components. Business entities, or—more generally—business objects, encapsulate the business logic and data necessary to represent real world elements, such as Customers or Orders, within your application. They store data values and expose them through properties; contain and manage business data used by the application; and provide stateful programmatic access to the business data and related functionality. Business entities also validate the data contained within the entity and encapsulate business logic to ensure consistency and to implement business rules and behavior.

3.5.3 Orchestration service layer

When orchestration is incorporated as part of a service-oriented architecture, it assumes the role of the process. Orchestration allows a direct link to process logic to service interaction within workflow logic. It combines business modelling with service-oriented modelling by means of business process and service layer position. A master composition controller orchestration language (WS-BPEL) realizes workflow management through a process service model. The orchestration layer introduces a parent level of abstraction that improves the need for other services. Within the orchestration 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. They are required to compose other services to execute business process logic Process services can also be referred to as orchestrated task services parent business process layer. The introduction of an orchestration layer typically brings with it the requirement to introduce new middleware into the IT infrastructure Orchestration is more valuable to us than a standard business process, as it allows us to directly link process logic to service interaction within our workflow logic. This combines business process modelling with service-oriented modelling and design. And, 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 (Figure). Within the orchestration service layer, process services compose other services that provide

http://msdn.microsoft.com/en-us/library/ee658122.aspx

http://msdn.microsoft.com/en-us/library/ee658122.aspx



specific sets of functions, independent of the business rules and scenario-specific logic required to execute a process instance. Therefore, all process services are also controller services by their very nature, as they are required to compose other services to execute business process logic. Process services also have the potential of becoming utility services to an extent, if a process, in its entirety, should be considered reusable. In this case, a process service that enables orchestration can itself be orchestrated (making it part of a larger orchestration). The introduction of an orchestration layer typically brings with it the requirement to introduce new middleware into the IT infrastructure. Orchestration servers are by no means a trivial addition and can impose significant expense and complexity.



Web services – Service descriptions – Messaging with SOAP – Service discovery – UDDI –Message exchange Patterns – Orchestration – Choreography – WS-Transactions.

UNIT IV

WEB SERVICES

4.1 SERVICE DESCRIPTIONS • A Service Description plays an important role in enabling access to a service. • Most service description languages are designed for machine consumption, allowing for :

1) The automatic creation of code skeletons, 2) Easier search, and 3) Classification of services 4.1.1 Data description • There are several aspects in data description like:

1) The definition of the data structure, 2) Type and values, 3) Semantic • For XML, XML Schema provide structural, type and values descriptions; • For Web Services, WSDL provides, the use of XML Schema, the data formats flowing in

and out; • SAWSDL provides a way to add semantic descriptions to XML Schema and WDSL

descriptions. 4.1.2 Web Services description • WSDL defines not only the format and values of data flowing in and out of the service,

but also define the endpoints, supported operations, message exchange patterns (MEP). • WS-Choreography describes the flow of messages between a set of services. It can also

be used to validate a subsequent series of exchanges between different parties. • WS Policy describes the policies in use when accessing a service.

INTRODUCTION TO WEB SERVICES

Web Services can convert your applications into Web-applications.

Web Services are published, found, and used through the Web.

What are Web Services?

Web services are application components Web services communicate using open protocols Web services are self-contained and self-describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services

How does it Work?

The basic Web services platform is XML + HTTP.

XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.

http://www.w3.org/standards/xml/core

http://www.w3.org/standards/techs/xmlschema

http://www.w3.org/standards/techs/wsdl

http://www.w3.org/standards/techs/sawsdl

http://www.w3.org/standards/techs/wsdl

http://www.w3.org/standards/techs/choreography

http://www.w3.org/standards/techs/wspolicy



The HTTP protocol is the most used Internet protocol.

Web services platform elements:

SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language)

Why Web Services?

Interoperability has Highest Priority

When all major platforms could access the Web using Web browsers, different platforms couldn't interact. For these platforms to work together, Web-applications were developed.

Web-applications are simply applications that run on the web. These are built around the Web browser standards and can be used by any browser on any platform.

Web Services take Web-applications to the Next Level

By using Web services, your application can publish its function or message to the rest of the world.

Web services use XML to code and to decode data, and SOAP to transport it (using open protocols).

With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.

Web Services have Two Types of Uses

Reusable application-components

There are things applications needs very often. So why make these over and over again?

Web services can offer application-components like: currency conversion, weather reports, or even language translation as services.

Connect existing software

Web services can help to solve the interoperability problem by giving different applications a way to link their data.

With Web services you can exchange data between different applications and different platforms.

Web Services Platform Elements

What is SOAP?

SOAP is an XML-based protocol to let applications exchange information over HTTP. Or simpler: SOAP is a protocol for accessing a Web Service.



SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is a format for sending messages SOAP is designed to communicate via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls SOAP is a W3C standard.

What is WSDL?

WSDL is an XML-based language for locating and describing Web services.

WSDL stands for Web Services Description Language WSDL is based on XML WSDL is used to describe Web services WSDL is used to locate Web services WSDL is a W3C standard

What is UDDI?

UDDI is a directory service where companies can register and search for Web services.

UDDI stands for Universal Description, Discovery and Integration UDDI is a directory for storing information about web services UDDI is a directory of web service interfaces described by WSDL UDDI communicates via SOAP UDDI is built into the Microsoft .NET platform.

Web Services Example

Any application can have a Web Service component.

Web Services can be created regardless of programming language.

A Web Service Example

In the following example we will use ASP.NET to create a simple Web Service that converts the temperature from Fahrenheit to Celsius, and vice versa:

<%@ WebService Language="VBScript" Class="TempConvert" %> Imports System Imports System.Web.Services Public Class TempConvert :Inherits WebService <WebMethod()> Public Function FahrenheitToCelsius (ByVal Fahrenheit As String) As String dim fahr fahr=trim(replace(Fahrenheit,",","."))



if fahr="" or IsNumeric(fahr)=false then return "Error" return ((((fahr) - 32) / 9) * 5) end function <WebMethod()> Public Function CelsiusToFahrenheit (ByVal Celsius As String) As String dim cel cel=trim(replace(Celsius,",",".")) if cel="" or IsNumeric(cel)=false then return "Error" return ((((cel) * 9) / 5) + 32) end function end class Output

TempConvert

The following operations are supported. For a formal definition, please review the Service Description.

CelsiusToFahrenheit FahrenheitToCelsius

CelsiusToFahrenheit

Test

To test the operation using the HTTP POST protocol, click the 'Invoke' button.

Parameter Value

Celsius:

4.2 WSDL

4.2.1 What is WSDL?

WSDL stands for Web Services Description Language

WSDL is written in XML

WSDL is an XML document

WSDL is used to describe Web services

WSDL is also used to locate Web services

WSDL is a W3C recommendation

WSDL Describes Web Services. WSDL stands for Web Services Description Language. WSDL

is a document written in XML. The document describes a Web service. It specifies the location

http://www.w3schools.com/webservices/tempconvert.asmx?WSDL

http://www.w3schools.com/webservices/tempconvert.asmx?WSDL

http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit

http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius



of the service and the operations (or methods) the service exposes. A WSDL document is just a

simple XML document. It contains set of definitions to describe a web service.

4.2.2 The WSDL Document Structure

A WSDL document describes a web service using these major elements:

Element Description

<types> A container for data type definitions used by the web service

<message> A typed definition of the data being communicated

<portType> A set of operations supported by one or more endpoints

<binding> A protocol and data format specification for a particular port type

Operation Types

The request-response type is the most common operation type, but WSDL defines four types:

Type Definition

One-way The operation can receive a message but will not return a response

Request-response The operation can receive a request and will return a response

Solicit-response The operation can send a request and will wait for a response

Notification The operation can send a message but will not wait for a response

WSDL Elements

WSDL breaks down Web services into three specific, identifiable elements that can be combined

or reused once defined.

Three major elements of WSDL that can be defined separately and they are:

Types

Operations

Binding

A WSDL document has various elements, but they are contained within these three main

elements, which can be developed as separate documents and then they can be combined or

reused to form complete WSDL files.



Following are the elements of WSDL document. Within these elements are further sub elements,

or parts:

Definition: element must be the root element of all WSDL documents. It defines the

name of the web service, declares multiple namespaces used throughout the

remainder of the document, and contains all the service elements described here.

Data types: the data types - in the form of XML schemas or possibly some other

mechanism - to be used in the messages

Message: an abstract definition of the data, in the form of a message presented either

as an entire document or as arguments to be mapped to a method invocation.

Operation: the abstract definition of the operation for a message, such as naming a

method, message queue, or business process, that will accept and process the message

Port type: an abstract set of operations mapped to one or more end points, defining

the collection of operations for a binding; the collection of operations, because it is

abstract, can be mapped to multiple transports through various bindings.

Binding: the concrete protocol and data formats for the operations and messages

defined for a particular port type.

Port: a combination of a binding and a network address, providing the target address

of the service communication.

Service: a collection of related end points encompassing the service definitions in the

file; the services map the binding to the port and include any extensibility definitions.

In addition to these major elements, the WSDL specification also defines the following utility

elements:

Documentation: element is used to provide human-readable documentation and can

be included inside any other WSDL element.

Import: element is used to import other WSDL documents or XML Schemas.

WSDL Definition Element

The <definition> element must be the root element of all WSDL documents. It defines the name

of the web service.

Here is the example piece of code from last session which uses definition element.

<definitions name="HelloService"



targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

................................................

</definitions>

From the above example we can conclude the followings points:

The definitions element is a container of all the other elements.

The definitions element specifies that this document is the HelloService.

The definitions element specifies a targetNamespace attribute. The targetNamespace is a

convention of XML Schema that enables the WSDL document to refer to itself. In this

example we have specified a targetNamespace of

http://www.examples.com/wsdl/HelloService.wsdl.

The definition element specifies a default namespace:

xmlns=http://schemas.xmlsoap.org/wsdl/. All elements without a namespace prefix, such

as message or portType, are therefore assumed to be part of the default WSDL

namespace.

It also specifies numerous namespaces that will be used throughout the remainder of the

document.

WSDL Types Element

A Web service needs to define its inputs and outputs and how they are mapped into and out of

services. WSDL <types> elements take care of defining the data types that are used by the web

service. Types are XML documents, or document parts.

Here is a piece of code taken from W3C specification. This code depicts how a types element

can be used within a WSDL.

The type’s element describes all the data types used between the client and server.

WSDL is not tied exclusively to a specific typing system

WSDL uses the W3C XML Schema specification as its default choice to define data types.



If the service uses only XML Schema built-in simple types, such as strings and integers,

then types element is not required.

WSDL allows the types to be defined in separate elements so that the types are reusable

with multiple Web services.

<types>

<schema targetNamespace="http://example.com/stockquote.xsd"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="TradePriceRequest">

<complexType>

<all>

<element name="tickerSymbol" type="string"/>

</all>

</complexType>

</element>

<element name="TradePrice">

<complexType>

<all>

<element name="price" type="float"/>

</all>

</complexType>

</element>

</schema>

</types>

Data types address the problem of how to identify the data types and format you intend to use

with your Web services. Type information is shared between sender and receiver. The recipients

of messages therefore need access to the information you used to encode your data and must

understand how to decode the data.

WSDL Message Element

The <message> element describes the data being exchanged between the Web service

providers and consumers.

Each Web Service has two messages: input and output.

The input describes the parameters for the Web Service and the output describes the



return data from the Web Service.

Each message contains zero or more <part> parameters, one for each parameter of the

Web Service's function.

Each <part> parameter associates with a concrete type defined in the <types>

container element.

Let’s take a piece of code from the Example Session:

<message name="SayHelloRequest">

<part name="firstName" type="xsd:string"/>

</message>

<message name="SayHelloResponse">

<part name="greeting" type="xsd:string"/>

</message>

Here, two message elements are defined. The first represents a request message

SayHelloRequest, and the second represents a response message SayHelloResponse.

Each of these messages contains a single part element. For the request, the part specifies the

function parameters; in this case, we specify a single firstName parameter. For the response, the

part specifies the function return values; in this case, we specify a single greeting return value.

WSDL portType Element

The <portType> element combines multiple message elements to form a complete oneway or

round-trip operation.

For example, a <portType> can combine one request and one response message into a single

request/response operation. This is most commonly used in SOAP services. A portType can

define multiple operations.

Let’s take a piece of code from the Example Session:

<portType name="Hello_PortType">

<operation name="sayHello">

<input message="tns:SayHelloRequest"/>

<output message="tns:SayHelloResponse"/>



</operation>

</portType>

The portType element defines a single operation, called sayHello.

The operation itself consists of a single input message SayHelloRequest

The operation itself consists of a single output message SayHelloResponse

Patterns of Operation

WSDL supports four basic patterns of operation:

One-way

The service receives a message. The operation therefore has a single input element. The grammar

for a one-way operation is:

<wsdl:definitions .... > <wsdl:portType .... > *

<wsdl:operation name="nmtoken">

<wsdl:input name="nmtoken"? message="qname"/>

</wsdl:operation>

</wsdl:portType >

</wsdl:definitions>

Request-response:

The service receives a message and sends a response. The operation therefore has one input

element, followed by one output element. To encapsulate errors, an optional fault element can

also be specified. The grammar for a request-response operation is:

<wsdl:definitions .... >

<wsdl:portType .... > *

<wsdl:operation name="nmtoken" parameterOrder="nmtokens">


<wsdl:output name="nmtoken"? message="qname"/>

<wsdl:fault name="nmtoken" message="qname"/>*

</wsdl:operation>

</wsdl:portType >

</wsdl:definitions>



Solicit-response

The service sends a message and receives a response. The operation therefore has one output

element, followed by one input element. To encapsulate errors, an optional fault element can also

be specified. The grammar for a solicit-response operation is:



<wsdl:operation name="nmtoken" parameterOrder="nmtokens">



<wsdl:fault name="nmtoken" message="qname"/>*

</wsdl:operation>

</wsdl:portType >

</wsdl:definitions>

Notification

The service sends a message. The operation therefore has a single output element. Following is

the grammer for a notification operation:



<wsdl:operation name="nmtoken">


</wsdl:operation>

</wsdl:portType >

</wsdl:definitions>

WSDL Binding Element

The <binding> element provides specific details on how a portType operation will

actually be transmitted over the wire.

The bindings can be made available via multiple transports, including HTTP GET, HTTP

POST, or SOAP.

The bindings provide concrete information on what protocol is being used to transfer

portType operations.

The bindings provide information where the service is located.



For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages

on top of HTTP protocol.

You can specify multiple bindings for a single portType.

The binding element has two attributes - the name attribute and the type attribute.

<binding name="Hello_Binding" type="tns:Hello_PortType">

The name attribute defines the name of the binding, and the type attribute points to the port for

the binding, in this case the "tns:Hello_PortType" port.

SOAP Binding

WSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify SOAPspecific

details, including SOAP headers, SOAP encoding styles, and the SOAPAction HTTP header.

The SOAP extension elements include:

soap:binding

This element indicates that the binding will be made available via SOAP. The style attribute

indicates the overall style of the SOAP message format. A style value of rpc specifies an RPC

format.

The transport attribute indicates the transport of the SOAP messages. The value

http://schemas.xmlsoap.org/soap/http indicates the SOAP HTTP transport, whereas

http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport.

soap:operation

This element indicates the binding of a specific operation to a specific SOAP implementation.

The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the

service.

soap:body

This element enables you to specify the details of the input and output messages. In the case of

HelloWorld, the body element specifies the SOAP encoding style and the namespace URN

associated with the specified service.

Here is the piece of code from Example section:



<binding name="Hello_Binding" type="tns:Hello_PortType">

<soap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="sayHello">

<soap:operation soapAction="sayHello"/>

<input>

<soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:examples:helloservice"

use="encoded"/>

</input>

<output>

<soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:examples:helloservice"

use="encoded"/>

</output>

</operation>

</binding>

WSDL Ports Element

A <port> element defines an individual endpoint by specifying a single address for a binding.

Here is the grammar to specify a port:


<wsdl:service .... > *

<wsdl:port name="nmtoken" binding="qname"> *

<-- extensibility element (1) -->

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

The port element has two attributes - the name attribute and the binding attribute.

The name attribute provides a unique name among all ports defined within in the



enclosing WSDL document.

The binding attribute refers to the binding using the linking rules defined by WSDL.

Binding extensibility elements (1) are used to specify the address information for the

port.

A port MUST NOT specify more than one address.

A port MUST NOT specify any binding information other than address information.

Here is the piece of code from Example session:

<service name="Hello_Service">

<documentation>WSDL File for HelloService</documentation>

<port binding="tns:Hello_Binding" name="Hello_Port">

<soap:address

location="http://www.examples.com/SayHello/">

</port>

</service>

WSDL Service Element

The <service> element defines the ports supported by the Web service. For each of

the supported protocols, there is one port element. The service element is a collection

of ports.

Web service clients can learn from the service element where to access the service,

through which port to access the Web service, and how the communication messages

are defined.

The service element includes a documentation element to provide human-readable

documentation.

Here is a piece of code from Example Session:

<service name="Hello_Service">

<documentation>WSDL File for HelloService</documentation>

<port binding="tns:Hello_Binding" name="Hello_Port">

<soap:address

location="http://www.examples.com/SayHello/">

</port> </service>



The binding attributes of por element associate the address of the service with a binding element

defined in the Web service. In this example this is Hello_Binding

<binding name="Hello_Binding" type="tns:Hello_PortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding>

WSDL Example

This is a simplified fraction of a WSDL document:

<message name="getTermRequest">

<part name="term" type="xs:string"/>

</message>

<message name="getTermResponse">

<part name="value" type="xs:string"/>

</message>

<portType name="glossaryTerms">

<operation name="getTerm">

<input message="getTermRequest"/>

<output message="getTermResponse"/>

</operation>

</portType>

In this example the <portType> element defines "glossaryTerms" as the name of a port,

and "getTerm" as the name of an operation.



The "getTerm" operation has an input message called "getTermRequest" and an output

message called "getTermResponse".

The <message> elements define the parts of each message and the associated data types.

Compared to traditional programming, glossaryTerms is a function library; "getTerm" is

a function with "getTermRequest" as the input parameter, and getTermResponse as the

return parameter.

4.3 MESSAGING WITH SOAP

SOAP Introduction

4.3.1 What is SOAP?

SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between applications SOAP is a format for sending messages SOAP communicates via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls SOAP is a W3C recommendation

Why SOAP?

It is important for application development to allow Internet communication between programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.

A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.

SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

SOAP Syntax

SOAP Building Blocks

A SOAP message is an ordinary XML document containing the following elements:

An Envelope element that identifies the XML document as a SOAP message A Header element that contains header information A Body element that contains call and response information A Fault element containing errors and status information



Syntax Rules

Here are some important syntax rules:

A SOAP message MUST be encoded using XML A SOAP message MUST use the SOAP Envelope namespace A SOAP message MUST use the SOAP Encoding namespace A SOAP message must NOT contain a DTD reference A SOAP message must NOT contain XML Processing Instructions

4.3.2 Skeleton SOAP Message

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> </soap:Envelope>

The SOAP Envelope Element

The required SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message.

Example

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... Message information goes here ... </soap:Envelope>

The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value of: "http://www.w3.org/2001/12/soap-envelope".

The namespace defines the Envelope as a SOAP Envelope.

If a different namespace is used, the application generates an error and discards the message.



The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element's contents and all child elements.

A SOAP message has no default encoding.

Syntax

soap:encodingStyle="URI"

Example

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... Message information goes here ... </soap:Envelope>

The SOAP Header Element

The optional SOAP Header element contains application-specific information (like authentication, payment, etc) about the SOAP message.

If the Header element is present, it must be the first child element of the Envelope element.

Note: All immediate child elements of the Header element must be namespace-qualified.

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234 </m:Trans> </soap:Header> ... ... </soap:Envelope>

The example above contains a header with a "Trans" element, a "mustUnderstand" attribute with a value of 1, and a value of 234.

SOAP defines three attributes in the default namespace ("http://www.w3.org/2001/12/soap-envelope"). These attributes are: mustUnderstand, actor, and encodingStyle.

The attributes defined in the SOAP Header defines how a recipient should process the SOAP message.



The mustUnderstand Attribute

The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process.

If you add mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it will fail when processing the Header.

Syntax

soap:mustUnderstand="0|1"

Example

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234 </m:Trans> </soap:Header> ... ... </soap:Envelope>

The actor Attribute

A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. However, not all parts of a SOAP message may be intended for the ultimate endpoint, instead, it may be intended for one or more of the endpoints on the message path.

The SOAP actor attribute is used to address the Header element to a specific endpoint.

Syntax

soap:actor="URI"

Example

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:actor="http://www.w3schools.com/appml/">234 </m:Trans> </soap:Header> ... ... </soap:Envelope>



The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and it will apply to that element's contents and all child elements.

A SOAP message has no default encoding.

Syntax

soap:encodingStyle="URI"

The SOAP Body element contains the actual SOAP message.

The SOAP Body Element

The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.

Immediate child elements of the SOAP Body element may be namespace-qualified.

Example

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope>

The example above requests the price of apples. Note that the m:GetPrice and the Item elements above are application-specific elements. They are not a part of the SOAP namespace.

A SOAP response could look something like this:

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>



The SOAP Fault Element

The SOAP Fault element holds errors and status information for a SOAP message.

The optional SOAP Fault element is used to indicate error messages.

If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.

The SOAP Fault element has the following sub elements:

Sub Element Description

<faultcode> A code for identifying the fault

<faultstring> A human readable explanation of the fault

<faultactor> Information about who caused the fault to happen

<detail> Holds application specific error information related to the Body element

SOAP Fault Codes

The fault code values defined below must be used in the fault code element when describing faults:

Error Description

VersionMismatch Found an invalid namespace for the SOAP Envelope element

MustUnderstand An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood

Client The message was incorrectly formed or contained incorrect information

Server There was a problem with the server so the message could not proceed

Layers of the Web Services Protocol Stack- UDDI

Web services consist of sets of internet protocols and standards for exchanging data between

applications. The Web Services Protocol Stack describes the layering of the set of internet

protocols or rules used to design, discover, and implement web services.



The major components or layers of a Web Service Protocol Stack include:

Transport Layer—transports messages between applications

XML Messaging Layer—encodes messages in XML that can be understood by both

client and server

WSDL Layer—describes the service provided

UDDI Layer—centralizes services with a common registry

Transport Layer

The Transport layer is the first component in the stack and is responsible for moving XML

messages between applications. The Transport protocol most commonly used is the standard

HTTP protocol. Other commonly used Web protocols are SMTP and FTP.

XML Messaging

The messaging layer in the protocol stack is based on an XML model. XML is widely used in

Web Services applications and is the foundation for all web services. XML is just one of the

standards enabling web services to map between technology domains.

The XML Messaging specification is a broadly-defined umbrella under which a number of more

specific protocols are defined. SOAP is one of the more popular standards, and is one of the most

significant standards in communicating web services over the network. XML provides a means

for communicating over the Web using an XML document that both requests and responds to

information between two disparate systems. SOAP allows the sender and the receiver of XML

documents to support a common data transfer protocol for effective networked communication.



WSDL Layer

This layer represents a way of specifying a public interface for a web service. It contains

information on available functions, on data types for XML messaging, binding information about

the transport protocol, and the location of the specific web service.

Any client application that wants to know about a service, what data it expects to receive,

whether or not it delivers any results, and the supported transport, uses WSDL to find that

information. When you create a Web Service, it must be described and advertised to its potential

customers before it can be used. WSDL provides a common format for describing and publishing

that web service information. Typically, WSDL is used with SOAP, and the WSDL specification

includes a SOAP binding.

Use CodeGear's Add Web Reference feature to obtain a WSDL document for your web service.

The WSDL document, or proxy file, is copied to the client and is used to call the server. This

proxy file is named References.*, where the file name extension reflects the language type.

4.4 Service discovery 4.4.1 UDDI Layer

This layer represents a way to publish and find web services over the Web. You can think of this

layer as the White and Yellow Pages of your phonebook. The White page of web services

provides general information about a specific company, for instance, their business name,

description, and address. The Yellow Pages includes the classification of data for the services

offered, for instance, industry type and products.

The protocol you use to publish your web services is known as UDDI. The UDDI Business

Registry allows anyone to search existing UDDI data and enables you to register your company

and its services. With RAD Studio, your data automatically gets published to the registry, or a

distributed directory for business and web services.

Web Services Protocols

For IBM web services, SOAP is the standard protocol used to send XML-based messages over

HTTPS.



SOAP

Simple Object Access Protocol (SOAP) is a standard for exchanging structured information, and

in IBM web services, it uses XML format over HTTPS. SOAP requires a WSDL (Web Services

Description Language) file to describe the payload for XML messages.

SOAP defines three parts to every message:

Envelope

Encoding rules

Communication styles

The SOAP envelope defines a framework for describing what is in a message and how to process

it. A SOAP message is an envelope containing zero or more headers and exactly one body. The

envelope is the top element of the XML document, providing a container for control information,

the address of a message, and the message itself. Headers transport any control information such

as quality-of-service attributes. The body contains the message identification and its parameters.

Both the headers and the body are child elements of the envelope.

SOAP envelopes of version 1.1 or 1.2 are supported.

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is a widely-used communications protocol for

secure communication. Technically, it is not a protocol in itself; rather, it is the result of layering

the Hypertext Transfer Protocol (HTTP) on top of the Secure Sockets Layer (SSL)/Transport

Layer Security (TLS) protocol, thus adding the security capabilities of SSL/TLS to standard

HTTP communications. For IBM web services, HTTPS is a non-standard protocol, with SOAP

being the standard protocol.

HTTPS is typically used for XML-based messages, but can be used for binary or flat files

as well.

4.5 MESSAGE EXCHANGE PATTERNS

4.5.1 The Need for Messaging

Web Services must exchange critical business information to succeed. Main features for business

critical systems include the following

Security

Performance



Reliability

Integration

Web services are revolutionizing the Internet by enabling applications to speak a common

language: XML. While Web services technology enables the execution of remote functions, it

does not provide a robust infrastructure for handling information.

As the solution of this problem this article describes the concepts of web services with

messaging.

Web Services

Web services are a new breed of Web application. They are self-contained, self-describing,

modular applications that can be published, located, and invoked across the Web. Web services

perform functions, which can be anything from simple requests to complicated business

processes.

How it differs from web application

Where the current web enables users to connect to applications, the web services architecture

enables applications to connect to other applications. A web service is therefore a key technology

in enabling business models to move from B2C (Business to Consumer) to B2B (Business to

Business).

Web Services provide companies with a standards-based technology to simply integrate

applications, share information with partners, and provide access to enterprise systems through a

variety of devices.

Where is the problem?

An enterprise-class application that communicates with Web services must ensure that the data

can be handled appropriately.

When employing Web services, one must ask questions like: Can our application scale to

increased messaging demands? If our application crashes, is the Web service’s data lost? How do

we connect our Web-services-facing applications to back-end systems? These problems are

created but unfortunately not solved through the Web services architecture. Web services must

be combined with additional technology called Messaging for robust enterprise messaging.



4.5.2 Messaging Concept

Messaging provides high-speed, asynchronous, program-to-program communication with

guaranteed delivery.

A simple way to understand what messaging does is to consider voice mail (as well as answering

machines) for phone calls. Before voice mail, when someone called, if the receiver could not

answer, the caller hung up and had to call back later to see if the receiver would answer at that

time. With voice mail, when the receiver does not answer, the caller can leave him a message;

later the receiver (at his convenience) can listen to the messages queued in his mailbox. Voice

mail enables the caller to leave a message now so that the receiver can listen to it later, which is

often a lot easier than trying to get the caller and the receiver on the phone at the same time.

Voice mail bundles (at least part of) a phone call into a message and queues it for later; this is

essentially how messaging works.

In enterprise computing, messaging makes communication between processes reliable, even

when the processes and the connection between them are not so reliable.

There are two main defacto messaging standards for enterprise computing:

1. The Java 2 Platform, Enterprise Edition (J2EE) includes the Java Message Service API (JMS).

2. The Microsoft .NET Framework SDK (.NET) includes the System.Messaging namespace for

accessing MicroSoft Message Queue (MSMQ).

JMS

At its simplest level, JMS is java based messaging that sends messages between servers and

clients. The format of these messages is quite flexible and can include ordinary text messages

(including raw text, SOAP, and XML), entire Java objects, and “empty” messages that are

suitable for basic communication (like acknowledgments).

What’s different about JMS compared with, say, low-level TCP/IP packets and Java Remote

Method Invocation (RMI) is that while the other methods normally require real-time connectivity

and messages that are sent synchronously, JMS systems are more flexible. In asynchronous

mode, which is the default mode for JMS, clients don’t have to be connected all the time.



MSMQ

MSMQ is Microsoft’s implementation of Messaging. It supports both Point-to-Point and

Publisher-Subscriber models for messaging. Messages are typically kept in queues that are

managed by Queue managers and applications access MSMQ via a simple client API.

Messages can be prioritized and delivered depending on their position in the queue, the first on

queue having the highest priority. Queues can be implemented both in memory as well as on

secondary storage such as disk. While express messages are stored in memory, recoverable

messages are stored on disk.

There are two types of queues in MSMQ

Public queues: These are queues published in the MQIS (Message Queue Information Store) and

replicated throughout the Enterprise. Any computer on the Enterprise can hence locate them.

Private queues: These are queues that are not published in the MQIS and can only be accessed by

systems that have access to the full path name or format name of the queue.

4.5.3 Combining Messaging with Web Services

A first-generation Web-services-enabled application contains or directly interfaces with a client

that communicates with Web services as following image shows.

This architecture enables the application to find and communicate with remote systems, but does

not implement data reliability, scalability. The addition of Messaging creates a second generation

for architecting Web services systems, as shown in following Figure.



The inclusion of messaging servers decouples the application from the tasks of handling

messages and web service clients. Applications communicate through an adapter to the

messaging server.

In this new architecture, hybrid Messaging and Web services clients handle the bulk of the

messaging duties. Information is passed through the Messaging server, which natively handles

issues like fail over, load balancing, and guaranteed message delivery. By decoupling the Web

services client from the application, several applications can effortlessly reuse a single Web

services client. Decoupling makes it a simpler process to upgrade the Web service as inevitable

software changes occur. Additionally, an application that becomes busy will have its Web

services data automatically queued in the Messaging server until it is able to process the

messages.

XML Messaging over Different Communication Protocols

In the early days of integrating applications together across the Internet, it was all about trying to

blend together the most ubiquitous communication protocol, HTTP, with the most popular data

format, XML. After all, every platform had an HTTP stack and an XML parser.

HTTP is a protocol that was designed to do a particular job, however, and has a very precise

mode of operation—the client establishes a connection, and then initiates the conversation by

sending a request to the server and synchronously getting back a response, with either party (or

any HTTP intermediary between them) able to close the connection. Such characteristics make

HTTP inappropriate for certain message exchange scenarios, such as peer-to-peer

communication, where either party may establish the connection or initiate the conversation, or

perhaps a single request/multiple response communication. It is lucky, then, that there are other

successful Internet-friendly protocols, such as TCP, FTP, and SMTP, which have slightly

different characteristics and that lend themselves to other types of application not well catered

for by HTTP.



To carry XML messages unchanged over different communication protocols, those XML

messages need to be self-contained and isolated from the underlying transport. This means that

messages must hold all the information required to get the message where it is going and to

process it. For instance, holding addressing information outside the XML message in the

communication protocol layer alone makes it more difficult to use different transports to send the

message. If addressing information is held inside the XML message, then it can be mapped to the

needs of any transport used to send it. Similarly, imagine you wanted to exchange a series of

XML messages that built up some conversational state. Holding the session identification

information outside the XML messages in the communication protocol layer means it is difficult

to change the transport used to send the messages. If such information is held inside the XML

messages, it can be carried over any transport.

One of the fundamental tenets of SOAP is transport-neutral messaging. The SOAP message

format, shown below, allows the protocol information needed to build higher-level message

exchanges to be carried in the XML message, and independently of the underlying

communication protocol.

<soap:Envelope

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header>



</soap:Header>

<soap:Body>



</soap:Body>

</soap:Envelope>

The Body element has an open content model and is used to hold arbitrary data. The Header

element also has an open content model, and is used to carry the information that is needed by

whatever communication protocol is used to carry the message. The Header element is also used

to carry the information that is needed to build higher-level application protocols, such as a

secure conversation protocol. Obviously the sender and receiver of the message must agree on

the syntax and semantics of these headers. In fact, over time, many headers have been

standardized by the community to promote interoperability. This can be seen with specifications

such as WS-Addressing (a transport-neutral way to address Web services and messages) and

http://www.w3.org/tr/soap/



WS-Security (a transport-neutral way to provide message integrity, message confidentiality, and

single message authentication).

Carrying XML messages over different communications protocols enables the many different

message exchange patterns (MEPs) made possible by those protocols—for instance, the ability to

send one request and get nothing back. For this reason, SOAP does not mandate any particular

message exchange patterns, preferring to talk instead about transmitting messages from a SOAP

sender to a SOAP receiver (via zero or more SOAP intermediaries), so that a variety of different

message exchange patterns can be built.

Sending Messages

A SOAP message is represented by the SoapEnvelope class from the Microsoft.Web.Services2

namespace. It is a specialization of the familiar XmlDocument class, and has additional

properties and methods geared to the fact that the document object model (DOM) represents a

SOAP message. Let us consider the SOAP message below, which represents a subscription.

<soap:Envelope

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<subscribe xmlns="urn:stockservice">

<stock>Acme</stock>

</subscribe>

</soap:Body>

</soap:Envelope>

Receiving Messages

To receive a message, you derive from the SoapReceiver class from the

Microsoft.Web.Services.Messaging2 namespace and override its Receive() method. This method

gets handed a SoapEnvelope, and your code must dig into it to process the message. The code

below shows how to do this.

class PublisherReceiver : SoapReceiver {

protected override void Receive(SoapEnvelope env) {

switch(env.Context.Addressing.Action.Value) {

case Literals.SubscribeAction:

AcceptSubscription(env);



break;

default:

Console.WriteLine(

"Unknown message, action is {0}, body is {1}",

env.Context.Addressing.Action.Value, env.Body.InnerXml);

break;

}

}

private void AcceptSubscription(SoapEnvelope env) {

XmlNamespaceManager nsm = new XmlNamespaceManager(env.NameTable);

nsm.AddNamespace("x", Literals.StockServiceNs);

XmlNode n = env.Body.SelectSingleNode(

"x:subscribe/x:stock/text()", nsm);

if (n!=null)

Console.WriteLine("Got subscription for stock {0}", n.Value);

}

}

Notice how the WS-Addressing Action SOAP header value is available via the received

message's Context.Addressing.Action property, and how it is used to distinguish the message's

intent and to dispatch the message to the correct code for processing. Of course, the element

name of the first child of the message's SOAP Body could have similarly been used to identify

the message's intent, assuming it was unique.

4.8 WS-Transaction

Introduction

The Web Service architecture provides a set of modular protocol building blocks that can be composed in varying ways to create protocols specific to particular applications. The protocols present in WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity are mechanisms to create activities, join into them, and reach common agreement on the outcome of joint operations. These specifications provide a basis on which to build interoperable, distributed applications that desire to coordinate joint work.

As Web services may belong to different enterprises, there is need to support arm's-length relationships. These specifications achieve this goal by assuming:

Asynchronous operation among participants Explicit registration in activities with pre-defined behaviours. All communication between participants is based on a collection of mandatory messages

and mandatory message exchange patterns for coordination operations



Composition with other WS-* specifications so that additional functionality, such as reliable messaging and end-to-end secure message exchanges, can be achieved

To complement the agreement coordination behaviours prescribed by the protocols in WS-AtomicTransaction and WS-BusinessActivity, they compose with other WS-* specifications such as WS-Addressing, WS-Policy, WS-Security, WS-SecureConversation, and WS-ReliableMessaging.

Figure illustrates the relationship between different kinds of activities and their use of the coordination specifications. For example, Activity 2 illustrates the use of atomic transactions. Activity 3, in this case, makes use of both atomic transactions and business activity. The figure also illustrates that WS-AtomicTransaction and WS-BusinessActivity build on WS-Coordination.

Terminology

Protocol: The rules of interaction between two Web services, including message formats and sequencing rules. For example, a purchase protocol would define message formats for purchase order, quote, etc., the meaning of these messages, and the constraint that a quote message should follow a purchase order message. Note that a communication protocol such as TCP/IP also satisfies this definition. Thus, protocols may be defined for different levels of a communication stack and they may nest. For example, an application protocol may use a communication protocol.

Protocol instance: A particular usage of a protocol. For example, a purchase protocol instance would involve a single purchase.

Activity: A set of actions spanning multiple Web services that work jointly toward a common goal. For example, making a trip reservation across hotel, airline, cruise, and auto rental reservation services.

Activity coordination: Managing the creation of an activity, the propagation of an activity, and the agreement on the intermediate steps and outcome of an activity. This enables all the involved services to agree even when exceptions happen.

Coordination protocol: A protocol that enables coordination. For example, the WS-AtomicTransaction two-phase commit protocol or the WS-BusinessActivity BusinessAgreementWithCoordinatorCompletion protocol.

Coordination type: A family of coordination protocols that address a particular kind of coordination. For example, WS-AtomicTransaction defines a coordination type that is most useful for handling system-generated exceptions, such as an incomplete write operation or a process terminating abnormally. This type includes three coordination protocols.

http://msdn.microsoft.com/en-us/library/ms951273.aspx



Coordination context: An XML element used in a message as an invitation to participate in an activity. The information includes that needed to register to participate in the activity.

EndpointReference: Defined in the WS-Addressing specification. It contains the information needed to address a Web service end point, including the service address and optionally additional opaque information that can be used by the target service to identify a particular resource within it.

Activation service: Defined as part of the WS-Coordination specification, it is a Web service where coordination contexts can be created.

Registration service: Defined as part of the WS-Coordination specification, it is a Web service where other Web services can register to participate in an activity. A registration begins a coordination protocol instance by exchanging coordination and participant service EndpointReferences.

Coordinator service: Defined as part of the WS-Coordination specification, it is a Web service that is an endpoint for a coordination protocol instance and plays the coordinator role. The semantics of the coordinator and participant roles are defined as part of the specific coordination protocol.

Participant service: Defined as part of the WS-Coordination specification, is a Web service that is an endpoint for a coordination protocol instance and plays the participant role. The semantics of the coordinator and participant roles are defined as part of the specific coordination protocol.

Atomic transaction: An activity that is coordinated using WS-AtomicTransaction coordination protocols. These protocols provide an all-or-nothing coordination mechanism that is useful in situations including short-lived activities within a domain of trust, and for handling system-generated exceptions that arise from hardware and software failures.

Business activity: An activity that is coordinated using WS-BusinessActivity coordination protocols. These protocols provide a coordinated outcome useful in situations that include activities that transcend one domain of trust, those that require tentative operations whose intermediate results may be visible to third parties, and for handling application-generated exceptions.

4.8.1 WS-Coordination

The procedure to establish coordination between the set of participants of an activity has two stages. In the first stage, the activity is configured; the second stage is that in which the participants exchange messages over the wires according to the protocols that have been established. In particular, the WS-Coordination specification defines the following:

A format for a CoordinationContext, which contains the information needed to request to participate in an activity.

A protocol to create a CoordinationContext for an activity. How to pass a CoordinationContext in application messages as a way for one service to

invite another service to participate in the activity. A protocol to register to participate in the activity.

These basic mechanisms can be used by any collection of Web services that desire to establish a coordinated activity.

A coordination type is identified by a URI (called the coordination type) and defines one or more coordination protocols. Each coordination protocol is identified by a URI (called the coordination protocol identifier) and defines the formats and behaviour of the protocol. A coordination protocol is defined between two services.



Coordination Services

In Figure below, we illustrate the types of service involved in coordination. The illustrated logical services can be hosted in fewer actual services in different ways. For atomic transactions, the Activation, Registration and Coordinator/Participant services on either side are typically hosted in a single transaction manager. For business activities, the application service is typically also included.

CoordinationContext

A CoordinationContext includes the following information:

An activity identifier The type of the coordination (e.g., atomic transaction) The EndpointReference to the Registration service An optional expiration time for the activity Extensibility elements to allow other information to be communicated

Creating an Activity

To create a CoordinationContext, the WS-Coordination specification defines an Activation protocol with the following two messages:

The CreateCoordinationContext message targets an ActivationService, and provides an optional CurrentContext parameter that is a CoordinationContext for an existing activity. This parameter causes the activity to be imported instead of created. Import is described later.

CreateCoordinationContextResponse message returns the newly created CoordinationContext.

Although the above messages have a request-response pattern, each message is a separate operation to support asynchronous usage. An activation protocol instance consists of a CreateCoordinationContext message followed by a CreateCoordinationContextResponse message.



Registration

Registration is the explicit operation done to become a participant in an activity. To register to participate, the WS-Coordination specification defines a Registration protocol with the following two messages:

The Register message targets the Registration service it got from the CoordinationContext, and provides the name of the protocol it wants to register for and the Participant service's EndpointReference.

The RegisterResponse message provides the Coordinator service's EndpointReference.

A registration protocol instance consists of a Register message followed by a RegisterResponse message.



Importing an Activity

The Activation protocol can be used for importing an activity to a different set of coordination services. Importing an activity has several motivations. For example, it allows an application to use an intermediary set of coordination services that it prefers to deal with directly due to performance, trust domain, or control reasons. In a federated environment of autonomous services, this is especially necessary given the arbitrary trust relationships that may exist between them. Sometimes this procedure is also called interposition.

In Figure , after the import of the activity or the interposition of the trusted coordinator service B, Application B can deal with its own coordination services, which in turn deals with A's coordination services. Figure 3 illustrates importing:

1. Create the activity and receive a CoordinationContext. 2. Propagate A's CoordinationContext to B in an application message. 3. B has a choice of whether to deal directly with A's coordination services, as in Figure 2,

or use another set of coordination services as its representative. It decides to import the activity to B's coordination services by sending its Activation service the CreateCoordinationContext message with the context from A as the optional CurrentContext parameter. The returned CoordinationContext has the same activity identifier, but has B's Registration service.

4. Register B with its own Registration service obtained from its CoordinationContext identifier.

5. B's coordination services delegate the registration to A's Registration service, which it obtained from the CurrentContext parameter during import. This creates a new coordination protocol instance between A and B.

6. The coordination protocol instance can then begin between the participants A and B.

Protocol Instance Termination

The WS-Coordination specification does not define a protocol for terminating a coordination protocol instance. Termination is specific to a coordination protocol, and thus is part of that protocol definition. For example, the coordination protocols for WS-AtomicTransaction and WS-BusinessActivity have different requirements for the participants on how to terminate.

4.8.2 WS-AtomicTransaction

Atomic transactions greatly simplify application programming by shielding the application from system-generated exceptions, especially when they do not recur on retry.



Two-Phase Commit (2PC)

The atomic transaction 2PC protocol coordinates registered services to reach a commit or abort decision, and informs all services of the final result. The decision is the same for all the services in the transaction. Making this group decision uses two phases:

Prepare phase: All participants are asked to get ready to either commit or abort, and then vote on the overall outcome. The vote is propagated up to the root coordinator to make the overall group decision.

Commit phase: If all participants vote to commit, the decision will be to commit. Otherwise, it will be to abort.

An atomic transaction provides a simple programming model abstraction by making the following assumptions:

Updates are hidden (isolated) until they are committed. For even the weakest database isolation levels, write locks are held on updated data until the end of the transaction, so that updates are hidden from view by other transactions until commit. When a transaction spans multiple systems using 2PC, all of these systems hold write locks until commit, so the systems must trust each other to be responsive.

There is a single all-or-nothing decision for all participants. Any one of the systems can abort the entire atomic transaction, so these systems must trust each other to have cooperative intentions.

The 2PC protocol also requires that services in the Prepare phase waiting for the final outcome to be communicated by the coordinator do not drop unilaterally their participation in the activity. This is quite a stringent constraint, as the Prepare phase may be of long duration, so these systems must trust each other to be responsive.

The Coordination Protocols

The three coordination protocols for atomic transactions specified in WS-AtomicTransaction are the following:

Completion: An application uses this protocol to tell the coordinator to either try to commit or abort an atomic transaction. Upon receiving a Commit or Rollback message, the coordinator begins with Volatile2PC prepare phase and then proceeds through Durable2PC. The final result is signaled to the Completion protocol participant. This protocol does not guarantee that the message with the final outcome be delivered to the participant.

Volatile2PC: Participants managing volatile resources, such as a cache, should use this 2PC protocol. Upon receiving a Completion protocol Commit message, the root coordinator begins the prepare phase of all participants registered for the Volatile2PC protocol. All participants registered for this protocol must respond before a Prepare message is sent to a participant registered for the Durable2PC protocol. Additional participants may register with the coordinator until the coordinator issues a Prepare to any durable participant. This protocol does not guarantee that the message with the final outcome be delivered to the participant.

Durable2PC: Participants managing durable resources such as a database, a transactional file system or a durable queue service should use this 2PC protocol. Upon completing the prepare phase for Volatile2PC participants, the root coordinator begins the prepare phase for Durable2PC participants. All participants registered for this protocol must respond Prepared or ReadOnly before a Commit notification is issued to a participant registered for either protocol. This protocol guarantees that the message with the final outcome will be delivered to each of the participants.



4.4 Example

Figure illustrates the sequencing of the messages at commit for the scenario of a successful commit. There are three participants, one for each of the above protocols:

1. When all of the work has completed, the Completion participant (i.e., the application) initiates the commit process by deciding to try to commit and by sending a Commit message to the Coordinator. The Coordinator initiates the prepare phase on the Volatile2PC participant by sending a Prepare message. Each Volatile2PC participant signals that it has successfully finished preparing by sending a Prepared message.

2. The Coordinator initiates the prepare phase on the Volatile2PC participant by sending a Prepare message. Each Volatile2PC participant signals that it has successfully finished preparing by sending a Prepared message.

3. When all Prepared messages have been received from Volatile2PC participants, the root Coordinator initiates the prepare phase on the Durable2PC participant by sending a Prepare message. Each Durable2PC participant signals that it has successfully finished preparing by sending a Prepared message.

4. When all Prepared messages have been received from Durable2PC participants, the root Coordinator decides to commit, sends the Committed message to the Completion participant, and sends the Commit message to both the Volatile2PC and Durable2PC participants. There are no ordering constraints among the 4a, 4b and 4c messages.

WS-BusinessActivity

A business activity service is expected to use multiple atomic transactions to move the application from one consistent state to another. This leverages atomic transactions to handle system-generated exceptions, so that business activity coordination need handle only application-generated exceptions.

The WS-BusinessActivity coordination protocols provide a standard way for application code to drive toward an overall agreement while preserving their autonomy, even when application-generated exceptions occur. This agreement can involve a single pair of services or multiple pairs of services.

Each business activity should handle a single coordination agreement. When an application involves multiple different agreements, then multiple business activities should be used.



As an example of an activity involving a single pair of services, a buyer service sends a purchase order to a seller service. The seller either provides a quote that is good for some duration of time, or declines. The buyer decides whether to buy or cancel.

As an example of an activity involving multiple pairs of services, a buyer service sends a purchase order to multiple seller services. Some sellers will provide a quote that is good for some duration of time, while others will decline. The buyer service picks one of the quotes according to its standard selection criteria and tells the other sellers to cancel.

In both of the above cases, the WS-BusinessActivity coordination protocols add a standard structure to the application, but allow arbitrary application logic to handle the coordination.

The Coordination Protocols

WS-BusinessActivity defines two coordination protocols that differ only in the knowledge of when a unit of work has been completed.

BusinessAgreementWithParticipantCompletion: The participant knows when the coordinator will ask no more work of it.

BusinessAgreementWithCoordinatorCompletion: The coordinator has to tell the participant that no more work will be asked of it.

These protocols are considered to be of "broadest coverage". An application should use as much of these protocols' flexibility as needed. Some two-party interactions may avoid using some of the legal paths through the state diagrams presented in WS-BusinessActivity.

How Business Activities Differ From Atomic Transactions

Like an atomic transaction, a business activity deals with coordinating agreement among participants performing multiple distributed actions. However, business activities have distinctly different operational characteristics, which are described in the following points:

Type of exceptions: A business activity is aimed at handling application-generated exceptions that require application logic to resolve to continue progress toward a desirable goal. For example, knowing whether a participant has completed its work (and therefore requires a fee to compensate) may affect the decision of the coordinator. An atomic transaction is aimed at handling system-generated exceptions that are contained within the computer system. Atomic transactions provide a way to easily return to a consistent state, so that the exception can be handled by retrying the transaction or by manual intervention. Thus, when an application error can be treated as an atomic transaction rollback, atomic transactions provide a simple and robust mechanism for programming applications.

Duration: A business activity typically occurs over many minutes, or over days, weeks, or months. An atomic transaction typically happens almost instantaneously.

Isolation: A business activity does not hold locks throughout its agreement phases, so it has weaker isolation characteristics than atomic transactions. Resource availability problems occur when locks are held for user input or a real-world event such as the arrival of a shipment. Thus, in business activities, intermediate steps become visible, sometimes outside of the computer system. Even though the actions are tentative, they become part of real-world history. This increases resource availability by releasing locks between steps, but makes applications more complex by requiring them to program compensating actions.



Durability: Because a business activity is aimed at handling application-generated exceptions in order to keep moving forward toward a desirable goal, its state is typically saved between steps. Because a business activity is used as a solution for activities of long duration, durability is needed to avoid holding physical resources other than disk space (e.g., threads, connections, memory).

Agreement scope: A business activity is aimed at handling application exceptions, so its coordination involves application logic. For example, when a business activity coordinator receives a Faulted message from one of its participants, its action is determined by application logic. This makes each pair-wise interaction independent in a business activity, so there is not necessarily a global decision.

Combined services: A business activity involves business logic in its coordination, so that coordination typically requires access to application state. This close relationship makes it more convenient to combine the application and coordination into a single service, so that the application state required for coordination is available. Separating these services requires additional application-specific protocols between the two services.

Diverse operational characteristics: The business activity protocols enable services to have different operational behaviors. For example, services need not be simultaneously up, or the latency of message delivery among participants may be substantially different over time, yet agreement can still be reached.

Fewer constraints in coordinator behavior: The business activity protocols do not mandate any behavior on the coordinators. For example, a coordinator may use the all-or-nothing logic among its participants to determine the outcome of an activity. Or, it could use an "only one winner" behavior among its participants.

Expires time: The Expires time in the CoordinationContext is interpreted differently in a business activity. The Expires time represents a time after which participants can unilaterally leave the activity. This interpretation assumes that the expiration time was reached because some large failure happened. Thus, it is appropriate for participants to finish up their participation in the activity in the most appropriate manner.

Example



Figure illustrates a Buyer service that asks for quotes from three Seller services and picks the best deal:

The Buyer service sends each Seller a PurchaseOrder message with a CoordinationContext header. These messages can all be sent at the same time.

1. All three Sellers register for the BusinessAgreementWithParticipantCompletion protocol. 2. From this point on, each of the 3 Sellers have different flows:

a. Seller A cannot make a quote. It notifies the Buyer using the coordination protocol Fault message with message's ExceptionIdentifier parameter to indicate this.

b. Sellers B and C can make a quote. They each notify the Buyer using the coordination protocol Completed message with price information included in the message using the extensibility elements of the protocol messages.

3. After looking at the quotes from Sellers B and C, the Buyer chooses B. a. It notifies B with the coordination protocol Close message. b. It notifies C with the coordination protocol Compensate message. This

compensation may require the Buyer to pay a handling fee.

WEB SERVICE ORCHESTRATION AND CHOREOGRAPHY

Web Services

Web Services can convert your application into a Web-application, which can publish

its function or message to the rest of the world.

Communicate using open protocols

Self-contained and self-describing

Can be discovered using UDDI

Can be used by other applications

XML is the basis for Web services

The basic Web services platform is XML + HTTP.

XML provides a language which can be used between different platforms and

programming languages and still express complex messages and functions.

The HTTP protocol is the most used Internet protocol.

Web Services Platform Elements (WS-Platform)

Web services platform elements:

SOAP (Simple Object Access Protocol)

UDDI (Universal Description, Discovery and Integration)

WSDL (Web Services Description Language)



SOAP :

SOAP is an XML-based protocol to let applications exchange information over HTTP.

It is platform and language independent.

WSDL :

It is an XML-based language for locating and describing Web services

WSDL document structure composed by:

types : The data types used by the web service

messages : The messages used by the web service

portType : The operations performed by the web service

The communication protocols used by the web service



UDDI :

UDDI is a directory service where companies can register and search for Web services.

It stands for Universal Description, Discovery and Integration

It uses WDSL to describe interfaces to web services

UDDI communicates via SOAP

4.6 Orchestration

It describes how web services can interact with each other at the message level,

including the business logic and execution order.

With orchestration, the process is always controlled from the perspective of one of the

bussiness parties.

In orchestration, the involved web services are under control of a single endpoint

central process (another web service).

This process coordinates the execution of different operations on the Web services

participating in the process.



Composition Of Web Services with Orchestration

4.7 Choreography

It relates to describing externally observable interactions between web services

It is based on collaboration

It tracks the sequence of public message exchanges that occur between multiple

sources, including customers, suppliers, partners

The choreography is expressed in terms of states and the transitions between them.

A Business Activity is known as an abstract state, with Business Collaborations and

Business Transaction Activities known as concrete states.

The choreography is described in the ebXML Business Process Specification

Choreography, in contrast, does not depend on a central orchestrator. Each Web

service that participates in the choreography has to know exactly when to become

active and with whom to interoperate.



Composition Of Web Services with Choreography

Orchestration vs. Choreography



Service oriented analysis and Design – Service Modeling– Design standards and guidelines --Composition – WS-BPEL – WS-Coordination – WS-Policy – WS-Security – SOA support in J2EE.

UNIT V

BUILDING SOA-BASED APPLICATIONS

5.1 SERVICE-ORIENTED ANALYSIS AND DESIGN

5.1.1 SERVICE MODELING

Service-Oriented Analysis represents one of the early stages in an SOA initiative and the first phase in the service delivery cycle. It is a process that begins with preparatory information gathering steps that are completed in support of a service modeling a sub-process that results in the creation of conceptual service candidates, service capability candidates, and service composition candidates (s 1 and 2).

The Service-Oriented Analysis process is commonly carried out iteratively, once for each business process. Typically, the delivery of a service inventory determines a scope that represents a meaningful domain of the enterprise, or the enterprise as a whole. All iterations of a Service-Oriented Analysis then pertain to that scope, with each iteration contributing to the service inventory blueprint.

A key success factor of the Service-Oriented Analysis process is the hands-on collaboration of both Business Analysts and Technology Architects. The former group is especially involved in the definition of service candidates within a business-centric functional context because they understand the business processes used as input for the analysis and because service-orientation aims to align business and IT more closely.

5.1.2 1 - A generic Service-Oriented Analysis process that can be further customized. The first two steps essentially collect information in preparation for a detailed service modeling sub-process.



5.1.3 2 - A generic service modeling process comprised of steps that raise key service definition considerations.

5.1.4 3 - A look at how the collaboration between business analysts and technology architects changes with SOA projects.

Process Overview



A separate analysis is dedicated to each business process definition associated with a given service inventory. For the full definition of a service inventory blueprint, a complete top-down delivery process is carried out, comprised of numerous iterations through service-oriented analysis process steps.

5.1.5 4 - A high-level service-oriented analysis process.

How service-oriented analysis actually represents a parent process consisting of two information gathering steps and then a third step represented by the service modeling sub-process.

Information Gathering Steps

Define Analysis Scope

During this step business analysts are asked to clearly establish the boundary of the analysis. Most commonly, there is a ratio of one analysis process to one business process definition. However, business processes can be complex or multi-layered (containing nested processes) and may or may not already be representing portions of business logic already analyzed during a previous iteration of the service inventory analysis cycle. Therefore, this step may also require identifying portions of a given business process for which service modeling is not required.



Identify Affected Systems

It is helpful to have an understanding of what existing parts of the enterprise will be affected by the scope of the planned business process analysis. Especially relevant are legacy systems that may later raise service encapsulation and autonomy challenges. These types of constraints can directly impact the partitioning of logic into services and the ultimate granularity at which service candidates are defined.

Service Modeling Process

Service modeling is the process of conceptualizing services and capabilities prior to their actual physical definition and development. Because nothing concrete is defined during this stage, we qualify the results of carrying out this process with the term "candidate." Service modeling essentially identifies service capability candidates that are grouped into service candidates that are subsequently assembled into service composition candidates.

5.1.6 5 - A common service modeling process.

The iterative nature of the aforementioned inventory analysis allows for service candidates to be repeatedly revised and refined prior to the creation of corresponding services.

The service modeling steps displayed in the previous are explained in detail in "Service-Oriented Architecture: Concepts, Technology, and Design." In a nutshell, a business process definition is



decomposed (Step 1) into its most detailed representation, resulting in a series of granular actions. Those suitable for service encapsulation become potential service capability candidates (Step 2).

The service logic of each capability candidate is assessed in terms of whether it is specific or agnostic to the current business process. Agnostic capability candidates are grouped into agnostic service candidates usually based on entity and utility service models (Step 3), whereas non-agnostic capability candidates are placed into a task service candidate with a functional scope usually equivalent to the business process (Step 4).

During subsequent iterations of this process, the chances of identifying already defined capability candidates increase. Therefore, a separate discovery step (not shown) is added to ensure that no redundant capability or service candidates are introduced into the blueprint. Also select service-orientation principles are applied to shape modeled service candidates in preparation for their eventual designs (Step 5).

The following three service-orientation principles are typically applied during the service modeling process:

Service Reusability Service Autonomy Service Discoverability

After the initial set of service candidates is established, a candidate composition is assembled and subjected to possible runtime scenarios (Step 6). Subsequently, each of the identified service capability candidates is further studied to explore any additional processing requirements that may be needed to carry out its functionality. This kicks off the second half of the service modeling process (Steps 7-12) during which additional utility service capability candidates are generally defined. The process ends with an extended composition candidate modeling step and a final revision of all capability and service candidate definitions created so far.

5.2 Design standards and guidelines

5.2.1 COMPOSITION

5.2.2 Steps to composing SOA

Regardless of the shape or size of your SOA, it will consist of a number of technology components that establish an environment in which your services will reside. The fundamental components that typically comprise an SOA include:

an XML data representation architecture Web services built upon industry standards a platform capable of hosting and processing XML data and Web services

The fundamental components of a SOA: –  XML data representation architecture –  Web services built upon industry standards –  A platform capable of hosting and processing XML data and Web Services.



What types of services should be built and orchestrated? How should the first-generation standards be implemented? Which available extensions are required? Suggested preliminary steps for composing a SOA Choose Service Layers Position Core Standards Choose SOA Extensions

Considerations for choosing service layers

The service-oriented analysis process likely will have resulted in a preliminary identification of a suitable service layer configuration. The first step to designing SOA is deciding how you intend to con service layers within your environment, if at all.

Choosing Service Layers: Guidelines

Existing configurations - If service layers already have been standardized new service designs should conform to these layers. Required Standards - If new types of services or service layers are being developed ensure that they are delivered along with accompanying design standards. Service composition performance - Service compositions can impose severe processing overhead, especially when intermediary services are required to process SOAP messages (each service having to perform a validation, de-serialization and serialization steps). Service Deployment - Deployment becomes a concern when solution-agnostic services are being developed. Re-usable services accessed remotely impose message latency on solutions that need to connect to them. Business Services and XSD schema design - If an established XML data representation architecture exists, it should be analyzed for compatibility issues. Business Service Maintenance - If proceeding with the agile delivery strategy, on-going maintenance should be considered.

Considerations for positioning core SOA standards

This second step within the SOA composition sub-process requires that we establish the foundation standards that will form the basis of our architecture. On the surface, this may seem like a pretty easy task, given that the core family of standards most SOA vendors support is provided by a very commonly accepted set of XML and first-generation Web services specifications.



Considerations for choosing SOA extensions

Although by completing Steps 1 and 2, we may have assembled a basic service-oriented environment consisting of core standards and planned service layers, Step 3 is where we get to compose unique variations of SOA.



5.5 WS-POLICY 5.5.1 Introduction to WS-Policy

To integrate software systems with web services

a way to express its characteristics by means of

WS-Security

signed messages

Encryption

security tokens

Without this standard, developers need docs to integrate software systems.

Provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of Web Service entities

Defines a model to express these properties as policies

Goal:

Provide the mechanisms needed to enable Web Services applications to specify policies

WS-Policy specifies:

An XML-based structure called a policy expression containing policy information

Grammar elements to indicate how the contained policy assertions apply



5.5.2 Terminology Policy: refers to the set of information being expressed as policy assertions

Policy Assertion: represents an individual preference, requirement, capability, etc.

Policy Expression: set of one or more policy assertions

Policy Subject: an entity to which a policy expression can be bound

Policy Attachment: the mechanism for associating policy expressions with one or more subjects

Policy Expressions

A Policy Expression is the XML representation of a policy

XML facilitates interoperability between a heterogeneous platforms

We will look at how to name and identify them

Policy Namespaces WS-Policy schema defines all constructs that can used in a policy expression

Prefix Description Namespace

wsp WS-Policy, WS-PolicyAssertions, and WS-PolicyAttachment

http://schemas.xmlsoap. org/ws/2002/12/policy

wsse WS-SecurityPolicy http://schemas.xmlsoap. org/ws/2002/12/secext

wsu WS utilty schema http://schemas.xmlsoap. org/ws/2002/07/utility

msp WSE 2.0 policy schema http://schemas.microsoft.com/wse/2003/06/Policy

Policy Assertions A policy assertion: represents an individual preference, requirement, capability, or other characteristic is the basic building block of a policy expression an XML element with a well-known name and meaning. wsp:Policy xmlns:wsp="..." xmlns:wsu="..." wsu:Id="..." Name="..." TargetNamespace="..." > <Assertion wsp:Usage="..." wsp:Preference="..." /> <Assertion wsp:Usage="..." wsp:Preference="..." /> ... </wsp:Policy>

http://schemas.xmlsoap.org/ws/2002/12/policy



Types of Assertions Two types:

1. Requirements and capabilities that are explicitly manifested on the wire

2. No wire manifestation, just provide information

The Usage Qualifier

wsp:Usage distinguishes between

1. different types of assertions

2. how assertions are processed

Value Meaning

wsp:Required The assertion must be applied, otherwise an error results

wsp:Rejected The assertion is not supported and, if present, will cause failure

wsp:Optional The assertion may be made of the subject, but is not required

wsp:Observed The assertion will be applied to all subjects and requestors are told

wsp:Ignored The assertion will be ignored if present and requestors are told

Assertion Preference wsp:Preference attribute:

Used to specify the service’s preference as an integer value

Larger integer => higher preference

Omitted preference attribute is interpreted as a 0

Standard Policy Assertions WS-PolicyAssertions defines four general policy assertions for any subject

Policy Assertion Description

wsp:TextEncoding Specifies a character encoding

wsp:Language Specifies a natural language (xml:Lang)

wsp:SpecVersion Specifies a version of a particular specification

wsp:MessagePredicate Specifies a predicate that can be tested against the message (XPath expressions by default)



General Assertion Example What does this Assertion state?

<wsp:Policy xmlns:wsse="..."> <wsp:TextEncoding wsp:Usage="wsp:Required" Encoding="utf-8"/> <wsp:Language wsp:Usage="wsp:Required" Language="en"/> <wsp:SpecVersion wsp:Usage="wsp:Required" URI="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/" /> ... </wsp:Policy>

The subject requires

1. The UTF-8 character encoding

2. Any form of the English language

3. SOAP version 1.1

WS-SecurityPolicy Defines a set of security-related assertions

Policy Assertion Description

wsse:SecurityToken Specifies a type of security token (defined by WS-Security)

wsse:Integrity Specifies a signature format (defined by WS-Security)

wsse:Confidentiality Specifies an encryption format (defined by WS-Security)

wsse:Visibility Specifies portions of a message that MUST be able to be processed by an intermediary or endpoint

wsse:SecurityHeader Specifies how to use the <Security> header defined in WS-Security

wsse:MessageAge Specifies the acceptable time period before messages are declared "stale" and discarded

Combining Multiple Assertions Policy operators are used to combine assertions

Can nest operators

Policy Operator Description

wsp:All Requires that all of its child elements be satisfied

wsp:ExactlyOne Requires that exactly one child to be satisfied

wsp:OneOrMore Requires that at least one child be satisfied

wsp:Policy Same as wsp:All



Policy Reference

Mechanism to share policy assertions across policy expressions

Uses the naming conventions discussed above

<wsp:Policy xmlns:wsp="..."> ... <wsp:PolicyReference URI="..." Ref="..." Digest="..." DigestAlgorithm="..." /> ... </wsp:Policy>

Policy Attachments WS-PolicyAttachment defines mechanisms to associate expressions with subjects

Specifically defines mechanisms for:

XML elements

WSDL definitions

UDDI entries

Uses attributes

wsp:PolicyURIs – list of URIs

wsp:PolicyPrefs – list of QNames

The attribute wsp:PolicyAttachment binds an endpoint to a policy expression

Requires no change to the web service

5.6 WS-Security 5.6.1 The Web Services

Why Web Services? • loosley-coupled



• language-neutral

• platform-independent

But it isn’t secure… • Transport Layer Security (TLS) can provide point-to-point security, but not end-to-end,

problem with proxies.

• Want:

– Message integrity

– Message confidentiality

Goals of the specification • Multiple security token formats

• Multiple trust domains

• Multiple signature formats

• Multiple encryption technologies

• End-to-end message content security

Terminology • Confidentiality – the property that data is not made available to unauthorized individuals,

entities, or processes (encryption)

• Integrity – the property that data has not been modified (signature)

• Claim – a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, etc).

• Claim Confirmation – the process of verifying that a claim applies to an entity.

• Security Token – represents a collection of claims.

• Signed Security Token – a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket).



• Trust - the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes.

What is WS-Security?

– soap message protection through message integrity, confidentiality, and single message authentication

– extensible and flexible (multiple security tokens, trust domains, signature formats, and encryption technologies. )

– a flexible set of mechanisms that can be used to construct a range of security protocols

– Enhancement to SOAP

– Uses

– XML Encryption xmlenc

– XML Digital Signatures xmlsig

– SSL/TLS

Enables the scenario

The firewall is a “SOAP-firewall” not a traditional firewall.



How to Secure? • Integrity - information is not modified in transit

– XML signature in conjunction with security tokens

– Multiple signature, multiple actors, additional signature formats

• Confidentiality - only authorized actors or security token owners can view the data

– XML encryption in conjunction with security tokens

– Multiple encryption processes, multiple actors

• Authentication – you are whom you said you are

Security Tokens

Syntax <S:Envelope> <S:Header> ... <Security S:actor="...“ S:mustUnderstand="..."> ... </Security> ... </S:Header> <S:Body>… </S:Body> </S:Envelope>

Web Services Security Specifications The combination of security specifications, related activities, and interoperability profiles

will enable customers to easily build interoperable secure Web services.

Figure. Web Services Security Specifications

Secure Web Services • Securing Web Services has several parts

– XML Message Security Concepts



– Practical Implementations

Web Service Security Basic Picture • Web Services operate by exchanging (typically) SOAP messages.

• These messages may travel over secure network connections

– typical Web security techniques like certificates and HTTPS

• The SOAP messages themselves may be signed, encrypted, and otherwise secured.

• Note this picture does not show any SOAP intermediaries.

5.6.2 Security Challenges for Web Services • The previous picture represents the commonplace client-server style security.

– Message level security is redundant.

• But SOAP allows for other messaging patterns:

– Multiple relaying brokers.

– Multiple recipients.

• Each hop represents a different network connection.

– May want to authenticate peers at each step.

– Nodes may partially process messages.



5.6.3 Web Service Security Stack

5.3 BPEL (Business Process Execution Language)

• Business Process Execution Language

• enables:

– Definition of Business Processes using Web Services

– Coordination of a set of Web service interactions

– Degree of interoperability at the process level (describe process and use it in different runtime infrastructures)

• where it comes from:



– Builds on XML and Web Services

– Convergence of two workflow languages (WSFL – directed graphs; XLANG – block-structured language)



Traditional Flow Models

5.3.1 Structure of a BPEL4WS Process <process ...> <partners> ... </partners> 



<containers> ... </containers> <!– Data used by the process --> <correlationSets> ... </correlationSets> <!– Used to support asynchronous interactions --> <faultHandlers> ... </faultHandlers> <!–Alternate execution path to deal with faulty conditions --> <compensationHandlers> ... </compensationHandlers> <!–Code to execute when “undoing” an action --> (process body) <!– What the process actually does --> </process> 5.3.2 BPEL Basic Activities <invoke partner=“...” portType=“...” operation=“...” inputContainer=“...” outputContainer=“...”/>  <receive partner=“...” portType=“...” operation=“...” container=“...” [createInstance=“...”]/>  <reply partner=“...” portType=“...” operation=“...” container=“...”/>  <assign> <copy> <from container=“...”/> <to container=“...”/> </copy>+ </assign> <!– Data assignment between containers: --> Partner Definitions and Links <partner name=“...” serviceLinkType=“...” partnerRole=“...” myRole=“...”/> <!– A partner is accessed over a WS “channel”, defined by a service link type --> <serviceLinkType name=“..."> <role name=“..."> <portType name=“..."/>* </role> <role name=“..."> <portType name=“...”/>* </role> </serviceLinkType> <!– A SLT defines two roles and the portTypes that each role needs to support --> 5.3.3 BPEL Data Model



BPEL Structured Activities

Nesting Structured Activities. Example

5.3.4 BPEL Handlers and Scopes



How Handlers Work

• A compensation handler is used to reverse the work performed by an already completed scope

– A compensation handler can only be invoked by the fault handler or compensation handler of its immediate enclosing scope

• A fault handler defines alternate execution paths when a fault occurs within the scope.

• Typical scenario:

– Fault is thrown (retuned by invoke or explicitly by process)

– Execution of scope is terminated

– Appropriate fault handler located (with usual propagation semantics)

– Main execution is compensated to “undo” business effects of unfinished work.

5.3.5 BPEL Architecture

Date post:	22-Jun-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times