IT6801-Service Oriented Architecture

IT6801 SERVICE ORIENTED ARCHITECTURE L T P C
3 0 0 3
OBJECTIVES:
The student should be made to:
 Learn XML fundamentals.
 Be exposed to build applications based on XML.
 Understand the key principles behind SOA.
 Be familiar with the web services technology elements for realizing SOA.
 Learn the various web service standards.
UNIT I INTRODUCTION TO XML 9
XML document structure – Well formed and valid documents – Namespaces – DTD – XML
Schema –X-Files.
UNIT II BUILDING XML- BASED APPLICATIONS 9
Parsing XML – using DOM, SAX – XML Transformation and XSL – XSL Formatting –
Modeling Databases in XML.
UNIT III SERVICE ORIENTED ARCHITECTURE 9
Characteristics of SOA, Comparing SOA with Client-Server and Distributed architectures –
Benefits of SOA -- Principles of Service orientation – Service layers.
UNIT IV WEB SERVICES 9
Service descriptions – WSDL – Messaging with SOAP – Service discovery – UDDI –
Message Exchange Patterns – Orchestration – Choreography –WS Transactions.
UNIT V BUILDING SOA-BASED APPLICATIONS 9
Service Oriented Analysis and Design – Service Modeling – Design standards and
guidelines -- Composition – WS-BPEL – WS-Coordination – WS-Policy – WS-Security –
SOA support in J2EE.
TOTAL PERIOD: 45 Periods
OUTCOMES:
Upon successful completion of this course, students will be able to:
 Build applications based on XML.
 Develop web services using technology elements.
 Build SOA-based applications for intra-enterprise and inter-enterprise applications.
TEXTBOOKS:
1. Ron Schmelzer et al. “XML and Web Services”, Pearson Education, 2002
2. Thomas Erl, “Service Oriented Architecture: Concepts, Technology, and Design”,
Pearson Education, 2005.
REFERENCES:
1. Frank P.Coyle, “XML, Web Services and the Data Revolution”, Pearson Education,
2002.
2. Eric Newcomer, Greg Lomow, “Understanding SOA with Web Services”, Pearson
Education, 2005.
3. Sandeep Chatterjee and James Webber, “Developing Enterprise Web Services: An
Architect's Guide”, Prentice Hall, 20044.
4. James McGovern,Sameer Tyagi, Michael E.Stevens, Sunil Mathew, ”Java Web.
Services Architecture”, Morgan Kaufmann Publishers, 2003.

IT6801 SERVICE ORIENTED ARCHITECTURE
UNIT 1 - CSE/RMKCET 1
S.No. Name of the Topic Reference Book (Text Book)
UNIT I - INTRODUCTION TO XML
1. XML document structure Chapter 2 (Text 1)
2. Well-formed and valid documents Chapter 2 (Text 1)
3. Namespaces Chapter 2 (Text 1)
4.
DTD Chapter 3 (Text 1)
5.
6.
XML Schema Chapter 4 (Text 1)
7.
8.
X-Files Chapter 5 (Text 1)
9.
Content Beyond Syllabus JSON

XML (Extensible Markup Language)
XML is a simple, very flexible text format derived from SGML. Originally designed to meet the
challenges of large-scale electronic publishing, XML is also playing an increasingly important
role in the exchange of a wide variety of data on the Web and elsewhere.
Common Uses/Applications of XML
 Data Interchange Format
Because XML is nonproprietary and easy to read and write, it’s an excellent format for the
interchange of data among different applications.
Alternative Technologies: JSON (JavaScript Object Notation), YAML
 Web development
Web documents can be created from XML using XSLT to transform the documents into HTML.
 Documentation (or) Document Publishing
The term publishing refers to converting a document from a text file that contains XML markup
to one or more output files in a specific presentation format, such as HTML, Portable Document
Format (PDF), PostScript, Rich Text Format (RTF), and so on.
(eg): DocBook (XML vocabulary for representing document contents)
 Database Development
 Configuration Files
Configuration files, or config files configure the parameters and initial settings for some
computer programs. They are used for user applications, server processes and operating system
settings. (eg): web.xml
 Web Services
Advantages of XML
 Simplicity
 Extensibility
 Interoperability
 Openness
 Self-describing

Drawbacks of XML
XML takes up lots of space (3 to 20 times more) to represent data that could be similarly
modeled using a binary format or a simpler text file format. It’s the price we pay for human-
readable, platform-neutral, process-separated, metadata-enhanced, structured, validated code. It’s
possible that 1GB of database information can result in over 20GB of XML-encoded
information.
Introduction to XML
Markup Language
The main concept behind markup languages is that they use special text strings to surround data
or text with information that indicates the context, meaning, or interpretation of the data
encapsulated in the markup. In effect, markup languages in general and XML in particular really
contain only two kinds of information: markup elements and actual data that are given meaning
by these markup elements. Together, these are known as XML text.
Markup text has a couple rules. First, it needs to be differentiated from the rest of the document
text by a unique set of characters that delineates where the markup information starts and ends.
These special characters are known as delimiters.
Character Meaning
< The start of an XML markup tag
> The end of an XML markup tag
& The start of an XML entity
; The end of an XML entity
Table: XML Delimiter Characters
Extensible
Extensibility, as applied to XML, is the ability for the language to be used to define specific
vocabularies and metadata. Rather than being fixed in describing a particular set of data, XML,
in conjunction with its DTDs and schema, is able to define any number of documents that
together form a language of their own. It would be a difficult proposition at best to add a new set
of information to a text file or relational database management system (RDBMS). XML files,
especially those created using an “open content model,” can easily be extended by adding
additional elements and attributes.

XML Document Structure
The major portions of an XML document include the following:
 The XML declaration
 The Document Type Declaration
 The element data
 The attribute data
 The character data or XML content
XML Declaration
The first part of an XML document is the declaration. The XML declaration is a processing
instruction of the form <?xml ...?>. Although it is not required, the presence of the
declaration explicitly identifies the document as an XML document and indicates the version
of XML to which it was authored. In addition, the XML declaration indicates the presence of
external markup declarations and character encoding.
The standalone document declaration defines whether an external DTD will be processed as part
of the XML document. When standalone is set to “yes”, only internal DTDs will be allowed.
When it is set to “no”, an external DTD is required and an internal DTD becomes an optional
feature
<?xml version=“1.0” standalone=“yes” ?>
<?xml version=“1.0” standalone=“no” ?>
<?xml version=“1.0” encoding=“UTF-8” standalone=“yes” ?>

Document Type Declaration
The Document Type Declaration (DOCTYPE) gives a name to the XML content and
provides a means to guarantee the document’s validity, either by including or specifying a
link to a Document Type Definition (DTD).
General Forms of the Document Type Declarations
<!DOCTYPE NAME SYSTEM “file”>
<!DOCTYPE NAME SYSTEM [ ]>
<!DOCTYPE NAME SYSTEM “file” [ ]>
In the first form listed, the DOCTYPE is referring to a document that only allows use of an
externally defined DTD subset. The second declaration only allows an internally defined
subset within the document. The final listing provides a place for inclusion of an internally
defined DTD subset between the square brackets while also making use of an external subset.
In the preceding listing, the keyword NAME should be replaced with the actual root element
contained in the document, and the “file” keyword should be replaced with a path to a valid
DTD.
Markup and Content
In general, six kinds of markup can occur in an XML document: elements, entity references,
comments, processing instructions, marked sections, and Document Type Declarations.
 Elements
Within an XML document, elements are the most common form of markup. XML elements
are either a matched pair of XML tags or single XML tags that are “self-closing.” Matching
XML tags consist of markup tags that contain the same content, except that the ending tag is
prefixed with a forward slash.
<regno> Opening Tag / Start Tag
</regno> Closing Tag / End Tag
When elements do not come in pairs, the element name is suffixed by the forward slash.
These “unmatched” elements are known as empty elements.
<br/> Empty Elements

 Attributes
Attributes are name/value pairs contained within the start element that can specify text
strings that modify the context of the element.
<studentName section =“A”>Rahul</studentName>
 Entity References
Entities provide a means to indicate to XML-processing applications that a special text string
is to follow that will be replaced with a different literal value.
CHARACTER REFERENCE
& &
< <
> >
“ "
‘ '
Table: Built-in Entity References
<description>The following says that 8 is greater than5
</description>
<equation>4 > 5</equation>
 Comments
The character sequence  ends the comment. Comments can be
placed anywhere in a document and are not considered to be part of the textual content of an
XML document. As a result, XML processors are not required to pass comments along to an
application.

 Processing Instructions
Processing instructions (PIs) are like comments that are intended for computer programs
reading the document. However, XML parsers are required to pass along the contents of
processing instructions to the application on whose behalf they’re parsing, unlike comments

that a parser is allowed to silently discard. However, the application that receives the
information is free to ignore any processing instruction it doesn’t understand.
Processing instructions begin with <? and end with ?>. The starting <? is followed by an
XML name called the target, which identifies the program that the instruction is intended for,
followed by data for that program. Processing instructions have the following form:
<?target data?>
Eg: <?xml-stylesheet type=”text/xsl” href=”appUsers.xslt” ?>
The target in this example is xml-stylesheet.
 CDATA
CDATA stands for Character Data. CDATA sections provide a way to tell the parser that
there is no markup in the characters contained by the CDATA section. This makes it much
easier to create documents containing sections where markup characters might appear, but
where no markup is intended. Everything inside a CDATA section is ignored by the parser.
A CDATA section starts with "<![CDATA[" and ends with "]]>":
<example-code>
<![CDATA[
while (x <len&& !done) {
print( "Still working, 'zzzz'." );
++x;
}
]]>
</example-code>
Rules of XML Structure
All XML Elements Must Have a Closing Tag
XML requires all tags to be closed. They can be closed by matching a beginning element tag
with a closing tag, or they can be closed by the use of empty elements. In either case, no tag
may be left unclosed.

Incorrect XML Due to Unclosed Tags
<markup>This is not valid XML
<markup>Since there is no closing tag
XML Tags Are Case Sensitive
In XML, the use of capitalization is incredibly important. XML elements and attributes are
case sensitive. This means that differences in capitalization will be interpreted as different
elements or attributes. In XML, the elements <student> and <Student> are as different as
<egg> and <house>.
All XML Elements Must Have Proper Nesting
XML requires that elements be nested in proper hierarchical order. Tags must be closed in
the reverse order in which they are opened. A proper analogy is to think of XML tags as
envelopes. There must never be a case where one envelope is closed when an envelope
contained within it is still open.
<student>
<regno>
These tags are improperly nested
</student>
</regno>
All XML Documents Must Contain a Single Root Element
XML documents must contain a single root element—no less, and certainly no more. All
other elements in the XML document are then nested within this root element. Once the root
element is defined, any number of child elements can branch off it as long as they follow the
rules.
Attribute Values Must Be Quoted
When attributes are used within XML elements, their values must be surrounded by quotes.
Although most systems accept single or double quotes for attribute values, it is generally
accepted to use double quotes around attribute values.

<?xml version=1.0?>
<shirt>
<price currency=USD>14.99</price>
</shirt>
Incorrect XML Due to Improper Quoting of Attributes
Attributes May Only Appear Once in the Same Start Tag
Even though attributes may be optional, when they are present, they can only appear once.
This simple restriction prevents ambiguity when multiple, conflicting attribute name/value
pairs are present.
<shirt size=”large” size=”small”>Zippy Tee</shirt>
Incorrect XML Due to Multiple Attribute Names in Start Tag
Attribute Values Cannot Contain References to External Entities
Although external entities may be allowed for general markup text, attribute values cannot
contain references to external entities. However, attribute values can make use of internally
defined entities and generally available entities, such as < and ".
All Entities Except amp, lt, gt, apos, and quot Must Be Declared Before They
Are Used
Although this goes without saying, entities cannot be used before they are properly declared.
Referring to an undeclared entity would obviously result in an XML document that is not
well formed and proper. However, there are a number of entities that can be assumed to be
defined by XML processors. So far, these are limited to the entities &, <, >,
', and ".
Well-Formed XML Document
Well-formed XML document
A XML document is well-formed if it conforms to XML specification and it is syntactically
correct.
Not well-formed:
 An element lacks a closing tag (and is not self-closing).

 Elements overlap without proper nesting: <a><b></a></b>
 An attribute value is missing a closing quote that matches the opening quote.
 <or& are used in content rather than &lt or &.
 Multiple root elements exist.
 Multiple XML declarations exist, or an XML declaration appears other than at the top of
the document.
XML Processing
XML Parser or Processor is a software module that is used to read XML documents and provide
access to their content and structure.
XML Parser (Validating & Non-Validating)
A non-validating parser is required to verify that an input XML document is well formed or not.
Non-validating parsers have the advantage that they will generally run faster than validating
parsers because they perform less validation.
A validating parser requires that any document it parses contain a DTD or XSD. The validating
parser will read the DTD or XSD, verify that the document conforms with DTD or XSD, and
also verify that the document meets validity constraints defined by the XML recommendation.
An advantage of validating parsers is that every correct implementation of a validating parser
should produce essentially the same results when parsing a given XML document.
XML Vocabulary
An XML vocabulary is created by specifying a complete description of the elements and
attributes for a specific type of XML document.
(Eg) RSS, XSLT, SOAP, SVG etc
XML Namespace
An XML namespace is a collection of element and attribute names associated with a particular
XML vocabulary through an absolute URI known as the namespace name.

Need for XML Namespace
It provides a mechanism to avoid name conflicts when XML document may contain element or
attribute names from more than one XML vocabulary. If each vocabulary is given a namespace,
the ambiguity between identically named elements or attributes can be resolved.
Example
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.
Name conflicts in XML can easily be avoided using a name prefix.
<?xml version = "1.0"?>


<h:demo

xmlns:h = "http://www.w3schools.com/htmlTableInfo"
xmlns:f = "http://www.w3schools.com/furnitureTableInfo">
<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>
</h:demo>
In the example above, there will be no conflict because the two <table> elements have different
namespaces.
 xmlns is the attribute used to specify the namespace URI.
 h and f are namespace prefixes
 http://www.w3schools.com/htmlTableInfo
andhttp://www.w3schools.com/furnitureTableInfo are namespace URIs. They are
unique and need not represent actual webpages.
Default Namespace
To eliminate the need to place namespace prefixes in each element, document authors may
specify a default namespace for an element and its children.
<?xml version = "1.0"?>

<demo
xmlns = "http://www.w3schools.com/htmlTableInfo"
xmlns:f = " http://www.w3schools.com/furnitureTableInfo">
<table>
<tr>
<td>Apples</td>
<td>Bananas</td>
</tr>
</table>
<f:table>
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
</demo>
In the above example, xmlns attribute without namespace prefix specifies default namespace.
XML Schema
An XML Schema is a language for expressing constraints about XML documents. There are
several different schema languages in widespread use, but the main ones are:
 Document Type Definitions (DTDs)
 XSD (XML Schema Definitions)
 Relax-NG
 Schematron
DTD
A document type definition lists the elements, attributes, entities, and notations that can be used
in a document, as well as their possible relationships to one another. A DTD specifies a set of
rules for the structure of a document.
A DTD can be declared inside an XML document or in an external file.
 Internal DTD: DTD is declared inside the XML file.

 External DTD: DTD is declared in an external file.
The Document Type Declaration
A document type declaration begins with <!DOCTYPE and ends with a >. In between is the
name of the root element, followed either by a pair of square brackets containing the DTD itself
or by the SYSTEM keyword and a URL where the DTD can be found (or, occasionally, both). A
document type declaration has this basic form:
<!DOCTYPE rootelement SYSTEM | PUBLIC DTDlocation [
internalDTDelements ] >
 The exclamation mark (!) is used to signify the beginning of the declaration.
 DOCTYPE is the keyword used to denote this as a Document Type Definition.
 rootelement is the name of the root element or document element of the XML document.
 SYSTEM and PUBLIC are keywords used to designate that the DTD is contained in an
external document. Although the use of these keywords is optional, to reference an
external DTD you would have to use one or the other. The SYSTEM keyword is used in
tandem with a URL to locate the DTD. The PUBLIC keyword specifies some public
location that will usually be some application-specific resource reference.
 internalDTDelements are internal DTD declarations. These declarations will always be
placed within opening ([) and closing (]) brackets.
DTD Elements
 Each element in the DTD should be defined with the following syntax:
<!ELEMENT elementname rule >
o ELEMENT is the tag name that specifies that this is an element definition.
o elementname is the name of the element.
o rule is the definition to which the element’s data content must conform.
 Elements are declared using element declarations. Each element declaration gives the
name of the element and lists the elements and text that it can contain. This list is called
the content specification. For example, this element declaration for the firstName element
says that elements with the name firstName must contain only parsed character data:
<!ELEMENT firstName (#PCDATA)>

Every declaration begins with <!. Element declarations begin with <!ELEMENT(case-
sensitive, as most things are in XML). This is followed by some white space and the
name of the element being declared, firstName in this example.
 The content spec (#PCDATA) says that the element must contain parsed character data.
Parsed character data is essentially any text that’s not markup. This also includes entity
references, such as &, that are replaced by text when the document is parsed.
employee.dtd
<!ELEMENT Employees (employee*)>
<!ELEMENT employee (employeeName, employeeID, dateOfBirth, address)>
<!ELEMENT employeeName (firstName, lastName)>
<!ELEMENT employeeID (#PCDATA)>
<!ELEMENT dateOfBirth (month, date, year)>
<!ELEMENT address (city, state)>
<!ELEMENT firstName (#PCDATA)>
<!ELEMENT lastName (#PCDATA)>
<!ELEMENT month (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
employee.xml
<?xml version="1.0"?>
<!DOCTYPE Employees SYSTEM "employee.dtd">
<Employees>
<employee>
<employeeName>
<firstName>Rahul</firstName>
<lastName>Dravid</lastName>
</employeeName>
<employeeID>5012</employeeID>

<dateOfBirth>
<month>January</month>
<date>11</date>
<year>1973</year>
</dateOfBirth>
<address>
<city>Bangalore</city>
<state>Karnataka</state>
</address>
</employee>
</Employees>
DTD Element Rules
There are two basic types of rules that elements must fall into. The first type of rule deals
with content. The second type of rule deals with structure.
 Content Rules: The content rules for .elements deal with the actual data that defined
elements may contain. These rules include the ANY rule, the EMPTY rule, and the
#PCDATA rule.
o The ANY Rule
An element may be defined using the ANY rule. This rule is just what it sounds
like: The element may contain other elements and/or normal character data (just
about anything as long as it is well formed). An element using the ANY rule
would appear as follows:
<!ELEMENT elementname ANY>
o The EMPTY Rule
This rule is the exact opposite of the ANY rule. An element that is defined with
this rule will contain no data. However, an element with the EMPTY rule could
still contain attributes (more on attributes in a bit). The following element is an
example of the EMPTY rule:
<!ELEMENT elementname EMPTY>
o The #PCDATA Rule

The #PCDATA rule indicates that parsed character data will be contained in the
element. Parsed character data is data that may contain normal markup and will be
interpreted and parsed by any XML parser accessing the document. The following
element demonstrates the #PCDATA rule:
<!ELEMENT elementname (#PCDATA)>
 Structure Rules: The structure rules deal with how that data may be organized. There
are two types of structure rules we will look at here. The first is the “element only” rule.
The second rule is the “mixed” rule.
o The “Element Only” Rule
The “element only” rule specifies that only elements may appear as children of
the current element. The child element sequences should be separated by commas
and listed in the order they should appear. If there are to be options for which
elements will appear, the listed elements should be separated by the pipe symbol.
<!ELEMENT elementname (element1, element2, element3)>
<!ELEMENT elementname (element1 | element2)>
o The “Mixed” Rule
The “mixed” rule is used to help define elements that may have both character
data (#PCDATA) and child elements in the data they contain. A list of options or
a sequential list will be enclosed by parentheses. Options will be separated by the
pipe symbol (|), whereas sequential lists will be separated by commas.
<!ELEMENT elementname (#PCDATA | childelement1 |
childelement2)*>
Element Symbols
Asterisk (*) The data will appear zero or more times (0, 1, 2, …).
<!ELEMENT Employees (employee*)>
Plus sign (+) Signifies that the data must appear one or more times (1, 2, 3, …).
<!ELEMENT Employees (employee+)>
Question mark (?) Data will appear either zero times or one time in the element.
<!ELEMENT Employees (employee?)>

Pipe (|) Separates choices in a set of options.
<!ELEMENT accountType (savings | current | termDeposit)>
DTD Attributes
Attribute list declarations in a DTD will have the following syntax:
<!ATTLIST elementname attributename type defaultbehavior defaultvalue>
 ATTLIST is the tag name that specifies that this definition will be for an attribute list.
 elementname is the name of the element that the attribute will be attached to.
 attributename is the actual name of the attribute.
 type indicates which of the 10 valid kinds of attributes this attribute definition will be.
 defaultbehavior dictates whether the attribute will be required, optional, or fixed in value.
This setting determines how a validating parser should relate to this attribute.
 defaultvalue is the value of the attribute if no value is explicitly set.
<!ATTLIST employeeName
gender CDATA #REQUIRED
country CDATA #IMPLIED >
ATTLIST Declaration
An XML element using the attribute list declared here would appear as follows:
<employeeName gender = “male” country = “India”>
</employeeName>
DTD Entities
Entities in DTDs are storage units. They can also be considered placeholders. Entities are special
markups that contain content for insertion into the XML document. Usually this will be some
type of information that is bulky or repetitive. Entities make this type of information more easily
handled because the DTD author can use them to indicate where the information should be

inserted in the XML document. This is much better than having to retype the same information
over and over.
The general syntax of an entity is as follows:
<!ENTITY entityname [SYSTEM | PUBLIC] entitycontent>
 ENTITY is the tag name that specifies that this definition will be for an entity.
 entityname is the name by which the entity will be referred in the XML document.
 entitycontent is the actual contents of the entity—the data for which the entity is serving
as a placeholder.
 SYSTEM and PUBLIC are optional keywords. Either one can be added to the definition of
an entity to indicate that the entity refers to external content.
Internal Entity
DTD
<!ENTITY cpy “Copyright RMKCET 2017”>
Usage:
<copyright>&cpy;</copyright>
When the XML document containing the above content is parsed, &cpy; will be replaced with
“Copyright RMKCET 2017” in each instance in which it is used. Using the entity &cpy; saves
the XML document author from having to type in “Copyright RMKCET 2017” over and over.
External Entities
External entities are used to reference external content.
DTD
<!ENTITY rahul SYSTEM “http://srvr/emps/rahul.xml”>
Usage:
<staff>&rahul;</staff>
Non-Text External Entities and Notations
Some external entities will contain non-text data, such as an image file. We do not want the
XML parser to attempt to parse these types of files. The NDATA keyword is used to alert the
parser that the entity content should be sent unparsed to the output document.

A notation is a special declaration that identifies the format of non-text external data so that the
XML application will know how handle the data.
<!NOTATION gif SYSTEM “image/gif” >
<!ENTITY employeephoto SYSTEM “images/employees/rahul.gif” NDATA gif >
<!ELEMENT employee (name, sex, title, years) >
<!ATTLIST employee pic ENTITY #IMPLIED >
…
<employee pic=”employeephoto”>
…
</employee>
Parameter Entities
It is very similar to the internal entity. The main difference between an internal entity and a
parameter entity is that a parameter entity may only be referenced inside the DTD. Parameter
entities can be useful when you have to use a lot of repetitive or lengthy text in a DTD. Use the
following syntax for parameter entities:
<!ENTITY % entityname entitycontent>
The syntax for a parameter entity is almost identical to the syntax for a normal, internal entity.
However, notice that in the syntax, after the declaration, there is a space, a percent sign, and
another space before entityname. This alerts the XML parser that this is a parameter entity and
will be used only in the DTD. These types of entities, when referenced, should begin with % and
end with;.
Drawbacks of DTD
 DTDs are composed of non-XML syntax and are non-extensible.
 There can only be a single DTD per document.
 DTDs are not object oriented. There is no inheritance in DTDs.
 DTDs have weak data typing. DTDs basically have one data type: the text string.
 DTDs does not support namespace very well.
 Number and order of child elements is not properly supported by DTD.

XSD
The W3C XML Schema Definition Language (XSD) is an XML language for describing and
constraining the content of XML documents. W3C XML Schema is a W3C Recommendation.
Built-in Data Types
Some of the XSD Built-in data types:
Namespace URI for XML Schema:
http://www.w3.org/2001/XMLSchema
An element declaration in an XSD schema
<element name="RegisterNumber" type="xsd:integer"/>
The usage of this element in an XML document instance.
<RegisterNumber>12345</ RegisterNumber>
User-Defined Simple Types
A simple element is an XML element that contains only text. It cannot contain any other
elements or attributes. The text can be of many different types. It can be one of the types
XML Schema Type Java Data Type
xsd:string java.lang.String
xsd:integer java.math.BigInteger
xsd:int int
xsd.long long
xsd:short short
xsd:decimal java.math.BigDecimal
xsd:float float
xsd:double double
xsd:boolean boolean
xsd:byte byte

included in the XML Schema definition (boolean, string, date, etc.), or it can be a custom type
that you can define yourself.
One can also add restrictions (facets) to a data type in order to limit its content, or one can
require the data to match a specific pattern.
Example: Defining marks, Range 0-100
<xsd:simpleType name="marks">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
Facets in XSD
 enumeration
 fractionDigits
 length
 maxExclusive
 maxInclusive
 maxLength
 minExclusive
 minInclusive
 minLength
 pattern
Besides <restriction> element, <simpleType> element has <list> and <union> child elements.
The <list> element allows an element or attribute based on the type definition to contain a list of
values of a specified simple data type. The <union> element allows you to combine two or more
simple type definitions to create a collection of values.
User-Defined Complex Types
XSD schema declaration
<complexType name="Student">
<sequence>
<element name="RegisterNumber" type="xsd:integer"/>
<element name="StudentName" type="xsd:string"/>
<element name="DepartmentName" type="xsd:string"/>

<element name="CGPA" type="xsd:decimal"/>
</sequence>
</complexType>
Order Indicators
sequence the elements must appear in the order specified
all the elements must appear, but order is not important
choice specifies that either one child element or another can occur
Occurrence Indicators
maxOccurs specifies the maximum number of times an element can occur
minOccurs specifies the minimum number of times an element can occur
Group Indicators
Group Defines set of related elements
attributeGroup Defines set of related attributes
Table: XSD Indicators
 <xsd:simpleContent> is used when you have an element that can contain structural
markup (complexType) and the element is not allowed to contain child elements. In other
words the elements content type allows only attributes and text content.
<?xml version="1.0" encoding="UTF-8" ?>

<xs:schemaxmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="books">
<xs:complexType>
<xs:sequence>
<xs:element name="book" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="bookname" type="xs:string"/>

<xs:element name="isbn" type="xs:string"/>
<xs:element name="authorname">
<xs:complexType>
<xs:sequence>
<xs:element name="firstname"
type="xs:string"/>
<xs:element name="lastname"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="publishername" type="xs:string"/>
<xs:element name="bookprice">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:decimal">
<xs:attribute name="currency" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

<books xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="book.xsd">
<book>
<bookname>Internet and World Wide Web How to Program</bookname>
<isbn>ISBN-10: 0-13-215100-6</isbn>
<authorname>
<firstname>Paul J</firstname>
<lastname>Deitel</lastname>
</authorname>
<publishername>Deitel and Associates, Inc</publishername>
<bookprice currency="rupees">11486</bookprice>
</book>
<book>
<bookname>Java: The Complete Reference</bookname>
<isbn>ISBN-10: 9339212096</isbn>
<authorname>
<firstname>Herbert</firstname>
<lastname>Schildt</lastname>
</authorname>
<publishername>McGraw Hill</publishername>
<bookprice currency="rupees">539</bookprice>
</book>
</books>

XFiles: XPath, XPointer and XLink
XPath
XPath is a syntax for specifying a collection of elements or other information contained within
an XML document.
Conceptually, XPath assumes that the XML document to which XPath expressions will be
applied has been parsed into an internal tree representation. The XPath tree model is similar to
the DOM tree. For example, the nodes in an XPath tree are of different types, such as element,
text, and comment nodes. In addition, unlike the DOM model, the XPath tree model also uses
nodes to represent attribute name value pairs.
The root of the XPath parse tree is known as the document root. Like an instance of Document in
the DOM, this node of the XPath parse tree has a child node representing the root of the element
hierarchy in the parsed document; this node is called the document element.
Location Path
An XPath expression that represents one or more nodes within an XPath parse tree is known as a
location path. A location path can be absolute or relative.
An absolute location path starts with a slash ( / ) and a relative location path does not. In both
cases the location path consists of one or more location steps, each separated by a slash:
An absolute location path:
/step/step/...
A relative location path:
step/step/...
Each step is evaluated against the nodes in the current node-set.A step consists of:
 an axis (defines the tree-relationship between the selected nodes and the current node)
 a node-test (identifies a node within an axis)
 zero or more predicates (to further refine the selected node-set)
The syntax for a location step is:
axisname::nodetest[predicate]

Table: Some XPath 1.0 Axis Names
Example Result
child::book Selects all book nodes that are children of the current
node
attribute::lang Selects the lang attribute of the current node
child::* Selects all element children of the current node
attribute::* Selects all attributes of the current node
child::text() Selects all text node children of the current node
child::node() Selects all children of the current node
descendant::book Selects all book descendants of the current node
ancestor::book Selects all book ancestors of the current node

ancestor-or-
self::book
Selects all book ancestors of the current node - and the
current as well if it is a book node
child::*/child::price Selects all price grandchildren of the current node
Table: XPath Axis Name Examples
<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
</book>
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
</book>
<book category="WEB">
<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>
</book>

<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
</book>
</bookstore>
Program: books.xml
Example XPath Expressions
 /bookstore/book/title - selects all the title nodes
 /bookstore/book[1]/title - selects the title of the first book node under the
bookstore element
 /bookstore/book/price[text()] - selects the text from all the price nodes
 /bookstore/book[price>35]/price - selects all the price nodes with a price higher than 35
 /bookstore/book[price>35]/title - selects all the title nodes with a price higher than 35
XPointer
The XML Pointer Language (XPointer) builds on the XPath specification. An XPointer uses
location steps the same as XPath but with two major differences: Because an XPointer describes
a location within an external document, an XPointer can target a point within that XML
document or a range within the target XML document.
Because XPointer builds on the XPath specification, the location steps within an XPointer are
comprised of the same elements that make up XPath location steps.
In addition to the node tests already listed for XPath expressions, XPointer provides two more
important node tests:
 point()
 range()
For this new functionality to work correctly, the XPointer specification added the concept of a
location within an XML document. Within XPointer, a location can be an XPath node, a point, or

a range. A point can represent the location immediately before or after a specified character or
the location just before or just after a specified node. A range consists of a start point and an end
point and contains all XML information between those two points.
XPointer expressions also allow predicates to be specified as part of a location step in much the
same fashion XPath expressions allow for them.
For an XPath expression, the result from a location step is known as a node set; for an XPointer
expression, the result is known as a location set.
<People>
<Person>
<Name>Dillon Larsen</Name>
<Address>
<Street>123 Jones Rd.</Street>
<City>Houston</City>
<State>TX</State>
<Zip>77380</Zip>
</Address>
</Person>
<Person>
<Name>Madi Larsen</Name>
<Address>
<Street>456 Hickory Ln.</Street>
<State>TX</State>
<Zip>77069</Zip>
</Address>
</Person>
<Person>
<Name>John Doe</Name>
<Address>
<Street>214 Papes Way</Street>

<State>TX</State>
<Zip>77301</Zip>
</Address>
</Person>
</People>
XPointer Expression Location
/People/Person[1]/Name/text()/point()[position()=4] Just after the l and just before the start o
in Dillon
/People/Person[1]/Name/text()/start-
point()[position()=0]
Just before the D in Dillon
/People/Person[2]/Address/ start-point()[position()=2] Just before the <State> element in the
<Person> element for Madi Larsen
/People/Person[2]/Address/ start-point()[position()=0] Just before the <Street> element in
the <Person> element for Madi Larsen
XLink
The XML Linking Language, XLink, allows a link to another document to be specified on any
element within an XML document. The XML Linking Language creates a link to another
resource through the use of attributes specified on elements, not through the actual elements
themselves.
Attribute Description
xlink:type This attribute must be specified and indicates what type of XLink is represented
or defined.
xlink:href This attribute contains the information necessary to locate the desired resource.
xlink:role This attribute describes the function of the link between the current resource and
another.
xlink:arcrole This attributes describes the function of the link between the current resource and

another.
xlink:title This attribute describes the meaning of the link between the resources.
xlink:show This attribute indicates how the resource linked to should be displayed.
xlink:actuate This attribute specifies when to load the linked resource.
xlink:label This attribute is used to identify a name for a target resource.
xlink:from This attribute identifies the starting resource.
xlink:to This attribute identifies the ending resource.
Further Reading
1. Validating XML document against XSD.
https://stackoverflow.com/questions/124865/xml-schema-xsd-validation-tool

S.No. Name of the Topic Reference Book(Text Book)
UNIT II - BUILDING XML- BASED APPLICATIONS
1.
Parsing XML using DOM Chapter 7 (Text 1)
2.
3.
Parsing XML using SAX Chapter 8 (Text 1)
4.
5.
XML Transformation and XSL Chapter 9 (Text 1)
6.
7. XSL Formatting Chapter 9 (Text 1)
8.
Modeling Databases in XML Chapter 10 (Text 1)
9.

XML Processing
XML Parser or Processor is a software module that is used to read XML documents and provide
access to their content and structure.
DOM
The Document Object Model is a platform- and language-neutral standard application
programming interface (API) that will allow programs and scripts to dynamically access and
update the content, structure and style of documents. It is a W3C recommendation.
In DOM-based XML processing, an XML document is first input and parsed, creating a tree
of nodes representing elements, text, comments, and so on. After the tree has been
constructed, methods can be called to modify the tree, extract data from it, and so on.
DOM Levels
The DOM working group works on phases (or levels) of the specification.
 Level 1 allows traversal of an XML document as well as the manipulation of the content
in that document.
 Level 2 extends Level1 with additional features such as namespace support, events,
ranges, and so on.
 Level 3 extends Level 2. It provides features for loading and saving documents and
validation.
DOM Core
The DOM core is available in DOM Level 1 and beyond. It permits you to create and manipulate
XML documents in memory. DOM is a tree structure that represents elements, attributes, and
content.
DOM Interfaces
The DOM interfaces are defined in IDL so that they are language neutral.

Fig: Interface relationships.

Class Description
DocumentBuilder Defines the API to obtain DOM Document instances from an
XML document.
DocumentBuilderFactory Defines a factory API that enables applications to obtain a
parser that produces DOM object trees from XML documents.
JAXP provides a unified approach to creating parser instances through a factory mechanism.
A factory is just an object that is used to create other objects.
<!DOCTYPE Employees SYSTEM "employee.dtd">
<?xml-stylesheet type="text/xsl" href="employeestyle.xsl" ?>
<Employees>
<employee>
<employeeName>
</employeeName>
<dateOfBirth>
<month>January</month>
<date>11</date>
<year>1973</year>
</dateOfBirth>
<address>
<city>Bangalore</city>
<state>Karnataka</state>
</address>
</employee>
<employee>
<employeeName>

<firstName>Sachin</firstName>
<lastName>Tendulkar</lastName>
</employeeName>
<dateOfBirth>
<month>April</month>
<date>24</date>
<year>1973</year>
</dateOfBirth>
<address>
<city>Mumbai</city>
<state>Maharashtra</state>
</address>
</employee>
</Employees>
Program: employee.xml
package xml;
import java.io.File;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
public class DOMDemo {
protected DocumentBuilder documentBuilder;
protected Element root;

public DOMDemo() throws Exception {
DocumentBuilderFactory documentBuilderFactory =
DocumentBuilderFactory.newInstance();
documentBuilder =
documentBuilderFactory.newDocumentBuilder();
}
public static void main(String[] args) throws Exception {
String fileName = "employee.xml";
DOMDemo dom = new DOMDemo();
dom.parse(fileName);
dom.printAllElements();
}
public void parse(String fileName) throws Exception {
File inputFile = new File(fileName);
Document doc = documentBuilder.parse(inputFile);
root = doc.getDocumentElement();
System.out.println("Root element is:" + root.getNodeName());
}
public void printAllElements() throws Exception {
printElement("", root);
}
public void printElement(String indent, Node aNode) {
if (aNode.getNodeType() == Node.TEXT_NODE) {
System.out.println(indent + aNode.getNodeValue());
} else {

System.out.println(indent + "<" + aNode.getNodeName()
+ ">");
Node child = aNode.getFirstChild();
while (child != null) {
printElement(indent + "t", child);
child = child.getNextSibling();
}
System.out.println(indent + "</" + aNode.getNodeName()
+ ">");
}
}
}
Program: DOMDemo.java

Creating an XML Document
package xml;
import javax.xml.parsers.*;
import javax.xml.transform.*;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import org.w3c.dom.*;
public class DOMCreationDemo {
public static final String xmlFilePath = "company.xml";
public static void main(String argv[]) {
try {

DocumentBuilderFactory documentFactory =
DocumentBuilderFactory.newInstance();
DocumentBuilder documentBuilder =
documentFactory.newDocumentBuilder();
Document document = documentBuilder.newDocument();
// root element
Element root = document.createElement("company");
document.appendChild(root);
// employee element
Element employee = document.createElement("employee");
root.appendChild(employee);
// set an attribute to staff element
Attr attr = document.createAttribute("id");
attr.setValue("10");
employee.setAttributeNode(attr);
// firstname element
Element firstName = document.createElement("firstname");
firstName.appendChild(document.createTextNode("Sachin"));
employee.appendChild(firstName);
// lastname element
Element lastname = document.createElement("lastname");
lastname.appendChild(document.createTextNode("Tendulkar"));
employee.appendChild(lastname);
// email element
Element email = document.createElement("email");
email.appendChild(document.createTextNode("sachin.tendulkar@gmail
.com"));
employee.appendChild(email);
// department elements

Element department = document.createElement("department");
department.appendChild(document.createTextNode("Batting"));
employee.appendChild(department);
// create the xml file
// transform the DOM Object to an XML File
TransformerFactory transformerFactory =
TransformerFactory.newInstance();
Transformer transformer =
transformerFactory.newTransformer();
DOMSource domSource = new DOMSource(document);
StreamResult streamResult = new StreamResult(new
File(xmlFilePath));
transformer.transform(domSource, streamResult);
System.out.println("Done creating XML File");
} catch (ParserConfigurationException pce) {
pce.printStackTrace();
} catch (TransformerException tfe) {
tfe.printStackTrace();
}
}
}
DOM Traversal and Range
Traversal and range are features added in DOM Level 2.You can determine whether traversal is
supported by calling the hasFeature()method of the DOMImplementation interface. For
traversal, you can use the arguments“Traversal” and “2.0” for the feature and version parameters
of the hasFeature()method.
Traversal
Traversal is a convenient way to walk through a DOM tree and select specific nodes.This is
useful when you want to find certain elements and perform operations on them.

Interface Description
NodeIterator Used to walk through nodes linearly. Represents a subtreeas a linear list.
TreeWalker Represents a subtree as a tree view.
NodeFilter Can be used in conjunction with NodeIterator andTreeWalker to select
specific nodes.
DocumentTraversal Contains methods to create NodeIterator andTreeWalker instances.
Table: Summary of Traversal Interfaces
Range
Range interfaces provide a convenient way to select, delete, extract, and insert content. You can
determine whether range is supported by calling the hasFeature(...) method of the
DOMImplementation interface. You can use the arguments “Range” and “2.0” for feature and
version. There are a number of applications for which the range interfaces are useful.
A range consists of two boundary points corresponding to the start and the end of the range. A
boundary point’s position in a Document or DocumentFragment tree can be characterized by a
node and an offset. The node is the container of the boundary point and its position. The
container and its ancestors are the ancestor containers of the boundary point and its position. The
offset within the node is the offset of the boundary point and its position. If the container is an
Attr, Document, DocumentFragment, Element, or EntityReference node, the offset is between its
child nodes. If the container is a CharacterData, Comment, or ProcessingInstruction node, the
offset is between the16-bit units of the UTF-16 encoded string contained by it.
Interface Description
Range This interface describes a range and contains methods to define, delete,
insert content.
DocumentRange This interface creates a range.
Table: Summary of Range Interfaces
DOM Implementations
The DOM working group supplies Java language bindings as part of the DOM specification. The
specification and Java language bindings are available at the W3C Web site. These bindings are
sets of Java source files containing Java interfaces, and they map exactly to the DOM interfaces.

The package org.w3c.dom contains the Java interfaces but does not include a usable
implementation. In order to make the interfaces do something useful, you will need an
implementation, or a parser. A number of DOM implementations are available for Java.
Java APIs for XML Processing (JAXP)
The Java API for XML Processing or JAXP is one of the Java XML Application
programming interfaces (API). It provides the capability of validating and parsing XML
documents. javax.xml.parsers: The JAXP APIs, which provide a common interface for
different vendors' SAX and DOM parsers.
Xerces
JDOM
Small DOM-like Implementations
Meant for smaller devices.
 NanoXML
 TinyXML
 kXML
SAX – Event Oriented Parsing
 SAX (Simple API for XML) is an API that can be used to parse XML documents.
 SAX provides a framework for defining event listeners, or handlers. These handlers are
written by developers interested in parsing documents with a known structure. The handlers
are registered with the SAX framework in order to receive events. Events can include start of
document, start of element, end of element, and so on. The handlers contain a number of
methods that will be called in response to these events. Once the handlers are defined and
registered, an input source can be specified and parsing can begin.
Class Description
SAXParser Defines the API that wraps an XMLReader implementation class.
SAXParserFactory Defines a factory API that enables applications to configure and
obtain a SAX based parser to parse XML documents.
Table: javax.xml.parsers

The basic steps to perform SAX Parsing to an XML Document are:
 Create an new instance of SAXParserFactory
 Use the appropriate handlers to hand the events of the parsing process by extending the
DefaultHandler class
 Create the appropriate callback functions to handle the events, e.g. when a new element is
found
package xml;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;
public class SAXDemo extends DefaultHandler {
public void startDocument() {
System.out.println("***Start of Document***");
}
public void endDocument() {
System.out.println("***End of Document***");
}
public void startElement(String uri, String localName, String
qName, Attributes attributes) {
System.out.print("<" + qName);
int n = attributes.getLength();

for (int i = 0; i < n; i += 1) {
System.out.print("" + attributes.getQName(i) + "='" +
attributes.getValue(i) + "");
}
System.out.println(">");
}
public void characters(char[] ch, int start, int length) {
System.out.println(new String(ch, start, length).trim());
}
public void endElement(String namespaceURI, String localName,
String qName) throws SAXException {
System.out.println("</" + qName + ">");
}
public static void main(String args[]) throws Exception {
String fileName = "employee.xml";
SAXDemo handler = new SAXDemo();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.parse(new File(fileName), handler);
}
}

ErrorHandler contains three methods that can be used to determine whether a document
iswell formed and valid.Either error() or warning() will be called if the document is well formed
but not valid(that is, it violates the rules of the DTD), and fatalError() will be called if the
documentis not well formed.
/*SAX Validation*/
package xml;
import java.io.FileReader;
import org.xml.sax.InputSource;

import org.xml.sax.SAXParseException;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLReaderFactory;
public class SAXValidationDemo extends DefaultHandler {
private boolean valid;
private boolean wellFormed;
public SAXValidationDemo() {
valid = true;
wellFormed = true;
}
public void startDocument() {
System.out.println("***Start of Document***");
}
public void endDocument() {
System.out.println("***End of Document***");
}
public void error(SAXParseException e) {
valid = false;
}
public void fatalError(SAXParseException e) {
wellFormed = false;
}

public void warning(SAXParseException e) {
valid = false;
}
public boolean isValid() {
return valid;
}
public boolean isWellFormed() {
return wellFormed;
}
public static void main(String args[]) throws Exception {
XMLReader parser = XMLReaderFactory.createXMLReader();
SAXValidationDemo handler = new SAXValidationDemo();
parser.setContentHandler(handler);
parser.setErrorHandler(handler);
parser.parse(new InputSource(new
FileReader("employee.xml")));
if (!handler.isWellFormed()) {
System.out.println("Document is NOT well formed.");
}
if (!handler.isValid()) {
System.out.println("Document is NOT valid.");
}
if (handler.isWellFormed() && handler.isValid()) {
System.out.println("Document is well formed and
valid.");
}
}
}

Lexical Events
LexicalHandler interface, part of org.xml.sax.ext package, is used to capture events like
comments, CDATA and DTD references.
Comparing DOM and SAX
S.No. DOM SAX
1 Tree Based: The DOM parser first read
and parse anentire XML document into a
tree representation and then process this
tree.
Event Based: The SAX parser interact
with an application as itreads an XML
document. As an XML parser is reading
an XML document, certainevents occur.
2 More CPU time& Memory:Theentire
document tree must be created, even if
only a fraction of the document is
actuallyrelevant to the software
processing the document. Hence
consumes more CPU power and
memory.
Less CPU time & Memory: Only the
relevant element is parsed at a time. It
consumes less CPU power and memory

JAXB
Java Architecture for XML Binding (JAXB) provides a fast and convenient way to bind XML
schemas and Java representations, making it easy for Java developers to incorporate XML data
and processing functions in Java applications. As part of this process, JAXB provides methods
for unmarshalling (reading) XML instance documents into Java content trees, and then
marshalling (writing) Java content trees back into XML instance documents. JAXB also provides
a way to generate XML schema from Java objects.
The general steps in the JAXB data binding process are:
1. Generate classes: An XML schema is used as input to the JAXB binding compiler to
generate JAXB classes based on that schema.
xjc: JAXB tool that compiles an XML schema file into fully annotated Java classes
Customizing in JAXB2.0
xjc -b <file> <schema>
Eg: xjc schema1.xsd schema2.xsd schema3.xsd -b bindings123.xjb

2. Compile classes: All of the generated classes, source files, and application code must be
compiled.
3. Unmarshal: XML documents written according to the constraints in the source schema
are unmarshalled by the JAXB binding framework. Note that JAXB also supports
unmarshalling XML data from sources other than files/documents, such as DOM nodes,
string buffers, SAX Sources, and so forth.
4. Generate content tree: The unmarshalling process generates a content tree of data
objects instantiated from the generated JAXB classes; this content tree represents the
structure and content of the source XML documents.
5. Validate (optional): The unmarshalling process optionally involves validation of the
source XML documents before generating the content tree. Note that if you modify the
content tree in Step 6, below, you can also use the JAXB Validate operation to validate
the changes before marshalling the content back to an XML document.
6. Process content: The client application can modify the XML data represented by the
Java content tree by means of interfaces generated by the binding compiler.
7. Marshal: The processed content tree is marshalled out to one or more XML output
documents. The content may be validated before marshalling.
8.
Comparing with DOM and SAX
 DOM: JAXB is faster and requires less memory when compared with DOM.
 SAX: There is no need to create and use a parser and no need to write a content handler
with callback methods. What this means is that developers can access and process XML
data without having to know XML or XML processing.

<address>
<name>Ajeeth</name>
<company>Google</company>
<phone>(011) 123-4567</phone>
</address>

/*POJO mapped to XML using set of JAXB annotations*/
package xml;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
@XmlRootElement(name = "address")
public class Address {
private String name;
private String company;
private String phone;
public String getName() {
return name;
}
@XmlElement(name = "name")
public void setName(String name) {
this.name = name;
}
public String getCompany() {
return company;
}
@XmlElement(name = "company")
public void setCompany(String company) {
this.company = company;
}
public String getPhone() {

return phone;
}
@XmlElement(name = "phone")
public void setPhone(String phone) {
this.phone = phone;
}
@Override
public String toString() {
return "Address [name=" + name + ", company=" + company + ",
phone=" + phone + "]";
}
}
/*Unmarshaling – XML to Java*/
package xml;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
public class JAXBUnmarshalDemo {
public static void main(String[] args) {
try {

File file = new File("address.xml");
JAXBContext jaxbContext = JAXBContext.newInstance(Address.class);
Unmarshaller jaxbUnmarshaller = jaxbContext.createUnmarshaller();
Address address = (Address) jaxbUnmarshaller.unmarshal(file);
System.out.println(address);
} catch (JAXBException e) {
e.printStackTrace();
}
}
}
Output
Address [name=Ajeeth, company=Google, phone=(011) 123-4567]
/*Marshaling – Java Objects to XML*/
package xml;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
public class JAXBMarshalDemo {
public static void main(String[] args) {
Address address = new Address();
address.setName("Rahul Dravid");
address.setCompany("Rajasthan Royals");
address.setPhone("99999 88888");
try {
File file = new File("address.xml");

JAXBContext jaxbContext = JAXBContext.newInstance(Address.class);
Marshaller jaxbMarshaller = jaxbContext.createMarshaller();
// output pretty printed
jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
//File Output
jaxbMarshaller.marshal(address, file);
//Console Output
jaxbMarshaller.marshal(address, System.out);
} catch (JAXBException e) {
e.printStackTrace();
}
}
}
Output
S.No. Methods Description
1 public abstract Marshaller
createMarshaller() throws
Create a Marshaller object that can be used to convert a
java content tree into XML data.

JAXBException
2 public abstract Unmarshaller
createUnmarshaller() throws
JAXBException
Create an Unmarshaller object that can be used to convert
XML data into a java content tree.
3 public static void
marshal(Object jaxbObject,
File xml)
Writes a Java object tree to XML and store it to the
specified location.
4 public static JAXBContext
newInstance(Class...
classesToBeBound)
throws JAXBException
Obtain a new instance of a JAXBContext class.
Annotation Type Description
@XmlRootElement(name=”Student”) Maps a class or an enum type to an XML element.
@XmlElement(name=”regno”) Maps a JavaBean property to a XML element derived
from property name.
@XmlAttribute Maps a JavaBean property to a XML attribute.
XSL
XSL is a family of recommendations for defining XML document transformation and
presentation. It consists of three parts:
 XSL Transformations (XSLT): It is a language for transforming XML.
 The XML Path Language (XPath): It is an expression language used by XSLT (and
many other languages) to access or refer to parts of an XML document.
 XSL Formatting Objects (XSL-FO): It is an XML vocabulary for specifying formatting
semantics.
ExtensibleStylesheet Language (XSL) is a “programming language” that allows extraction of
information from oneXMLtext documentand uses that information to create another XML text

document.XSL is an XML vocabulary; that is, XSL documents arewell-formed XML documents.
So the transformation “program” is an XML document.
AnXSL document normally contains two types of information: template data, which is textthat is
copied to the output XML text document with little or no change; and XSL markup,which
controls the transformation process.
XSLT: Template-based Transformation
 First, the root element of an XSLT document can be named either transform or stylesheet.
There is no semantic difference between these elements.
 The content of the root element often consists of one or more template elements. Each
template represents a template rule, which typically consists of two parts:
o An XPath expression specified as the value of the template element’s match attribute
and known as the template rule’s pattern.
o The content of the template rule, which is known as the template portion of the rule.
 Software for performing an XSLT transformation, such as JAXP, is known as an XSLT
processor. An XSLT processor is given two inputs—an XSLT document and asource XML
document—and produces a single result XML document. Internally, an XSLTprocessor
represents each of these documents as an XPath tree, called the source tree, thestyle-sheet

tree, and the result tree, respectively. Since all three trees are XPath trees, nodes in any of
these trees can be referenced using XPathexpressions.
<?xml version="1.0" encoding="utf-8" ?>

<?xml-stylesheet type="text/xsl" href="studentstyle.xsl" ?>
<students>
<student>
<registernumber>1001</registernumber>
<name>Badrinath</name>
<cgpa>8.1</cgpa>
</student>
<student>
<name>Dhoni</name>
<cgpa>6.5</cgpa>
</student>
<student>
<name>Rahul</name>
<cgpa>9.6</cgpa>
</student>
<student>
<name>Sachin</name>
<cgpa>8.8</cgpa>
</student>
<student>
<name>Sehwag</name>

<cgpa>8.9</cgpa>
</student>
<student>
<name>Yuvraj</name>
<cgpa>9.1</cgpa>
</student>
</students>
Program: XML document (Source Tree)
<?xml version="1.0" encoding="utf-8" ?>

<xsl:stylesheetversion="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="students">
<html><head><title>Style Sheet for student.xml</title></head><body>
<table border="1" align="center">
<tr style="background-color:khaki;color:blue;">
<th>REGISTER NUMBER</th>
<th>NAME</th>
<th>CGPA</th>
</tr>
<xsl:for-each select="student">
<xsl:sort select="cgpa" data-type="number" order="descending" />
<tr>
<td><xsl:value-of select="registernumber" /></td>
<td><xsl:value-of select="name" /></td>
<td><xsl:value-of select="cgpa" /></td>
</tr>
</xsl:for-each>

</table>
</body></html>
</xsl:template>
</xsl:stylesheet>
Program: XSL transformation to represent XML document as HTML Table
<xsl: template> Contains rule to apply when a specified node is
matched.
<xsl: value-of select=”expression”> Selects the value of an XML document and adds it to
the output tree of the transformation. The required
select attribute contains an XPath expression.
<xsl: for-each select=”expression”> Applies a template to every node selected by the
XPath specified by the select attribute.
<xsl: sort select=”expression”> Used as a child element of an <xsl:apply-templates>
or <xsl: for-each> element. Sorts the nodes selected
by the <xsl: apply-template> or <xsl: for-each>
element so that the nodes are processed in sorted
order.
<xsl: apply templates> Applies the templates of the XSL document to the
children of the current node.
<xsl: apply-templates
match=”expression”>
Applies the templates of the XSL document to the
children of expression. The value of the attribute
match(i.e., expression) must be an XPath expression
that specifies elements.
<xsl:iftest = “boolean-expression”> Used to perform conditional statements against the
contents of the XML document.
Table: XSL Elements

XSL for Business-to-Business (B2B) Communication
XSLT can also be used in for B2B communication—the process of exchanging data between two
different companies. Developers can leverage XML to describe the data in a vendor-independent
fashion. In the ideal case, both companies will agree upon a standard vocabulary for describing
the data using a DTD or schema. The vocabulary is composed of the XML element names used
in the XML document. However, in certain cases one of the companies might like to use a
different vocabulary. This is where XSL enters the picture.
The example in this section describes a B2B scenario between a training company, Hot Shot
Training, and a software development company, AcmeSoft. The computer training company
maintains a database for the students that have attended its courses. The training company has
developed an XML application that produces the list of students for a given class.
The management team at AcmeSoft would like to retrieve this list from the training company’s
XML application. However, once the data is retrieved, AcmeSoft would like to store the data in a
different XML format using its own XML element names.
The XML application at the training company is accessible using the HTTP protocol. The first
step is to request the XML document from the training company. In step 2, the XML document
is retrieved. In step 3, the document is transformed using the supplied XSLT style sheet. Finally,
the desired output document is produced in step 4.

<?xml version=”1.0”?>
<trainingclass>
<title>J2EE Essentials</title>
<start_date>24 Sep 2001</start_date>
<end_date>28 Sep 2001</end_date>
<location>Philadelphia, PA</location>
<student>
<first_name>Riley</first_name>
<last_name>Scott</last_name>
<email>riley@acmesoft.web</email>
</student>
<student>
<first_name>Torrance</first_name>
<last_name>Lee</last_name>
<email>torrance.lee@acmesoft.web</email>
</student>
</trainingclass>
Program: XML document used in Hot Shot Training Company
<employeelist>
<course_title>J2EE Essentials</course_title>
<course_date start=”24 Sep 2001” end=”28 Sep 2001” />
<location>Philadelphia, PA</location>
<employee>
<name>
<first>Riley</first>
<last>Scott</last>
</name>
<email>riley.scott@acmesoft.web</email>

</employee>
<employee>
<name>
<first>Torrance</first>
<last>Lee</last>
</name>
<email>torrance.lee@acmesoft.web</email>
</employee>
</employeelist>
Program: XML document used in AcmeSoft
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”
version=”1.0”>
<xsl:template match=”/trainingclass”>
<employeelist>
<course_title><xsl:value-of select=”title” /></course_title>

<course_date>
<xsl:attribute name=”start”>
<xsl:value-of select=”start_date”/>
</xsl:attribute>
<xsl:attribute name=”end”>
<xsl:value-of select=”end_date”/>
</xsl:attribute>
</course_date>
<location><xsl:value-of select=”location” /></location>

<xsl:for-each select=”student”
<employee>

<name>
<first><xsl:value-of select=”first_name”/></first>
<last><xsl:value-of select=”last_name”/></last>
</name>
<email><xsl:value-of select=”email”/></email>
</employee>
</xsl:for-each>
</employeelist>
</xsl:template>
</xsl:stylesheet>
Program: Stylesheet to transform XML document used in Hot Spot to XML document
used in AcmeSoft
XSL-FO

 XSL-FO elements use the following namespace:
http://www.w3.org/1999/XSL/Format
 The element <fo:root> is the root element for the XSL-FO document.
 An XSL-FO document is divided into two main parts:
1. One layout master set (layout-master-set), which specifies one or more page master
templates (simple-page-master) to be used in the document.
2. One or more page sequences, which contain the content of the document.
<?xml version="1.0" encoding="utf-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="hello"
page-height="11in" page-width="8.5in" margin-top="1in"
margin-bottom="1in" margin-left="1in" margin-right="1in">
<fo:region-body margin-top="1in" margin-bottom=".5in"/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="hello">
<fo:flow flow-name="xsl-region-body">
<fo:block font-size="18pt" text-align="center" font-weight="bold">
Hello World!
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>

Fig: Pagination Tree Structure
Page Master Set: <fo:layout-master-set>
A document can be composed of multiple pages, each with its own dimensions. The pagemaster
set refers to the collection of page masters.
Page Master: <fo:simple-page-master>
The page master describes the page size and layout. For example, we could use an8.5×11-inch
page or an A4 letter. The page master contains the dimensions for a page, including width,
height, and margins.
Regions
The simple-page-master FO contains region settings in the form of the following child FOs.
 <fo:region-before>
 <fo:region-after>
 <fo:region-body>
 <fo:region-start>
 <fo:region-end>

The region-before and region-after areas are commonly used for page headers andfooters. The
region-body area is the center of the page and contains the main content.The region-start and
region-end sections are commonly used for left and right sidebars,respectively.
Page Sequences: <fo:page-sequence>
 A page sequence defines a series of printed pages. Each page sequence refers to a page
master for its dimensions. The page sequence contains the actual content for the document.
 The <fo:page-sequence> element contains <fo:static-content> and <fo:flow>
elements.
 The <fo:static-content> element is used for page headers and footers. For example, we
can define a header for the company name and page number, and this information will appear
on every page.
 The <fo:flow>element contains a collection of text blocks. The <fo:flow> element is
similar to a collection of paragraphs. A body of text is defined using the <fo:block>
element.
 The <fo:block> element is a child element of <fo:flow>. The <fo:block> element
contains free-flowing text that will wrap to the next line in a document if it overflows.
Page Headers and Footers
The header is defined using the following code fragment:

<fo:static-content flow-name=”xsl-region-before”>
<fo:block text-align=”end”
font-size=”10pt”
font-family=”serif”
line-height=”14pt” >
Ez Books Catalog - page <fo:page-number/>
</fo:block>
</fo:static-content>
The footer is defined using the following code fragment:

<fo:static-content flow-name=”xsl-region-after”>
<fo:block text-align=”center”
font-size=”10pt”
font-family=”serif”
line-height=”14pt” >
Visit our website http://www.ezbooks.web
</fo:block>
</fo:static-content>
Graphics
XSL-FO also allows for the insertion of external graphic images. The graphic formatssupported
are dependent on the XSL-FO formatting engine. The Apache-FOP formatting engine supports
the popular graphics formats: GIF, JPEG, and BMP.
The following code fragment inserts the image smiley.jpg:
<fo:block text-align=”center”>
<fo:external-graphic src=”smiley.jpg” width=”200px” height=”200px”/>
</fo:block>
Tables
XSL-FO has rich support for structuring tabular data.

<fo:table>

<fo:table-column column-width=”120pt”/>
<fo:table-header>
<fo:table-row>
<fo:table-cell>
<fo:block font-weight=”bold”>Author</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block font-weight=”bold”>Title</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block font-weight=”bold”>Price (USD)</fo:block>
</fo:table-cell>
</fo:table-row>
</fo:table-header>

<fo:table-body>
<fo:table-row>
<fo:table-cell>
<fo:block>Michael Daconta</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>XML Development with Java 2</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>37.99</fo:block>
</fo:table-cell>

</fo:table-row>
</fo:table-body>
</fo:table>
Modeling Databases in XML
Need for Integrating XML and Database
With the emergence of XML as a technique for describing data, the frequently asked question is,
“How can we integrate XML with our existing relational database?” In particular, developers
need a solution to dynamically generate XML documents using information stored in databases.
XML and database integration is important because XML provides a standard technique to
describe data. By leveraging XML, a company can convert its existing corporate data into a
format that is consumable by its trading partners. XML allows the development team to define a
set of custom tags specific to its industry. A trading partner can import the XML data into its
system using the given format. The trading partner also has the option of converting the data to a
different XML format using XSLT.
XML Database Solutions
XML Database Mapping
The first type of XML database solution provides a mapping between the XML document
and the database fields. The system dynamically converts SQL result sets to XML
documents.
Fig: Mapping XML documents to database fields.

Native XML Support (Native XML database or NXD)
The second type of XML database solution actually stores the XML data in the document
in its native format. Each product uses its own proprietary serialization technique to store
the data. However, when the data is retrieved, it represents an XML document.
Fig: Native XML databases.
JAXB Solution for Modeling Databases in XML
1. Review the database schema.
2. Construct the desired XML document.
3. Define a schema for the XML document.
4. Create the JAXB binding schema.
5. Generate the JAXB classes based on the schema.
6. Develop a Data Access Object (DAO).
7. Develop a servlet for HTTP access.
Fig: The rental property application architecture.

Step 1: Review the database schema
Step 2: Construct the desired XML document
<rental_property>
<prop_id>1</prop_id>
<name>The Meadows</name>
<address>

<street>251 Eisenhower Blvd</street>
<city>Houston</city>
<state>TX</state>
<postal_code>77033</postal_code>
</address>
<square_footage>500.0</square_footage>
<bedrooms>1.0</bedrooms>
<bath>1.0</bath>
<price>600</price>
<contact>
<phone>555-555-1212</phone>
<fax>555-555-1414</fax>
</contact>
</rental_property>
Step 3: Define a schema for the XML document
<!ELEMENT rental_property_list (rental_property)*>
<!ELEMENT rental_property (prop_id, name, address, square_footage,
bedrooms, bath, price, contact)>
<!ELEMENT prop_id (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT address (street, city, state, postal_code)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT postal_code (#PCDATA)>
<!ELEMENT square_footage (#PCDATA)>
<!ELEMENT bedrooms (#PCDATA)>
<!ELEMENT bath (#PCDATA)>
<!ELEMENT price (#PCDATA)>

<!ELEMENT contact (phone, fax)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT fax (#PCDATA)>
Step 4: Create the JAXB binding schema
JAXB 1.0 binding schema files normally use the filename extension .xjs (for XML Java schema).
But JAXB 2.0 uses .xjb. JAXB uses a default binding schema that will create properties in the
Java class based on the XML element name. But we can customize the default binding schema as
follows:
Fig: Example JAXB 1.0 Customized Binding Schema (.xjs)
<jxb:bindings schemaLocation = "xs:anyURI">
<jxb:bindings node = "xs:string">*
<binding declaration>
<jxb:bindings>
</jxb:bindings>
Fig: JAXB 2.0 Customized Binding Schema (.xjb) General Form

Step 5: Generate the JAXB classes based on the schema
Using JAXB binding compiler, Java classes are generated from XSD/DTD (One or many bean
classes and ObjectFactory class).
Fig: Generating Java classes with the JAXB compiler
Using JAXB1.0
java com.sun.tools.xjc.Main rental_property.dtd rental_property.xjs -d
source_code
This command generates source code in the source_code directory. The following files are
generated:
 RentalPropertyList.java. This file models the <rental_property_list> element.
 RentalProperty.java. This file models the <rental_property> element.
 Address.java. This file models the <address> subelement.
 Contact.java. This file models the <contact> subelement.
Step 6: Develop a Data Access Object (DAO)
A Data Access Object (DAO) provides access to the backend database. The goal of the DAO
design pattern is to provide a higher level of abstraction for database access. The DAO
encapsulates the complex JDBC and SQL calls. The DAO provides access to the backend
database via public methods. The DAO converts a result set to a collection of objects. The
objects model the data stored in the database.

Fig: Data Access Object design pattern
Step 7: Develop a servlet for HTTP access
Fig: Servlet and DAO interaction
In our solution, we’ll use a servlet to handle the requests to the DAO. In the servlet, we’ll call the
appropriate method and return the result as an XML document.

UNIT III - SERVICE ORIENTED ARCHITECTURE
1.
Characteristics of SOA Thomas Erl – Ch: 3.2
2.
3. Comparing SOA with Client-Server Thomas Erl – Ch: 4.3
4.
Comparing SOA with Distributed
architectures
Thomas Erl – Ch: 4.3
5. Benefits of SOA Thomas Erl – Ch: 3.4
6.
Principles of Service orientation Thomas Erl – Ch: 8.3
7.
8.
Service layers Thomas Erl – Ch: 9.0
9.
Contents beyond syllabus CORBA, RMI, IIOP

Need for SOA
The Challenges faced by Enterprise Computing before the advent of Service Oriented
Architecture (SOA) were:
 Scalability
 Heterogeneity
 Time-to-market
 Cost
o Development
o Operation & Maintenance
The issues of Scalability and Heterogeneity were addressed by Component Based Technologies
(eg: J2EE – Open, standards based Component & Container model). But the remaining issues of
Time-to-market and Cost were not adequately addressed by Component Based Technologies.
SOA addresses all of the above mentioned issues.
Service Oriented Architecture
“Service-oriented architecture” is a term that represents a model in which automation logic is
decomposed into smaller, distinct units of logic known as services. This model should adhere to
the principles of service-orientation like loose coupling, autonomy, reusability, composability,
statelessness, discoverability, abstraction etc.
Service
It is a unit of processing logic. Collectively, these units comprise a larger piece of business
automation logic. Individually, these units can be distributed.
Primitive SOA

It is baseline technology architecture, whose core components are services, descriptions, and
messages. It supports the basic service oriented principles.
What is architecture?
 A baseline application that could act as a template for all other applications.
 It specifically explains the technology, boundaries, rules, limitations, and design
characteristics that apply to all solutions based on this template.
Application Architecture
 It is a technical blueprint for providing solutions.
 An organization can have several application architectures.
Enterprise Architecture
 It is a master specification providing high-level overview of all forms of heterogeneity
that exist within an enterprise. It also contains definition of the supporting architecture.
 Any changes to enterprise architecture directly affect application architectures.

Characteristics of SOA
Contemporary SOA
It extends primitive SOA through application of advanced design techniques and new Web
services specifications.
Contemporary SOA represents an open, agile, extensible, federated, composable architecture
comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and
potentially reusable services, implemented as Web services.
Observational Characteristics
 Contemporary SOA is at the core of the service-oriented computing platform
The term “architecture” refers to any application computing platform. Contemporary
SOA represents an architecture that promotes service-orientation through the use of web
services.
 Contemporary SOA is a building block
Organizations standardizing on SOA work toward an ideal known as the service-oriented
enterprise (SOE), where all business processes are composed of and exist as services,
both logically and physically. In this scenario an individual service-oriented application
can, in its entirety, be represented by and modeled as a single service.
 Contemporary SOA is an evolution
It differs from traditional client-server and distributed environments in that it is heavily
influenced by the concepts and principles associated with service-orientation and Web
services. It is similar to previous platforms in that it preserves the successful
characteristics of its predecessors and builds upon them with distinct design patterns and
a new technology set. For example, SOA supports and promotes reuse, as well as the
componentization and distribution of application logic.
 Contemporary SOA is still maturing
Despite the fact that Web services are being used to implement a great deal of application
functionality, the support for a number of features necessary for enterprise-level
computing is not yet fully available.

When SOA platforms and tools reach an adequate level of maturity, the utilization of
Web services can be extended to support the creation of enterprise SOA solutions.
 Contemporary SOA is an achievable ideal
A standardized enterprise-wide adoption of SOA requires an enormous amount of effort,
discipline, and a good amount of time. It is a transition phase now, where various parts of
SOA will be phased in at different stages and to varying extents. This will likely result in
countless hybrid architectures, consisting mostly of distributed environments that are part
legacy and part service-oriented. The advancements in technology set will help in
realizing enterprise-level SOAs.
Concrete Characteristics
 Contemporary SOA increases quality of service
Common quality of service requirements:
Security: Protecting the contents of a message, as well as access to individual services.
Reliability: Guaranteeing message delivery or notification of failed delivery.
Performance: Ensuring that the overhead imposed by SOAP message and XML content
processing does not inhibit the execution of a task.
Transaction: Protecting the integrity of specific business tasks with a guarantee that
should the task fail, exception logic is executed.
WS-* Extensions provide features that directly address the quality of
service requirements.
 Contemporary SOA is fundamentally autonomous
Services are autonomous. Messages are autonomous. SOA builds upon and expands this
principle by promoting the concept of autonomy throughout solution environments and
the enterprise.
 Contemporary SOA is based on open standards
Data exchange is governed by open standards. The message itself is standardized, both in
format and in how it represents its payload. The use of SOAP, WSDL, XML, and XML
Schema allow for messages to be fully self-contained and support the underlying
agreement that to communicate, services require nothing more than knowledge of each
other's service descriptions. The use of an open, standardized messaging model

eliminates the need for underlying service logic to share type systems and supports the
loosely coupled paradigm.
An SOA limits the role of proprietary technology to the implementation and hosting of
the application logic encapsulated by a service.
 Contemporary SOA supports vendor diversity
Disparate technology platforms do not prevent service-oriented solutions from
interoperating.
 Contemporary SOA fosters intrinsic interoperability
Intrinsically interoperable services enable unforeseen integration opportunities.
Promoting this characteristic can significantly alleviate the cost and effort of fulfilling
future cross-application integration requirements.
 Contemporary SOA promotes discovery
SOA supports and encourages the advertisement and discovery of services throughout the
enterprise and beyond. A serious SOA will likely rely on some form of service registry or
directory to manage service descriptions. UDDI is the Web services registry standard.
 Contemporary SOA promotes federation
While Web services enable federation, SOA promotes this cause by establishing and
standardizing the ability to encapsulate legacy and non-legacy application logic and by
exposing it via a common, open, and standardized communications framework.

 Contemporary SOA promotes architectural composability
Composability is a deep-rooted characteristic of SOA that can be realized on different
levels. The WS-* platform allows for the creation of streamlined and optimized service-
oriented architectures, applications, services, and even messages.
 Contemporary SOA fosters inherent reusability
SOA establishes an environment that promotes reuse on many levels. Collections of
services that form service compositions can themselves be reused by larger compositions.
 Contemporary SOA emphasizes extensibility
The scope of functionality offered by a service can sometimes be extended without
breaking the established interface. Extensibility is also a characteristic that is promoted
throughout SOA as a whole. Extending entire solutions can be accomplished by adding
services or by merging with other service-oriented applications. Because of loosely
coupling, extending logic can be achieved with significantly less impact.
 Contemporary SOA supports a service-oriented business modeling paradigm
Services can be designed to express business logic. BPM models, entity models, and
other forms of business intelligence can be accurately represented through the
coordinated composition of business-centric services.
 Contemporary SOA implements layers of abstraction
Typical SOAs can introduce layers of abstraction by positioning services as the sole
access points to a variety of resources and processing logic. Abstraction can be targeted
at business and application logic. Application logic created with proprietary technology
can be abstracted through a dedicated service layer.
 Contemporary SOA promotes loose coupling throughout the enterprise
Through the implementation of service layers that abstract business and application logic,
the loose coupling paradigm can be applied to the enterprise as a whole.
 Contemporary SOA promotes organizational agility
Agility is the ability to respond and adapt to business or technology-related change. A
loosely coupled relationship between business and application technology allows each
end to more efficiently respond to changes in the other.

Comparing SOA with Client-Server and Distributed Architectures

SOA vs Client-Server Architecture
Client-Server Architecture SOA
Application
Logic
 Client-software contains the
application logic.
 Presentation layer designs are
completely open and specific to a
solution’s requirements.
 Processing logic is partitioned into
autonomous units. This facilitates
service statelessness,
interoperability, composability and
reusability.
Application
Processing
 Client workstation is
responsible for the bulk of the
processing.
 Databases do 20% of work.
 Database connections are
expensive and the resource
demands overwhelm the
database servers.
 Client-side executables are
fully stateful and consume
more memory.
 Processing in SOA is highly
distributed with multiple servers.
 Because of self-governing nature of
messages, they are stateless and
hence reduce the need for caching
state information.
Technology
 Front End: 4GL languages like
VB & PowerBuilder and also
3GL like C++ also used.
 Back End: Oracle, Informix,
IBM, Sybase and Microsoft
RDBMSs.
 Newer versions of old
programming languages like VB
can be used to create Web services
& RDBMSs are still used.
 Standard set of Web technologies
(HTML, CSS, HTTP, etc.), XML
data representation architecture,
SOAP messaging framework and

ever expanding Web services
platform.
Security
 Security is simple.
 Databases present in the server
are sufficiently sophisticated to
manage user accounts.
 Clients also had security
measures for the execution of
application logic.
 Operating system level
security for achieving single
sign-on.
 Security is complex.
 Uses WS-Security Framework
Administration
 Updating application present
in each client required a
redistribution of the client s/w
to all the workstations.
 Ever increasing demands on
the server side database
because of increasing clients.
 SOA accommodate scalability for
application and database server.
 Still powerful administrative tools
may be required in future for
management of server resources &
service interfaces.

SOA vs Distributed Internet Architecture
Distributed Internet Architecture SOA
Application
Logic
 Distributed Internet applications
place all of their application
logic on the server side.
Individual units of logic are
components.
 SOA too place all of their
application logic on the server
side. Individual units of logic are
services.
 Components are tightly-coupled
(at design time).
 Services (made up of Components)
are loosely coupled.
 Traditional components provide
methods that, once invoked,
send and receive parameter data.
Eg: RPC, CORBA, RMI
 Even though SOAP supports RPC-
style message structures, the
majority of service-oriented Web
service designs rely on document-
style messages.
 It promotes reuse.
 It promotes reuse and cross-
application interoperability on a
deep level by promoting the
creation of solution-agnostic
services.
Application
Processing
 Processing of RPC
communication is relatively
faster.
 Message-based communication
supported by SOA incurs more
processing overheads and hence
relatively slower.
 But asynchronous communication
minimizes frequent
communication and thus optimizes
processing. Statelessness of
services also optimizes processing.

Technology
 Initial architectures consisted of
components, server-side scripts,
and raw Web technologies, such
as HTML and HTTP.
 XML and Web Services are
optional. They gave data
representation which allowed to
cross proprietary platform
boundaries.
 Since contemporary SOA is built
upon XML data representation and
Web Services technology platform,
XML and Web Services are must.
Security
 It followed approaches such as
delegation and impersonation.
Encryption also is added to the
otherwise wide open HTTP
protocol to allow data to be
protected during transmission
beyond the Web server.
 The security models (WS-Security
framework) used within SOA
emphasizes the placement of
security logic onto the messaging
level. SOAP messages provide
header blocks in which security
logic can be stored.
Administration
 Maintaining component-based
applications involves keeping
track of individual component
instances, tracing local and
remote communication
problems, monitoring server
resource demands, and, of
course, the standard database
administration tasks. Web server
farms are created to address the
requirements of scalability.
 Problems with RPC- based data
exchanges are comparatively
easy to detect.
 Private registries (repositories) are
needed to access service
descriptions of each of the large
number of services.
 Problems with messaging
frameworks can more easily go
undetected than with RPC-based
data exchanges.
 Exception handling during failures
in message exchange is complex
and less robust. WS-* extensions
are able to address this problem to
an extent.

Benefits of SOA
Improved integration (and intrinsic interoperability)
SOA can result in the creation of solutions that consist of inherently interoperable services.
Utilizing solutions based on interoperable services is part of service-oriented integration (SOI)
and results in a service-oriented integration architecture.
Because of the vendor-neutral communications framework established by Web services-driven
SOAs, the potential is there for enterprises to implement highly standardized service descriptions
and message structures. The net result is intrinsic interoperability, which turns a cross-
application integration project into less of a custom development effort, and more of a modeling
exercise.
The bottom line: The cost and effort of cross-application integration is significantly lowered
when applications being integrated are SOA-compliant.
Inherent reuse
Service-orientation promotes the design of services that are inherently reusable. Designing
services to support reuse from the get-go opens the door to increased opportunities for leveraging
existing automation logic.
Building service-oriented solutions in such a manner that services fulfill immediate application-
level requirements while still supporting a degree of reuse by future potential requestors
establishes an environment wherein investments into existing systems can potentially be
leveraged and re-leveraged as new solutions are built.
The bottom line: Building services to be inherently reusable results in a moderately increased
development effort and requires the use of design standards. Subsequently leveraging reuse
within services lowers the cost and effort of building service-oriented solutions.
 Exception handling during
failures in RPC communication
is comparatively easier.

Streamlined architectures and solutions
The concept of composition is another fundamental part of SOA. It is not, however, limited to
the assembly of service collections into aggregate services. The WS-* platform is based in its
entirety on the principle of composability.
This aspect of service-oriented architecture can lead to highly optimized automation
environments, where only the technologies required actually become part of the architecture.
The bottom line: Realizing this benefit requires adherence to design standards that govern
allowable extensions within each application environment. Benefits of streamlined solutions and
architectures include the potential for reduced processing overhead and reduced skill-set
requirements.
Leveraging the legacy investment
The industry-wide acceptance of the Web services technology set has spawned a large adapter
market, enabling many legacy environments to participate in service-oriented integration
architectures. Previously isolated environments now can interoperate without requiring the
development of expensive and sometimes fragile point-to-point integration channels.
Though still riddled with risks relating mostly to how legacy back-ends must cope with increased
usage volumes, the ability to use what you already have with service-oriented solutions that you
are building now and in the future is extremely attractive.
The bottom line: The cost and effort of integrating legacy and contemporary solutions is
lowered. The need for legacy systems to be replaced is potentially lessened.
Establishing standardized XML data representation
On its most fundamental level, SOA is built upon and driven by XML. As a result, an adoption
of SOA leads to the opportunity to fully leverage the XML data representation platform. A
standardized data representation format (once fully established) can reduce the underlying
complexity of all affected application environments.
Examples include:
 XML documents and accompanying XML Schemas (packaged within SOAP messages)
passed between applications or application components fully standardize format and

typing of all data communicated. The result is a predictable and therefore easily
extensible and adaptable communications network.
 XML's self-descriptive nature enhances the ability for data to be readily interpreted by
architects, analysts, and developers. The result is the potential for data within messages to
be more easily maintained, traced, and understood.
 The standardization level of data representation lays the groundwork for intrinsic
interoperability. Specifically, by promoting the use of standardized vocabularies, the need
to translate discrepancies between how respective applications have interpreted corporate
data models is reduced.
The bottom line: The cost and effort of application development is reduced after a proliferation
of standardized XML data representation is achieved.
Focused investment on communications infrastructure
Because Web services establish a common communications framework, SOA can centralize
inter-application and intra-application communication as part of standard IT infrastructure. This
allows organizations to evolve enterprise-wide infrastructure by investing in a single technology
set responsible for communication.
The bottom line: The cost of scaling communications infrastructure is reduced, as only one
communications technology is required to support the federated part of the enterprise.
"Best-of-breed" alternatives
Some of the harshest criticisms laid against IT departments are related to the restrictions imposed
by a given technology platform on its ability to fulfill the automation requirements of an
organization's business areas. This can be due to the expense and effort required to realize the
requested automation, or it may be the result of limitations inherent within the technology itself.
Either way, IT departments are frequently required to push back and limit or even reject requests
to alter or expand upon existing automation solutions.
SOA won't solve these problems entirely, but it is expected to increase empowerment of both
business and IT communities. A key feature of service-oriented enterprise environments is the
support of "best-of-breed" technology. Because SOA establishes a vendor-neutral
communications framework, it frees IT departments from being chained to a single proprietary

development and/or middleware platform. For any given piece of automation that can expose an
adequate service interface, you now have a choice as to how you want to build the service that
implements it.
The bottom line: The potential scope of business requirement fulfillment increases, as does the
quality of business automation.
Organizational agility
Much of service-orientation is based on the assumption that what you build today will evolve
over time. One of the primary benefits of a well-designed SOA is to protect organizations from
the impact of this evolution. When accommodating change becomes the norm in distributed
solution design, qualities such as reuse and interoperability become commonplace.
Change can be disruptive, expensive, and potentially damaging to inflexible IT environments.
Building automation solutions and supporting infrastructure with the anticipation of change
seems to make a great deal of sense. A standardized technical environment comprised of loosely
coupled, composable, and interoperable and potentially reusable services establishes a more
adaptive automation environment that empowers IT departments to more easily adjust to change.
Further, by abstracting business logic and technology into specialized service layers, SOA can
establish a loosely coupled relationship between these two enterprise domains. This allows each
domain to evolve independently and adapt to changes imposed by the other, as required.
The bottom line: The cost and effort to respond and adapt to business or technology-related
change is reduced.
Anatomy of SOA
Logical components of the Web services framework
 Web service contains one or more operations.
 Each operation governs the processing of a specific function the Web service is capable
of performing.

Fig: Web Service
 The processing consists of sending and receiving SOAP messages
Fig: Operation
 By composing these parts, Web services form an activity through which they can
collectively automate a task.

Logical components of automation logic
Fundamental parts of the Web Service framework and Corresponding components in SOA:
 SOAP messages => messages
 Web service operations => operations
 Web services => services
 Activities => processes (and process instances)
Automation logic is comprised of the four identified parts. We can further qualify these parts by
relating each to different sized units of logic, as follows:
 messages = units of communication
 operations = units of work
 services = units of processing logic (collections of units of work)
 processes = units of automation logic (coordinated aggregation of units of work)

Components of an SOA
 A message represents the data required to complete some or all parts of a unit of work.
 An operation represents the logic required to process messages in order to complete a unit
of work.
 A service represents a logically grouped set of operations capable of performing
related units of work.
 A process contains the business rules that determine which service operations are used to
complete a unit of automation. In other words, a process represents a large piece of work
that requires the completion of smaller units of work.
How components in an SOA inter-relate
 An operation sends and receives messages to perform work.
 An operation is therefore mostly defined by the message it processes.
 A service groups is a collection of related operations.
 A service is therefore mostly defined by the operations that comprise it.
 A process instance can compose service.
 A process instance is not necessarily defined by its service because it may only require a
subset of the functionality offered by the services.
 A process instance invokes a unique series of operations to complete its automation.
 Every process instance is therefore partially defined by the service operation it uses.

Fig: How the components of a service-oriented architecture relate
Fig: How the components of a service-oriented architecture define each other
Principles of Service Orientation
1. Services are reusable
2. Services share a formal contract
3. Services are loosely coupled
4. Services abstract underlying logic
5. Services are composable
6. Services are autonomous
7. Services are stateless
8. Services are discoverable
Services are reusable
 Reusable services are able to accommodate future requirements with less development
effort.
 Inherently reusable services also reduce the need for creating wrapper services that
expose a generic interface over top of less reusable services.
 This principle facilitates all forms of reuse, including inter-application interoperability,
composition, and the creation of cross-cutting or utility services.

 Since a service is simply a collection of related operations, the logic encapsulated by the
individual operations that must be deemed reusable to warrant representation as a
reusable service
 Messaging also indirectly supports service reusability through the use of SOAP headers.
Services 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
It establishes the agreement made by a service provider and its service requestors.
Services are loosely coupled
Agility is directly supported by establishing a loosely coupled relationship between services.
Loose coupling is a condition wherein a service acquires knowledge of another service while still
remaining independent of that service. Loose coupling is achieved through the use of service
contracts that allow services to interact within predefined parameters.
Agility: It is the ability of a business to adapt rapidly and cost efficiently in response to changes
in the business and technology environments.

Services abstract underlying logic
Also referred to as service interface-level abstraction, it is this principle that allows services to
act as black boxes, hiding their details from the outside world. There is no limit to the amount of
logic a service can represent.
Operation granularity is a primary design consideration that is directly related to the range and
nature of functionality being exposed by the service. Again, it is the individual operations that
collectively abstract the underlying logic. Services simply act as containers for these operations.
Services are composable
A service can represent any range of logic from any types of sources, including other services. A
common SOA extension that underlines composability is the concept of orchestration. Here, a
service-oriented process is controlled by a parent process service that composes process
participants. Composability is simply another form of reuse, and therefore operations need to be
designed in a standardized manner and with an appropriate level of granularity to maximize
composition opportunities.
Fig: The UpdateEverything operation encapsulating a service composition.
Services are autonomous
Autonomy requires that the range of logic exposed by a service exist within an explicit boundary.
This allows the service to execute self-governance of all its processing. It also eliminates

dependencies on other services, which frees a service from ties that could inhibit its deployment
and evolution. Service autonomy is a primary consideration when deciding how application logic
should be divided up into services and which operations should be grouped together within a
service context.
There are two types of autonomy:
 Service-level autonomy: Service boundaries are distinct from each other, but the service
may share underlying resources.
 Pure autonomy: The underlying logic is under complete control and ownership of the
service.
Services are stateless
Services should minimize the amount of state information they manage and the duration for
which they hold it. State information is data-specific to a current activity. While a service is
processing a message, for example, it is temporarily stateful. If a service is responsible for
retaining state for longer periods of time, its ability to remain available to other requestors will
be impeded.
Statelessness is a preferred condition for services and one that promotes reusability and
scalability. A primary quality of SOA that supports statelessness is the use of document-style
messages. The more intelligence added to a message, the more independent and self-sufficient it
remains.

Fig: 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 that implement
redundant logic. Metadata attached to a service needs to sufficiently describe not only the
service's overall purpose, but also the functionality offered by its operations.
Note that this service-orientation principle is related to but distinct from the contemporary SOA
characteristic of discoverability. On an SOA level, discoverability refers to the architecture's
ability to provide a discovery mechanism, such as a service registry or directory. On a service
level, the principle of discoverability refers to the design of an individual service so that it can be
as discoverable as possible.

Service Layers
In enterprise model, the service interface layer is located between the business process and
application layers.
Business logic is a documented implementation of the business requirements that originate from
an enterprise's business areas. Business logic is generally structured into processes that express
these requirements, along with any associated constraints, dependencies, and outside influences.
Application logic is an automated implementation of business logic organized into various
technology solutions. Application logic expresses business process workflows through purchased
or custom-developed systems within the confines of an organization's IT infrastructure, security
constraints, technical capabilities, and vendor dependencies.
Problems solved by layering services
 What logic should be represented by services?
 How should services relate to existing application logic?
 How can services best represent business logic?
 How can services be built and positioned to promote agility?

What logic should be represented by services?
 The enterprise logic can be divided into two primary domains: business logic and
application logic.
 Services can be modeled to represent either or both types of logic, as long as the
principles of service-orientation can be applied.
 To achieve enterprise-wide loose coupling physically separate layers of services are, in
fact, required. Each domain of the enterprise is freed of direct dependencies on the other.
 This allows the automated representation of business process logic to evolve
independently from the technology-level application logic responsible for its execution.
In other words, this establishes a loosely coupled relationship between business and
application logic.
How should services relate to existing application logic?
 Much of this depends on whether existing legacy application logic needs to be exposed
via services or whether new logic is being developed in support of services.
 Applying a service layer on top of legacy application environments may even require that
some service-orientation principles be compromised.
 This is less likely when building solutions from the ground up with service layers in
mind.
 Services designed specifically to represent application logic should exist in a separate
layer and it is known as application service layer.
How can services best represent business logic?
 Business logic is defined within an organization's business models and business
processes. When modeling services to represent business logic, it is most important to
ensure that the service representation of this logic is in alignment with existing business
models.
 These services representing business logic are known as Business Service and belong to
the business service layer. Business service layer supports service-oriented business
modeling.

How can services be built and positioned to promote agility?
 The key to building an agile SOA is in minimizing the dependencies each service has
within its own processing logic.
 Introducing a parent controller layer on top of more specialized service layers would
allow us to establish a centralized location for business rules and composition logic
related to the sequence in which services are executed. Orchestration is designed
specifically for this purpose. It introduces the concept of a process service, capable of
composing other services to complete a business process according to predefined
workflow logic. Process services establish the orchestration service layer.
 Service abstraction, having separate application, business, and orchestration layers,
contributes to establishing an agile enterprise.
The three layers of abstraction identified for SOA are:
the application service layer
the business service layer
the orchestration service layer
Fig: The three primary service layers.

Application Service Layer
Application services commonly have the following characteristics:
 they expose functionality within a specific processing context
 they draw upon available resources within a given platform
 they are solution- agnostic
 they are generic and reusable
 they can be used to achieve point-to-point integration with other application services
 they are often inconsistent in terms of the interface granularity they expose
 they may consist of a mixture of custom-developed services and third-party services that
have been purchased or leased
The different types of Application Services are:
Utility service
Any generic service designed for potential reuse can be classified as a utility service. The
key to achieving this classification is that the reusable functionality be completely generic
and non-application specific in nature.
(eg) Load Balancing Service, Internal Policy Service, System Notification Service
Wrapper service
They consist of services that encapsulate ("wrap") some or all parts of a legacy
environment to expose legacy functionality to service requestors. The most frequent form
of wrapper service is a service adapter provided by legacy vendors.
Integration service
An application service also can compose other, smaller-grained application services (such
as proxy services) into a unit of coarse-grained application logic. Application services
that exist solely to enable integration between systems often are referred to as application
integration services or simply integration services. Integration services often are
implemented as controllers.
Hybrid Service
Services that contain both application and business logic can be referred to as hybrid
application services or just hybrid services. This service model is commonly found within
traditional distributed architectures.

Business Service Layer
The business service layer introduces a service concerned solely with representing business
logic, called the business service.
A business service also can be a controller service and a utility service. In fact, when application
logic is abstracted into a separate application service layer, it is more than likely that business
services will act as controllers to compose available application services to execute their business
logic.
Business service layer abstraction leads to the creation of two further business service models:
Task-centric business service: A service that encapsulates business logic specific to a
task or business process. This type of service generally is required when business process
logic is not centralized as part of an orchestration layer. Task-centric business services
have limited reuse potential.
Entity-centric business service: A service that encapsulates a specific business entity
(such as an invoice or timesheet). Entity-centric services are useful for creating highly
reusable and business process- agnostic services that are composed by an orchestration
layer or by a service layer consisting of task-centric business services (or both).
Example: Accounts Payable Service, Purchase Order Service, Ledger Service, Vendor Profile
Service
Orchestration Service Layer
 The orchestration service layer consists of one or more process services that compose
business and application services according to business rules and business logic
embedded within process definitions.
 Orchestration abstracts business rules and service execution sequence logic from other
services, promoting agility and reusability.
 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).

UNIT IV - WEB SERVICES
1.
Service descriptions – WSDL Thomas Erl - Chapter 5.3
2.
3. Messaging with SOAP Thomas Erl - Chapter 5.4
4. Service discovery – UDDI Thomas Erl - Chapter 5.3
5. Message Exchange Patterns Thomas Erl - Chapter 6.1
6. Orchestration Thomas Erl - Chapter 6.6
7. Choreography Thomas Erl - Chapter 6.7
8.
WS Transactions Thomas Erl - Chapter 6.3, 6.4, 6.5
9.
Contents beyond syllabus REST

Web Services
A Web service is a software designed to support interoperable machine-to-machine
interaction over a network. It has an interface described in a machine-processable format
(specifically WSDL). Other systems interact with the Web service in a manner prescribed by
its description using SOAP messages.
 Web applications are meant for application to human communication
It uses HTML & Browsers.
 Web services are for program to program communication
It is based on XML & uses XML Technologies (SOAP, WSDL, UDDI).
They also use Internet Protocols.
Fig: Core Web Service Standards
Service Roles (Temporary Classification of Web Services)
It is based on the roles it assumes during the runtime processing of a message
Service Requestor (Message Initiator)
Intermediary Service (Message Relayer)
Service Provider (Message recipient)
Service Composition Member

Service Provider
• It is comparable to that of server in traditional distributed architecture.
• A Service is a provider under the following conditions:
– The service is invoked via an External source, such as service requestor.
– The service provides a published service description offering information
about its features and behavior.
• Service Provider entity – the organization providing the Web service
• Service Provider agent – the Web service itself, acting as an agent of the entity
Service Requestor
• It is comparable to that of client in traditional distributed architecture. Any unit of
logic that issues a request message that is understood by a service provider.
• A Web service takes on the service requestor role when:
– Web service invokes a service provider by sending it a message
– The Web service searches for and accesses the most suitable service provided
by examining available service descriptions
• Service requestor entity – the organization of individual requesting the service
• Service requestor agent – the Web service itself, acting as an agent of the entity
Sometime service requestors are referred to as “service consumer”
Note: Same service can be a requestor and a provider in different message exchanges.
Fig: Service Provider (As the recipient of a request message)

Fig: Service Requestor (As the sender of the request message)
Intermediaries
• Web service communications uses point-to-* paths. Messages can be processed by
multiple intermediate routing and processing agents before arriving at destination
• Services and Agents that do this are intermediaries
• Passive intermediary simply routes without modifying the message
• Active intermediary process and alter message contents before routing the message
Fig: Passive Intermediary

Fig: Active Intermediary Service
Initial Sender
• Initial senders are simply service requestors that initiate the transmission of a
message. They are the first web service in a message path.
Ultimate Receiver
• Ultimate Receiver is the last web service along a message path.
Service Compositions
Any service can enlist one or more additional services to complete a given task. Further, any
of the enlisted services can call other services to complete a given sub-task. Therefore, each
service that participates in a composition assumes an individual role of service composition
member.
Fig: A service composition consisting of four members

Service Models (Permanent Classification of Web Services)
It is based on the roles it assumes during the runtime processing of a message.
Business Service Model
Utility Service Model
Controller Service Model
Business Service Model
• It encapsulates a distinct set of business logic.
• It is ideally autonomous (but can participate in compositions).
• Business Services are used within SOAs as:
– As fundamental building blocks for the representation of business logic
– To represent a corporate entity or information set
– To represent business process logic
– As service composition members
Utility Service Model
• It provides generic functionality usually not associated with business logic.
• Utility services are used within SOAs as:
– As services that enable characteristic reuse within SOA
– As solution-agnostic intermediary services
– As services that promote intrinsic interoperability
– As the services with the highest degree of autonomy
Controller Service Model
• It assembles and coordinates other services to supply a business function.
• It acts as a parent service to service composition members.
• It is used within SOAs as:
– To support and implement the principle of composability
– To leverage reuse opportunities
– To support autonomy in other services

SERVICE DESCRIPTIONS
Service Descriptions
Service descriptions describes list of operations (and their specifications) supported by the
web service, the input message accepted by the service and the output message returned by
the service. It also describes the location of the web service. The primary service description
document is WSDL (Web Service Description Language).
Fig: WSDL definitions enable loose coupling between services
Service Endpoints and Descriptions
A WSDL describes the point of contact for a service provider, also known as the service
endpoint or just endpoint. It provides a formal definition of the endpoint interface (so that
requestors wishing to communicate with the service provider know exactly how to structure
request messages) and also establishes the physical location (address) of the service.
A WSDL service description (also known as WSDL service definition or just WSDL
definition) can be separated into two categories:
abstract description
concrete description
WSDL Abstract Description
It defines the interface characteristics of web service.
Three main parts:
 portType (or interface) – It provides a high-level view of service interface. Sorts
messages into groups of functions called operations.

 Operation – It is a specific action performed by the service. (Similar to public
method for components in traditional distributed applications).
 Message – The parameters are represented as messages. An operation consists of a
set of input and output messages.
Fig: WSDL Definition
WSDL Concrete Description
The concrete description defines the transport and location information of the web service.
The physical transport protocol is described in three parts:
• Binding – A binding represents one possible transport technology the service can use
to communicate. SOAP is the most common form of binding, but others also are
supported.
• Port (or endpoint)– It represents physical address for the service
• Service – The service represents a group of related ports or endpoints.
Metadata and Service Contracts
• WSDL definitions usually rely on XSD schemas to formalize the structure of
messages. Policies provide rules, preferences, and processing details beyond what is
expressed in the WSDL and schema.

• The three service description documents WSDL Definition, XSD Schema and Policy
can be classified as service metadata. A service contract is comprised of a collection
of service descriptions and possibly additional documents.
Semantic Descriptions
• Most metadata focuses on technical information regarding data representation and
processing requirements. Semantic descriptions refer to service’s behavioral
characteristics.
• Examples of service semantics include:
– How a service behaves under certain conditions
– How a service will respond to a specific condition
– What specific tasks the service is best suited for
Description Advertisement and Discovery
• Advertisement refers to publishing service description by a service provider in
registry. Discovery refers to finding suitable service description by a service requestor
in registry. UDDI formed the first generation of Web service standard for registry or
directory.
• Central directories and registries allow humans and service requestors to:
– Locate the latest versions of known service descriptions
– Discover new Web services

Registries
• Public – They accept registrations from any organizations with or without Web
services.
• Private – It can be implemented within an organization to provide a central repository
for descriptions of all services the organization develops, leases, or purchases.
UDDI Components
• Business Entities: It contains the descriptive information about the organization (or
service provider entity) and about list of services it offers. This would include
information such as names and descriptions in multiple languages, contact
information and classification information.
• Business services: The business service structure represents an individual web
service provided by the business entity.
• Binding Templates: It provides the technical information needed by applications to
bind and interact with the Web service being described. It must contain either the
access point for a given service or an indirection mechanism that will lead one to the
access point.
• tModels (Technical Model): It is used to represent unique concepts or constructs.
Each distinct specification, transport, protocol or namespace is represented by a
tModel. It contains addresses (URLs) and metadata about the technical documents.

MESSAGING WITH SOAP
The SOAP specification is universally accepted as the standard transport protocol for
messages processed by Web services. The SOAP messaging framework fulfills the need for
SOA's reliance on "independent units of communication," by supporting the creation of
intelligence-heavy, document-style, and highly extensible messages.
SOAP
It originally stood for Simple Object Access Protocol. Now SOAP is a standalone term.
The main parts of SOAP are:
Envelope: It is a container housing all parts of the message.
Header: It contains metadata.
Body: It contains the actual message contents (also referred to as the message
payload). They are XML formatted data.
Fig: Basic Structure of SOAP Message
Header Blocks
• Header blocks outfit a message with information needed by all the services which
process the message.
• This relieves services from having to store message-specific logic.
• Almost all WS-* extensions are implemented with header blocks
Examples of message features outfitted with using header block:

• Processing instructions that may be executed by service intermediaries or ultimate
receiver.
• Routing or workflow information.
• Security measures implemented in the message.
• Reliability rules related to the delivery of the message.
• Context and transaction management information.
• Correlation information to associate request and response messages.
Message Styles
Two messaging styles are supported by SOAP. They are:
 RPC-style Messages: The RPC calls between distributed components are serialized
into XML documents, transported, and then deserialized into the native component
format upon arrival. It is synchronous and tightly-coupled.
 Document-style Messages: SOA relies on document-style messages to enable larger
payloads, coarser interface operations, and reduced message transmission volumes
between services. It is asynchronous and loosely-coupled.
Attachments
To facilitate requirements for the delivery of data not so easily formatted into an XML
document, the use of SOAP attachment technologies exist. Each provides a different
encoding mechanism used to bundle data in its native format with a SOAP message. SOAP
attachments are commonly employed to transport binary files, such as images.
Faults
Finally, SOAP messages offer the ability to add exception handling logic by providing an
optional fault section that can reside within the body area. The typical use for this section is
to store a simple message used to deliver error condition information when an exception
occurs.
Nodes
• Programs that services use to transmit and send SOAP messages are SOAP nodes
• SOAP nodes must conform to SOAP specification, as a result SOAP messages are
vendor-neutral

Node Types
• SOAP sender – a SOAP node that transmits a message
• SOAP receiver – a SOAP node that receives a message
• SOAP intermediary – a SOAP node that receives and transmits a message with
optional processing
• Initial SOAP sender – the first SOAP node to transmit the message
• Ultimate SOAP receiver – the last SOAP node to receive a message
SOAP Intermediaries
Forwarding intermediary: It is responsible for relaying the contents of a message to a
subsequent SOAP node.
Active intermediary: It is distinguished by the type of processing they perform above and
beyond forwarding-related functions. It can alter existing header blocks, insert new ones, and
execute a variety of supporting actions.
Fig: Different types of SOAP nodes involved with processing a message.
Message Paths
 A message path refers to the route taken by a message from when it is first sent until it
arrives at its ultimate destination. Therefore, a message path consists of at least one
initial sender, one ultimate receiver, and zero or more intermediaries.

 Design considerations relating to the path a message is required to travel often center
around performance, security, context management, and reliable messaging concerns.
 Note also that a message path is sometimes not predetermined. The use of header
blocks processed by intermediaries can dynamically determine the path of a message.
This may be the result of routing logic, workflow logic, or environmental conditions.
Fig: A message path consisting of three Web services.
Coarse grained Operations
–Large documents representing entire business events or business objects
–e.g. CRUD operations: CreateOrder, ReadOrder, UpdateOrder, DeleteOrder
–NOT operations such as SetPrice(), SetProduct(), SetCustomer(), CompleteOrder()

SERVICE DISCOVERY - UDDI
The Universal Description, Discovery, and Integration (UDDI) protocol is a central element
of the group of related standards that comprise the Web services stack. The UDDI
specification defines a standard method for publishing and discovering the network-based
software components of a service-oriented architecture (SOA).
A UDDI registry’s functional purpose is the representation of data and metadata about Web
services. A registry, either for use on a public network or within an organization’s internal
infrastructure, offers a standards-based mechanism to classify, catalog, and manage Web
services, so that they can be discovered and consumed by other applications.
Description Advertisement and Discovery
• Advertisement refers to publishing service description by a service provider in
registry. Discovery refers to finding suitable service description by a service requestor
in registry. UDDI formed the first generation of Web service standard for registry or
directory.
• Central directories and registries allow humans and service requestors to:
– Locate the latest versions of known service descriptions
– Discover new Web services

Registries
• Public – They accept registrations from any organizations with or without Web
services.
• Private – It can be implemented within an organization to provide a central repository
for descriptions of all services the organization develops, leases, or purchases.
UDDI Components
• Business Entities: It contains the descriptive information about the organization (or
service provider entity) and about list of services it offers. This would include
information such as names and descriptions in multiple languages, contact
information and classification information.
• Business services: The business service structure represents an individual web
service provided by the business entity.
• Binding Templates: It provides the technical information needed by applications to
bind and interact with the Web service being described. It must contain either the
access point for a given service or an indirection mechanism that will lead one to the
access point.
• tModels (Technical Model): It is used to represent unique concepts or constructs.
Each distinct specification, transport, protocol or namespace is represented by a
tModel. It contains addresses (URLs) and metadata about the technical documents.

Defining UDDI Nodes, Registries, and Affiliated Registries
The UDDI specification includes a specific definition of the hierarchical relationship between
a single instance of a UDDI implementation and others to which it is related.
Technically, there are three major classifications of UDDI servers:
 A node is a UDDI server that supports at least the minimum set of functionality
defined in the specification. It may perform one or more functions on the UDDI data
to which it has access. It is a member of exactly one UDDI registry.
 A registry is composed of one or more nodes. A registry performs the complete set of
functionality as defined in the specification.
 Affiliated Registries are individual UDDI registries that implement policy-based
sharing of information among them. The affiliated registries share a common
namespace for UDDI keys that uniquely identify data records.
MESSAGE EXCHANGE PATTERNS
An MEP is a generic interaction pattern that defines the message exchange between two
services.
Primitive MEPs
Before the arrival of contemporary SOA, a common set of primitive MEPs have been in
existence for some time
Request-response
Fire-and-forget
Request and Response
Fig: The request-response MEP.

Establishes a simple exchange – a message is first transmitted from a source (service
requestor) to a destination (service provider). Upon receipt, the destination then responds
with a message back to the source.
Fire-and-Forget
This simple asynchronous pattern is based on the unidirectional transmission of messages
from a source to one or more destinations. A number of variations of the fire-and-forget MEP
exist, including:
 Single-destination pattern: a source sends a message to one destination only
 Multi-cast pattern: a source sends messages to a predefined set of destinations
 Broadcast pattern: similar to multi-cast, except that message is sent to a broader
range of recipient destinations
The fundamental characteristic of the fire-and-forget pattern is that a response to a
transmitted message is not expected.
Fig: The fire-and-forget MEP.
Complex MEPs
 Primitive MEPs can be assembled in various configurations to create complex MEPs.
 Classic example is the publish-and-subscribe model. Services involved with this
model have new roles – publishers and subscribers.
 Two steps involved in publish-and-subscribe model are:
o Step 1: subscriber sends message to notify publisher that it wants to receive
messages on a particular topic

o Step 2: upon availability of requested information, publisher broadcasts
messages on particular topic to all of the topic’s subscribers
 WS-* specifications that incorporate this messaging model include:
o WS-BaseNotification
o WS-BrokeredNotification
o WS-Topics
o WS- Eventing
Fig: The publish-and-subscribe messaging model is a composite of two primitive MEPs.
MEPs and SOAP
 SOAP standard provides its own messaging framework to support single-direction
message transfer.
 Extensible nature of SOAP allows many messaging characteristics and behaviors to
be implemented via SOAP header blocks
MEPs and WSDL
 MEPs play a larger role in WSDL service descriptions as they coordinate the input
and output messages associated with an operation.

 Within WSDL specification, they’re often simply referred to as patterns.
 Release 1.1 of WSDL specification provides support for four message exchange
patterns
Four message exchange patterns in WSDL 1.1
Request-response: Upon receiving a message, service must respond with a standard message
or a fault message.
 Solicit-response: Upon submitting a message to a service requestor, service expects a
standard response message or fault message.
 One-way: Service expects a single message and is not obligated to respond.
 Notification: Service sends a message and expects no response.
WSDL 2.0 MEPs
Release 2.0 of the WSDL specification extends MEP support to eight patterns (and also
changes the terminology) as follows.
 The in-out pattern, comparable to the request-response MEP (and equivalent to the
WSDL 1.1 request-response operation).
 The out-in pattern, which is the reverse of the previous pattern where the service
provider initiates the exchange by transmitting the request. (Equivalent to the WSDL
1.1 solicit-response operation.)
 The in-only pattern, which essentially supports the standard fire-and-forget MEP.
(Equivalent to the WSDL 1.1 one-way operation.)
 The out-only pattern, which is the reverse of the in-only pattern. It is used primarily
in support of event notification. (Equivalent to the WSDL 1.1 notification operation.)

 The robust in-only pattern, a variation of the in-only pattern that provides the option
of launching a fault response message as a result of a transmission or processing error.
 The robust out-only pattern, which, like the out-only pattern, has an outbound
message initiating the transmission. The difference here is that a fault message can be
issued in response to the receipt of this message.
 The in-optional-out pattern, which is similar to the in-out pattern with one exception.
This variation introduces a rule stating that the delivery of a response message is
optional and should therefore not be expected by the service requestor that originated
the communication. This pattern also supports the generation of a fault message.
 The out-optional-in pattern is the reverse of the in-optional-out pattern, where the
incoming message is optional. Fault message generation is again supported.
MEPs and SOA
MEPs are highly generic and abstract in nature. Individually, they simply relate to an
interaction between two services. Their relevance to SOA is equal to their relevance to the
abstract Web services framework. They are therefore a fundamental and essential part of any
Web services-based environment, including SOA.
ORCHESTRATION
An orchestration expresses a body of business process logic that is typically owned by single
organization. Orchestration is composition of various services by a central controlling service
(process service) and the workflow logic involved in it.
Workflow Logic
It is a structured description of the activities or tasks that have to be done to fulfill a certain
business need.
Business Protocol
It defines how participants can interoperate to achieve the completion of a business task.

Process Definition
The details of the workflow logic encapsulated and expressed by an orchestration are
contained within a process definition.
Process Service
Identified and described within a process definition are the allowable process participants.
First, the process (orchestration workflow logic) itself is represented as a service, resulting in
a process service.
Fig: A process service coordinating and exposing functionality from three partner
services.
Partner Service
Other services allowed to interact with the process service are identified as partner services or
partner links. Depending on the workflow logic, the process service can be invoked by an
external partner service, or it can invoke other partner services
Fig: The process service, after first being invoked by a partner service, then invokes
another partner service.

Workflow logic can be broken down into either a basic activity or structured activity.
Basic Activities
Basic activities represent fundamental workflow actions (like receiving a message from a
partner, or manipulating data). They include activities like receive, invoke, reply, throw, wait
Structured Activities
Structured activities can contain other activities and define the business logic between them.
 Sequence activity is used to define a collection of activities which are executed
sequentially in lexical order.
 Flow activity is used to define a collection of activities which are executed
concurrently.
 Link: In a parallel process, it is necessary to synchronize between some of the
activities. Adding a link introduces a control dependency which means that the
activity which is the target of the link will only be executed if the activity that is the
source of the link has completed.
Orchestration and SOA
Orchestration provides an automation model where process logic is centralized yet still
extensible and composable. Orchestrations themselves typically establish a common point of
integration for other applications, which makes an implemented orchestration a key
integration enabler.
Fig: Orchestration relating to other parts of SOA.

These qualities lead to increased organizational agility because:
 The workflow logic encapsulated by an orchestration can be modified or extended in
a central location.
 Positioning an orchestration centrally can significantly ease the merging of business
processes by abstracting the glue that ties the corresponding automation solutions
together.
 By establishing potentially large-scale service-oriented integration architectures,
orchestration, on a fundamental level, can support the evolution of a diversely
federated enterprise.
CHOREOGRAPHY
Choreography is a complex activity comprised of a service composition and a series of
MEPs.
The Web Services Choreography Description Language (WS-CDL) is one of several
specifications that attempts to organize information exchange between multiple organizations
(or even multiple applications within organizations), with an emphasis on public
collaboration.
Collaboration
An important characteristic of choreographies is that they are intended for public message
exchanges. The goal is to establish a kind of organized collaboration between services
representing different service entities, no one entity (organization) necessarily controls the
collaboration logic. Choreographies therefore provide the potential for establishing universal
interoperability patterns for common inter-organization business tasks.
Note: While the emphasis on choreography is B2B interaction, it also can be applied to
enable collaboration between applications belonging to a single organization. The use of
orchestration, though, is far more common for this requirement.

Roles
A Role identifies a set of related behaviors, for example the Buyer role is associated with
purchasing of goods or services and the Supplier role is associated with providing those
goods or services for a fee.
Participants
A Participant identifies a set of related Roles, for example a Commercial Organization could
take both a Buyer Role when purchasing goods and a Seller role when selling them.
Relationships
A Relationship is the association of two Roles for a purpose. A relationship represents the
possible ways in which two roles can interact. For example the Relationships between a
Buyer and a Seller could include:
 A "Purchasing" Relationship, for the initial procurement of goods or services, and
 A "Customer Management" Relationship to allow the Supplier to provide service and
support after the goods have been purchased or the service provided.
Although Relationships are always between two Roles, Choreographies involving more than
two Roles are possible. For example if the purchase of goods involved a third-party Shipper
contracted by the Supplier to deliver the Supplier's goods, then, in addition to the Purchasing
and Customer Management relationships described above, the following relationships might
exist:
 A "Logistics Provider" relationship between the Supplier and the Shipper, and
 A "Goods Delivery" relationship between the Buyer and the Shipper.
Channels
Channels define the characteristics of the message exchange between two specific roles. It
contains information that describes how and where a message is sent to a Role. For example,
it could contain information such as the URL to which the message should be sent, the
policies that are to be applied, such as security, whether or not reliable messaging is to be
used, etc.
Interaction
An Interaction always involves the exchange of information between two Roles in a
Relationship that conform to a Message Exchange Pattern as defined by WSDL 1.2.

Interactions are the fundamental building blocks of choreographies because the completion of
an interaction represents actual progress within a choreography.
Work Units
It consists of either basic activity or a structured activity. Activities are the lowest level
components of the Choreography which do the actual work, such as the Interactions or the
performance of other Choreographies.
Example: A Send Purchase Order Work Unit that includes Interactions for the Buyer to send
an Order, the Supplier to acknowledge the order, and then later accept (or reject) the order.
Reusability, Composability and Modularity
 Each choreography can be designed in a reusable manner, allowing it to be applied to
different business tasks comprised of the same fundamental actions.
 Further, using an import facility, a choreography can be assembled from independent
modules. These modules can represent distinct sub-tasks and can be reused by
numerous different parent choreographies.
 Finally, even though a choreography in effect composes a set of non-specific services
to accomplish a task, choreographies themselves can be assembled into larger
compositions.
Fig: A choreography composed of two smaller choreographies.

Orchestrations and Choreographies
 An orchestration expresses organization-specific business workflow. This means that
an organization owns and controls the logic behind an orchestration, even if that logic
involves interaction with external business partners.
 A choreography, on the other hand, is not necessarily owned by a single entity. It acts
as a community interchange pattern used for collaborative purposes by services from
different provider entities.
 An orchestration is based on a model where the composition logic is executed and
controlled in a centralized manner.
 A choreography typically assumes that there is no single owner of collaboration logic.
 However, one area of overlap between the current orchestration and choreography
extensions is the fact that orchestrations can be designed to include multi-organization
participants.
Fig: A choreography enabling collaboration between two different orchestrations.
Choreography and SOA
Choreography can assist in the realization of SOA across organization boundaries. While it
natively supports composability, reusability, and extensibility, choreography also can
increase organizational agility and discovery.

Fig: Choreography relating to other parts of SOA.
WS TRASACTIONS
WS Transactions includes:
WS Coordination
WS Atomic Transactions
WS Business Activities.
COORDINATION
 Something that is happening or executing has meaning during its lifetime, and
description of its meaning is classified as context information.
 More complex an activity, the more context information it brings with it.
An activity is a generic concept used to represent a task or a unit of work performed by a set
of services.
Complexity of an activity
 The complexity of an activity can relate to various factors, including the:
o Amount of services participating in the activity
o Duration of the activity
o Frequency with which nature of activity changes
o Whether or not multiple instances of activity can concurrently exist

Coordination
A framework is required to provide a means for context information in complex activities to
be managed, preserved and/or updated, and distributed to activity participants. Coordination
establishes such a framework.
Coordinator composition
 The coordinator composition consists of the following services:
o Activation service: It creates a new context and associates this context with a
particular activity
o Registration service: It allows participating services to use context
information to register for a supported context protocol
o Protocol-specific services: It represent protocols supported by the
coordinator’s coordination type
o Coordinator: It is controller service of this composition, also known as the
coordination service
Coordination types and protocols
 Each coordinator is based on a coordination type, which specifies the nature and
underlying logic of an activity for which context information is being managed
 The two coordination types most commonly associated with WS-Coordination are
WS-AtomicTransaction and WS-BusinessActivity.
 Coordination type extensions provide a set of coordination protocols, which represent
unique variations of coordination types and consist of a collection of specific
behaviors and rules
Coordination contexts and coordination participants
 A context created by the activation service is referred to as a coordination context.
 Types of data held within a coordination context include:
o Unique identifier that represents the activity
o Expiration value
o Coordination type information
 A service that wants to take part in an activity managed by WS-Coordination must
request the coordination context from the activation service

Activation and registration process
 Coordination service composition is initiated when an application service contacts the
activation service
 Via a CreateCoordinationContext request message, it asks the activation service to
generate a new set of context data
 Once passed back with the ReturnContext message, the application service now can
invite other services to participate in the coordination
 Any Web service in possession of this context information may issue a registration
request to the registration service
The completion process
The application service can request that a coordination be completed by issuing a completion
request message to the coordination service. The coordinator, in turn, then issues its own
completion request messages to all coordination participants. Each participant service
responds with a completion acknowledgement message.
Fig: The WS-Coordination registration process.

Fig: The WS-Coordination completion process.
Coordination and SOA
A coordinator-based context management framework, as provided by WS-Coordination and
its supporting coordination types, introduces a layer of composition control to SOAs. It
standardizes the management and interchange of context information within a variety of key
business protocols.
Fig: Coordination as it relates to other parts of SOA.
Coordination also alleviates the need for services to retain state. Statelessness is a key
service-orientation principle applied to services for use within SOAs. Coordination reinforces
this quality by assuming responsibility for the management of context information.

ATOMIC TRANSACTIONS
Atomic transactions
Transaction is a series of steps (operations) wrapped into a single action and is fundamental
to many business process requirements. Atomic transactions implement the familiar commit
and rollback features to enable cross-service transaction support.
Example
When you purchase a book from an online bookstore, you exchange money (in the form of
credit) for a book. If your credit is good, a series of related operations ensures that you get the
book and the bookstore gets your money. However, if a single operation in the series fails
during the exchange, the entire exchange fails. You do not get the book and the bookstore
does not get your money.
ACID transactions
 Atomic Either all of the changes within the scope of the transaction succeed, or none
of them succeed. This characteristic introduces the need for the rollback feature that is
responsible for restoring any changes completed as part of a failed transaction to their
original state.
 Consistent None of the data changes made as a result of the transaction can violate the
validity of any associated data models. Any violations result in a rollback of the
transaction.
 Isolated If multiple transactions occur concurrently, they may not interfere with each
other. Each transaction must be guaranteed an isolated execution environment.
 Durable Upon the completion of a successful transaction, changes made as a result of
the transaction can survive subsequent failures.
Atomic transaction protocols
 A Completion protocol, which is typically used to initiate the commit or abort states
of the transaction.
 The Durable 2PC protocol for which services representing permanent data
repositories should register.
 The Volatile 2PC protocol to be used by services managing non-persistent
(temporary) data.

The atomic transaction coordinator
When WS-AtomicTransaction protocols are used, the coordinator controller service can be
referred to as an atomic transaction coordinator. This particular implementation of the WS-
Coordination coordinator service represents a specific service model. The atomic transaction
coordinator plays a key role in managing the participants of the transaction process and in
deciding the transaction's ultimate outcome.
Fig: The atomic transaction coordinator service model
The atomic transaction process
 The atomic transaction coordinator is tasked with the responsibility of deciding the
outcome of a transaction. It bases this decision on feedback it receives from all of the
transaction participants.
 The collection of this feedback is separated into two phases. During the prepare
phase, all participants are notified by the coordinator, and each is asked to prepare and
then issue a vote. Each participant's vote consists of either a "commit" or "abort"
request.

Fig: The coordinator requesting that transaction participants prepare to vote
 After the votes are collected, the atomic transaction coordinator enters the commit
phase. It now reviews all votes and decides whether to commit or rollback the
transaction. If all votes are received and if all participants voted to commit, the
coordinator declares the transaction successful, and the changes are committed.
However, if any one vote requests an abort, or if any of the participants fail to
respond, then the transaction is aborted, and all changes are rolled back.
Fig: The transaction participants voting on the outcome of the atomic transaction.

Atomic transactions and SOA
 The transactional functionality implemented in service-oriented solutions is done so
among the components that executes an activity on behalf of a single service. When
service compositions become more commonplace, the need to move transaction
boundaries into cross-service interaction scenarios increases.
 Being able to guarantee an outcome of an activity is a key part of enterprise-level
computing, and atomic transactions therefore play an important role in ensuring
quality of service.
 They promote interoperability when extended into integrated environments. This
allows the scope of an activity to span different solutions built with different vendor
platforms, while still being assured a guaranteed all-or-nothing outcome.
Fig: Atomic transaction relating to other parts of SOA
Business Activities
 Business activities manage complex, long-running activities that can vary in scope
and in the amount of participating services.
 What distinguishes a business activity from a regular complex activity is that its
participants are required to follow specific rules defined by protocols. Business
activities primarily differ from the also protocol-based atomic transactions in how
they deal with exceptions and in the nature of the constraints introduced by the
protocol rules.
 For instance, business activity protocols do not offer rollback capabilities. Instead,
business activities provide an optional compensation process that, much like a "plan
B," can be invoked when exception conditions are encountered.

Business activity protocols
It provides two very similar protocols, each of which dictates how a participant may behave
within the overall business activity.
 The BusinessAgreementWithParticipantCompletion protocol, which allows a
participant to determine when it has completed its part in the business activity.
 The BusinessAgreementWithCoordinatorCompletion protocol, which requires that a
participant rely on the business activity coordinator to notify it that it has no further
processing responsibilities.
Business activity participants interact with the standard WS-Coordination coordinator
composition to register for a protocol.
The business activity coordinator
When its protocols are used, the WS-Coordination controller service assumes a role specific
to the coordination type, in this case it becomes a business activity coordinator. This
coordinator has varying degrees of control in the overall activity, based on the coordination
protocols used by the participants.
Fig: The business activity coordinator service model.

Business activity states
During the lifecycle of a business activity, the business activity coordinator and the activity
participants transition through a series of states. The actual point of transition occurs when
special notification messages are passed between these services.
 Completed State: A participant can indicate that it has completed the processing it
was required to perform as part of the activity by issuing a completed notification.
This moves the participant from an active state to a completed state. The coordinator
may respond with a close message to let the participant know that the business
activity is being successfully completed.
 Compensation State: However, if things don't go as planned during the course of a
business activity, one of a number of options are available. Participants can enter a
compensation state during which they attempt to perform some measure of exception
handling. It could involve a series of additional processing steps. Its purpose is
generally to execute plan B when plan A fails.
 Cancelled State: Alternatively, a cancelled state can be entered. This typically results
in the termination of any further processing outside of the cancellation notifications
that need to be distributed.
 Exit State: They may leave the business activity after their individual contributions
have been performed. When doing so, participants enter an exit state by issuing an
exit notification message to the business activity coordinator.
Business activities and atomic transactions
It is important to note that the use of a business activity does not exclude the use of atomic
transactions. In fact, it is likely that a long-running business activity will encompass the
execution of several atomic transactions during its lifetime.
Business activities and SOA
 Business activities fully complement the composable nature of SOA by tracking and
regulating complex activities while also allowing them to carry on for long periods of
time.
 Service autonomy and statelessness are preserved by permitting services to participate
within an activity for only the duration they are absolutely required to.
 Through the use of the compensation process, business activities increase SOA's
quality of service by providing built-in fault handling logic.

Fig: Two atomic transactions residing within the scope of a business activity.
Fig: A business activity relating to other parts of SOA.
The support of the WS-BusinessActivity extension by multiple solutions promotes inherent
interoperability and can greatly simplify integration architectures. Business activities take this
a few steps further, though, by allowing the scope of the activity to include interaction with
outside business partners.

UNIT 5 - BUILDING SOA-BASED APPLICATIONS
1. Service Oriented Analysis and Design Thomas Erl - Ch 11.1, 13.1
2. Service Modeling Thomas Erl - Ch 12.1
3. Design standards and guidelines Thomas Erl - Ch 15.5
4. Composition Thomas Erl - Ch 14
5. WS-BPEL Thomas Erl - Ch 16.1
6. WS-Coordination Thomas Erl - Ch 16.2
7. WS-Policy Thomas Erl - Ch 17.3
8. WS-Security Thomas Erl - Ch 17.5
9. SOA support in J2EE Thomas Erl - Ch 18.2
Content Beyond Syllabus SOA support in .NET

Fig: Common phases of an SOA delivery lifecycle
SERVICE ORIENTED ANALYSIS
The process of determining how business automation requirements can be represented through
service-orientation is the domain of the service-oriented analysis.
Objectives of Service Oriented Analysis
The primary questions addressed during this phase are:
 What services need to be built?
 What logic should be encapsulated by each service?
The overall goals of performing a service-oriented analysis are as follows:
 Define a preliminary set of service operation candidates.
 Group service operation candidates into logical contexts. These contexts represent service
candidates.
 Define preliminary service boundaries so that they do not overlap with any existing or
planned services.
 Identify encapsulated logic with reuse potential.
 Ensure that the context of encapsulated logic is appropriate for its intended use.
 Define any known preliminary composition models.

Service Oriented Analysis Process
The service-oriented analysis process is a sub-process of the overall SOA delivery lifecycle.
Service oriented analysis will not replace existing analysis procedures in IT industry. Instead, it
proposes a sequence of supplementary steps, specific to the delivery of a service-oriented
solution.
The chosen delivery strategy will determine the layers of abstraction that comprise the service
layers of a solution environment. From an analysis perspective, each layer has different modeling
requirements.
Other questions that should be answered prior to proceeding with the service-oriented analysis
include:
 What outstanding work is needed to establish the required business model(s) and
ontology?
 What modeling tools will be used to carry out the analysis?
 Will the analysis be part of an SOA transition plan?
Step 1: Define business automation requirements
Business requirements are collected and their documentation is required for this analysis process
to begin. Only requirements related to the scope of that solution should be considered. Business
requirements should be sufficiently mature so that a high-level automation process can be
defined.
Step 2: Identify existing automation systems
Existing application logic that is already, to whatever extent, automating any of the requirements
identified in Step 1 need to be identified. A service-oriented analysis does assist in scoping the
potential systems affected.
Step 3: Model candidate services
A service-oriented analysis introduces the concept of service modeling a process by which
service operation candidates are identified and then grouped into a logical context. These groups
eventually take shape as service candidates that are then further assembled into a tentative
composite model representing the combined logic of the planned service-oriented application.

Fig: A high-level service-oriented analysis process
SERVICE ORIENTED DESIGN
Service-oriented design is the process by which concrete physical service designs are derived
from logical service candidates and then assembled into abstract compositions that implement a
business process.
Objectives of service-oriented design
The primary questions answered by this phase are:
 How can physical service interface definitions be derived from the service candidates
modeled during the service-oriented analysis phase?
 What SOA characteristics do we want to realize and support?
 What industry standards and extensions will be required by our SOA to implement the
planned service designs and SOA characteristics?
To address these questions, the design process actually involves further analysis. This time our
focus is on environmental factors and design standards that will shape our services.

The overall goals of performing a service-oriented design are as follows:
 Determine the core set of architectural extensions.
 Set the boundaries of the architecture.
 Identify required design standards.
 Define abstract service interface designs.
 Identify potential service compositions.
 Assess support for service-orientation principles.
 Explore support for characteristics of contemporary SOA.
"Design standards" versus "Industry standards"
Design standards represent custom standards created by an organization to ensure that services
and SOAs are built according to a set of consistent conventions.
Industry standards are provided by standards organizations and are published in Web services
and XML specifications.
Step 1: Compose SOA
A fundamental quality of SOA is that each instance of a service-oriented architecture is uniquely
composable.
This step consists of the following three further steps:
1. Choose service layers.
2. Position core SOA standards.
3. Choose SOA extensions.
Steps 2 to 4: Design services
These steps are represented by the following three separate processes:
 Entity-centric business service design process.
 Application service design process.
 Task-centric business service design process.
Primary input for each of these service design processes is the corresponding service candidates
produced in the service modeling process during the service-oriented analysis.

The service-oriented design process
Fig: A high-level service-oriented design process.
Step 5: Design service-oriented business process
Upon establishing an inventory of service designs, orchestration layer (the glue that binds our
services with business process logic) is created. This step results in the formal, executable
definition of workflow logic, which translates into the creation of a WS-BPEL process
definition.
Fig: Three core specifications associated with service design

SERVICE MODELING
A service modeling process is essentially an exercise in organizing the information gathered in
Steps 1 and 2 of the parent service-oriented analysis process. Sources of the information required
can be diverse, ranging from various existing business model documents to verbally interviewing
key personnel that may have the required knowledge of a relevant business area.
Process description
Up next is a series of 12 steps that comprise a proposed service modeling process. Specifically,
this particular process provides steps for the modeling of an SOA consisting of application,
business, and orchestration service layers.
Step 1: Decompose the business process
Take the documented business process and break it down into a series of granular process steps.
It is important that a process's workflow logic be decomposed into the most granular
representation of processing steps, which may differ from the level of granularity at which the
process steps were originally documented.
Step 2: Identify business service operation candidates
Some steps within a business process can be easily identified as not belonging to the potential
logic that should be encapsulated by a service candidate.
Examples include:
 Manual process steps that cannot or should not be automated.
 Process steps performed by existing legacy logic for which service candidate
encapsulation is not an option.
By filtering out these parts we are left with the processing steps most relevant to our service
modeling process.
Step 3: Abstract orchestration logic
If orchestration layer is built as part of the SOA, then the parts of the processing logic that this
layer would potentially abstract should be identified. Potential types of logic suitable for this
layer include:
 business rules

 conditional logic
 exception logic
 sequence logic
 Some of the identified workflow logic likely will be dropped eventually. In service-
oriented design phase, practical considerations come into play. This may result in the
need to remove some of the candidate operations, which would also require that
corresponding workflow logic be removed from the orchestration layer as well.
Step 4: Create business service candidates
 Review the processing steps that remain and determine one or more logical contexts with
which these steps can be grouped. Each context represents a service candidate. The
contexts will depend on the types of business services being chosen to build.
 For example, task-centric business services will require a context specific to the process,
while entity-centric business services will introduce the need to group processing steps
according to their relation to previously defined entities.
 The primary purpose of this exercise is to establish the required set of contexts.
 The scope of this step can be expanded to include an analysis of additional service
operation candidates not required by the current business process, but added to round out
entity services with a complete set of reusable operations for future reuse.
Step 5: Refine and apply principles of service-orientation
To make service candidates truly worthy of an SOA, underlying logic of each proposed service
operation candidate is observed closely.
The following four key principles are not naturally provided through the use of Web services:
 reusability
 autonomy
 statelessness
 discoverability
Of these four, only the first two are addressed in service modeling stage. The latter two on this
list are addressed in the service-oriented design process.

Fig: A sample service modeling process.
Step 6: Identify candidate service compositions
Identify a set of the most common scenarios that can take place within the boundaries of the
business process. For each scenario, follow the required processing steps as they exist now.
This exercise accomplishes the following:
 It gives a good idea as to how appropriate the grouping of process steps is.
 It demonstrates the potential relationship between orchestration and business service
layers.
 It identifies potential service compositions.
 It highlights any missing workflow logic or processing steps.
Ensure that as part of chosen scenarios, failure conditions is included that involve exception
handling logic. Note also that any service layers established at this point are still preliminary and
still subject to revisions during the design process.

Step 7: Revise business service operation grouping
Based on the results of the composition exercise in Step 6, revisit the grouping of your business
process steps and revise the organization of service operation candidates as necessary. It is not
unusual to consolidate or create new groups (service candidates) at this point.
Step 8: Analyze application processing requirements
The underlying processing requirements of all service candidates is carefully studied to abstract
any further technology-centric service candidates from this view that will complete a preliminary
application services layer. To accomplish this, each processing step identified so far is required
to undergo a mini-analysis.
Specifically, what need to be determined is:
 What underlying application logic needs to be executed to process the action described
by the operation candidate.
 Whether the required application logic already exists or whether it needs to be newly
developed.
 Is more than one system required to complete this action?
Note that the information gathered during Step 2 of the parent service-oriented analysis process
will be referenced at this point.
Step 9: Identify application service operation candidates
Break down each application logic processing requirement into a series of steps. Then these steps
are labeled explicitly so that they reference the function they are performing. Ideally, the
business process step for which this function is being identified is not referenced.
Step 10: Create application service candidates
Group these processing steps according to a predefined context. With application service
candidates, the primary context is a logical relationship between operation candidates. This
relationship can be based on any number of factors, including:
 association with a specific legacy system
 association with one or more solution components
 logical grouping according to type of function
Various other issues are factored in once service candidates are subjected to the service-oriented
design process. For now, this grouping establishes a preliminary application service layer.
Step 11: Revise candidate service compositions

Revisit the original scenarios you identified in Step 5 and run through them again. Only, this
time, incorporate the new application service candidates as well. This will result in the mapping
of elaborate activities that bring to life expanded service compositions. Be sure to keep track of
how business service candidates map to underlying application service candidates during this
exercise.
Step 12: Revise application service operation grouping
Going through the motions of mapping the activity scenarios from Step 11 usually will result in
changes to the grouping and definition of application service operation candidates. It will also
likely point out any omissions in application-level processing steps, resulting in the addition of
new service operation candidates and perhaps even new service candidates.
Optional Step: Keep an inventory of service candidates
So far, this process has assumed that this is the first time you are modeling service candidates.
Ideally, when going through subsequent iterations of this process, you should take existing
service candidates into account before creating new ones.
DESGIN STANDARDS AND GUIDELINES
Applying Naming Standards
Labeling services is the equivalent to labeling IT infrastructure. It is therefore essential that
service interfaces be as consistently self-descriptive as possible.
Naming standards therefore need to be defined and applied to:
 service endpoint names
 service operation names
 message values
 Service candidates with high cross-application reuse potential should always be
stripped of any naming characteristics that hint at the business processes for which
they were originally built. For example, instead of naming an operation
GetTimesheetSubmissionID, simply reduce it to GetTimesheetID or just GetID.
 Application services need to be named according to the processing context under
which their operations are grouped. Both the verb+noun or noun only conventions

can be used. Simplified examples of suitable application service names are
CustomerDataAccess, SalesReporting, and GetStatistics.
 Application service operations need to clearly communicate the nature of their
individual functionality. Examples of suitable application service operation names are
GetReport, ConvertCurrency, and VerifyData.
 Entity-centric business services need to remain representative of the entity models
from which their corresponding service candidates were derived. Typically, this type
of service uses the noun only naming structure. Examples of suitable entity-centric
business service names are Invoice, Customer, and Employee.
 Service operations for entity-centric business services should be verb-based and
should not repeat the entity name. For example, an entity-centric service called
Invoice should not have an operation named AddInvoice.
Apply a suitable level of interface granularity
The trend to create interfaces for Web services that are coarser than those traditionally
designed for RPC-based components has been encouraged by vendors as a means of
overcoming some of the performance challenges associated with XML-based processing.
Here are some guidelines:
 Fully understand the performance limitations of the target deployment environment
and explore alternative supporting technologies (such as the binary encoding
extensions developed by the W3C), if required.
 Explore the possibility of providing alternate (coarse and less coarse-grained) WSDL
definitions for the same Web services. These approaches de-normalize service
contracts but can address performance issues and accommodate a range of requestors.
 Assign coarse-grained interfaces to services designated as solution endpoints and
allow finer-grained interfaces for services confined to predefined boundaries.
Interoperability is promoted in coarse-grained services, and reusability is more
fostered in finer-grained services.
Design service operations to be inherently extensible
Some types of business process changes result in the need for the scope of entities to be
broadened. As a result, corresponding business services may need to be extended.

It is important to design operations and messages to be as activity-agnostic as possible.
Further, it is a good habit to respond to new processing requirements by first investigating the
possibility of composing other available services. This may succeed in fulfilling requirements
without having to touch the service interface.
Note that extensions to an existing service interface will impact the corresponding XSD
schema. These extensions can be facilitated by supplying new schemas specifically for the
extension.
Identify known and potential service requestors
Services are designed to address business requirements as they pertain to that application.
Limiting a service design to fulfill immediate requirements can inhibit its potential as a
reusable, adaptive, and interoperable unit of processing logic.
It is therefore advisable that any existing service design process incorporate a speculative
analysis of how that service may be utilized outside its initial application boundaries. In other
words, it can be useful and practical to identify any potential future service requestors and to
then incorporate their anticipated requirements into the current service design.
Consider using modular WSDL documents
WSDL service descriptions can be assembled dynamically at runtime through the use of
import statements that link to separate files that contain parts of the service definition. This
allows you to define modules for types, operations, and bindings that can be shared across
WSDL documents.
It also allows you to leverage any existing XSD schema modules you may already have
designed. Many organizations separate schemas into granular modules that represent
individual complex types. This establishes a centralized repository of schemas that can be
assembled into customized master schema definitions. By enabling you to import XSD
schema modules into the types construct of a WSDL definition, you now can have your
WSDL documents use those same schema modules.
Use namespaces carefully
A WSDL definition consists of a collection of elements with different origins. Therefore,
each definition often will involve a number of different namespaces. Following is a list of
common namespaces used to represent specification-based elements:
http://schemas.xmlsoap.org/wsdl/

http://schemas.xmlsoap.org/wsdl/soap/
http://www.w3.org/2001/XMLSchema/
http://schemas.xmlsoap.org/wsdl/http/
http://schemas.xmlsoap.org/wsdl/mime/
http://schemas.xmlsoap.org/soap/envelope/
When assembling a WSDL from modules, additional namespaces come into play, especially
when importing XSD schema definitions. Further, when defining your own elements, you
can establish more namespaces to represent application-specific parts of the WSDL
documents. It is not uncommon for larger WSDL documents to contain up to ten different
namespaces and the qualifiers to go along with them. Therefore, it is highly recommended
that you organize the use of namespaces carefully within and across WSDL documents.
The WS-I Basic Profile requires the use of the targetNamespace attribute to assign a
namespace to the WSDL as a whole. If the XSD schema is embedded within the WSDL
definition, then the WS-I Basic Profile requires that it also be assigned a targetNamespace
value (which can be the same value used by the WSDL targetNamespace).
Use the SOAP document and literal attribute values
There are two specific attributes that establish the SOAP message payload format and the
data type system used to represent payload data. These are the style attribute used by the
soap:binding element and the use attribute assigned to the soap:body element.
The style attribute can be assigned a value of "document" or "rpc." The former supports the
embedding of entire XML documents within the SOAP body, whereas the latter is designed
more to mirror traditional RPC communication and therefore supports parameter type data.
The use attribute can be set to a value of "literal" or "encoded." This attribute value indicates
which type system you want your message to use. The "literal" setting states that XSD data
types will be applied.
When considering these two attributes, the following four combinations are possible and
supported by SOAP:
 style:RPC + use:encoded
 style:RPC + use:literal
 style:document + use:encoded
 style:document + use:literal

The style:document + use:literal combination is preferred by SOA because it supports the
notion of the document-style messaging model that is key to realizing the features of many
key WS-* specifications. Further, the WS-I Basic Profile requires that the use attribute
always be set to "literal."
Use WS-I Profiles even if WS-I compliance isn't required
WS-I Profiles are sound, well researched, and proven and can save you a great deal of time
and effort when developing your own design standards.
Document services with metadata
Policies represent an important metadata supplement to WSDL definitions. For example, a
policy may express certain security requirements, processing preferences, and behavioral
characteristics of a service provider. This allows service requestors to better assess a service
provider and offers them the opportunity to be fully prepared for interaction. Polices are
formally implemented using a set of WS-* specifications.
Whatever unique properties a service has, they should be documented to easily communicate
a service's requirements, characteristics, or restrictions to others that may want to use it. This
information can be added to a WSDL definition through the use of the documentation
element and it could even be contained within a metadata document that is published
separately and easily accessible. This promotes the discovery and reuse of services.
SOA COMPOSITION GUIDELINES
Prior to commencing with the design of individual services, it is advisable to perform some
preparatory tasks to formally define a service-oriented architecture.
SOA will consist of a number of technology components that establish an environment in which
the 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

Fig: The most fundamental components of an SOA.
Fig: Suggested steps for composing a preliminary SOA
Considerations for Choosing Service Layers
Fig: Designated service layers organize and standardize Web services within SOA.

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 configure service layers within your environment, if at all. Some of the guidelines for
choosing service layers:
 Existing configurations: If service layers already have been standardized within your
enterprise, you should make every attempt to conform new service designs to these
layers. The exception to this is if a need to alter the current service layer configuration
has been identified.
 Required standards: If you are building new types of services or service layers, ensure
that these are delivered along with accompanying design standards.
 Service composition performance: Service compositions can impose a significant
amount of processing overhead, especially when intermediary services are required to
process the contents of SOAP messages. It is highly advisable to conduct performance
tests prior to deciding on a multi-level service layer configuration.
 Service deployment: In a highly distributed environment, reusable services that are
centrally located can impose remote messaging latency on solutions that need to connect
to them. These and other deployment issues need to be assessed prior to proceeding with
solution-agnostic service layers.
 Service versioning: After the service is deployed, extensions may be required to further
complete the service's expected feature set. If these extensions result in changes to the
initial interface, a versioning system will need to be in place to accommodate your
solution and any other requestors that are using the service.
 Business services and XSD schema designs: If your enterprise already has established a
comprehensive XML data representation architecture, it is worth taking a look at your
existing set of XSD schemas. These should be analyzed for potential compatibility issues
with planned business services.
 Business service maintenance: If proceeding with the agile delivery strategy, the on-
going maintenance of business services needs to be planned for. As the top-down analysis
proceeds, revisiting services to keep their business logic representation in alignment
introduces a separate administration process that may need to tie into the versioning
system mentioned earlier.

Considerations for Positioning Core SOA Standards
Fig: SOA can structure the manner in which common XML and Web services standards
are applied.
Industry standards and SOA
Abstract service designs are realized physically through the use of specific Web services markup
languages. These languages originate from published specifications of which different versions
in different stages of maturity exist. New versions of a specification can alter and extend the
feature set provided by previous versions. It is important to ensure that your SOA is fully
standardized with respect to the specification versions that establish a fundamental layer of your
technology architecture. This ensures standardization within an organization, expresses
consistent metadata to any services with which external partners may need to interface and
promotes interoperability.
Fig: The operational relationship between core SOA specifications.

XML and SOA
Fundamental to everything that comprises a contemporary SOA is data representation via XML.
This can raise various issues worth thinking about during the service-oriented design phase,
including:
 RPC-style versus document-style SOAP messages
 Auto-generated XML
It is useful for fulfilling immediate conversion or data sharing requirements. But the
persistent use of auto-generated XML can lead to the proliferation of non-standardized
data representation.
 Fitting SOA on top of an established XML data representation architecture
The WS-I Basic Profile
The Basic Profile is the result of WS-I efforts to assemble a set of mature, core specifications
that comprise a commonly supported and well aligned Web services platform. For example,
versions 1.0 and 1.1 of the Basic Profile propose that organizations standardize on the following
specifications:
WSDL 1.1, SOAP 1.1, UDDI 2.0, XML 1.0, XML Schema 1.0
This document introduces a series of design standards of its own, targeted primarily at resolving
potential interoperability issues.
WSDL and SOA
The WSDL definition is the primary deliverable of each of the service design processes. Some of
the key design issues that relate to WSDL design within SOA are highlighted here:
 Standardized use of namespaces
 Modular service definitions
 Compatibility of granularity
XML Schema and SOA
XML Schema definitions (or XSD schemas) establish data integrity throughout service-oriented
architectures. They are used intrinsically by many WS-* specifications but are most prominent in
their role as defining a service's public data model. Following are some considerations as to how
XSD schemas can be positioned and utilized in support of SOA.
 Modular XSD schemas

XSD schemas can be broken down into individual modules that are assembled at runtime
using the include statement or the import statement. XSD schema modules can provide
various definitions that can be reused by different WSDL definitions.
 Document-style messages and XSD schemas
The document-style SOAP messages required by SOA are increasingly intelligence-
heavy and therefore place a greater emphasis on advanced validation requirements. The
use of extensible or redefined schemas and supplementary technologies (eg: XSLT) may
be required for that validation.
SOAP and SOA
SOAP messages are what fuel all action within contemporary SOA. Following are two primary
areas in which SOAP messaging can be affected.
 SOAP message style and data types
This relates specifically to the style attribute used by the soap:binding element and the
use attribute assigned to the soap:body element.
 SOAP headers
The SOAP headers used by messages processed by a service depend primarily on the
WS-* specifications supported by the service-oriented architecture in which the service
resides.
Namespaces and SOA
Namespaces in SOA cannot be created arbitrarily. The WS-I Basic Profile provides a set of best
practices for implementing namespaces within WSDL definitions. However, additional design
standards are required to ensure that namespaces are used properly in XML documents outside of
WSDL definition boundaries.
UDDI and SOA
UDDI provides an industry standard means of organizing service description pointers to
accommodate the process of discovery through service registries. When implemented, UDDI
typically represents an enterprise-wide architectural component positioned to provide a central
discovery mechanism within and across SOAs.

Considerations for Choosing SOA Extensions
Fig: WS-* extensions allow for individual SOAs to be uniquely composed .
Choosing SOA characteristics
The primary influences that shape SOA are:
 principles of service-orientation
 first-generation Web services concepts
 WS-* concepts
The first-generation Web services standards establish commonly accepted core architecture and
therefore are considered required components of contemporary SOA. It is recommended that you
identify the primary SOA characteristics you want your services to inherently support and
promote. If you are delivering your first service-oriented architecture, this becomes a critical
decision point.
Choosing WS-* specifications
It is through the use of the many available WS-* specifications that many of the identified SOA
characteristics are realized. The key considerations for adding the features of a WS-*
specification to your SOA is the maturity of the specification itself, and the available support it is
receiving by product vendors specifically, vendors whose products you already are using.
WS-BPEL specification is a good example of a WS-* extension for which relatively strong
vendor support already exists.

WS – BPEL
The process element
It is the root element of a WS-BPEL process definition. It is assigned a name value using
the name attribute and is used to establish the process definition- related namespaces.
A skeleton process definition.
<process name="TimesheetSubmissionProcess"
targetNamespace="http://www.xmltc.com/tls/process/"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpl="http://www.xmltc.com/tls/process/"
xmlns:emp="http://www.xmltc.com/tls/employee/"
xmlns:inv="http://www.xmltc.com/tls/invoice/"
xmlns:tst="http://www.xmltc.com/tls/timesheet/"
xmlns:not="http://www.xmltc.com/tls/notification/">
<partnerLinks>
...
</partnerLinks>
<variables>
...
</variables>
<sequence>
...
</sequence>
...
</process>
The partnerLinks and partnerLink elements
A partnerLink element establishes the port type of the service (partner) that will be
participating during the execution of the business process. Partner services can act as a client to
the process, responsible for invoking the process service. Alternatively, partner services can be
invoked by the process service itself.

The contents of a partnerLink element represent the communication exchange between
two partners the process service being one partner and another service being the other. The
partnerLink element contains the myRole and partnerRole attributes that establish the service
provider role of the process service and the partner service respectively.
Put simply, the myRole attribute is used when the process service is invoked by a partner
client service, because in this situation the process service acts as the service provider. The
partnerRole attribute identifies the partner service that the process service will be invoking
(making the partner service the service provider).
Note that both myRole and partnerRole attributes can be used by the same partnerLink
element when it is expected that the process service will act as both service requestor and service
provider with the same partner service.
<partnerLinks>
<partnerLink name="client"
partnerLinkType="tns:TimesheetSubmissionType"
myRole="TimesheetSubmissionServiceProvider"/>
<partnerLink name="Invoice"
partnerLinkType="inv:InvoiceType"
partnerRole="InvoiceServiceProvider"/>
<partnerLink name="Timesheet"
partnerLinkType="tst:TimesheetType"
partnerRole="TimesheetServiceProvider"/>
<partnerLink name="Employee"
partnerLinkType="emp:EmployeeType"
partnerRole="EmployeeServiceProvider"/>
<partnerLink name="Notification"
partnerLinkType="not:NotificationType"
partnerRole="NotificationServiceProvider"/>
</partnerLinks>
The partnerLinkType element
For each partner service involved in a process, partnerLinkType elements identify the
WSDL portType elements referenced by the partnerLink elements within the process definition.

Therefore, these constructs typically are embedded directly within the WSDL documents of
every partner service (including the process service).
The partnerLinkType construct contains one role element for each role the service can
play, as defined by the partnerLink myRole and partnerRole attributes. As a result, a
partnerLinkType will have either one or two child role elements.
A WSDL definitions construct containing a partnerLinkType construct.
<definitions name="Employee"
targetNamespace="http://www.xmltc.com/tls/employee/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk=
"http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
...
>
...
<plnk:partnerLinkType name="EmployeeServiceType" xmlns=
"http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<plnk:role name="EmployeeServiceProvider">
<portType name="emp:EmployeeInterface"/>
</plnk:role>
</plnk:partnerLinkType>
...
</definitions>
Note that multiple partnerLink elements can reference the same partnerLinkType. This is
useful for when a process service has the same relationship with multiple partner services. All of
the partner services can therefore use the same process service portType elements.
The variables element
WS-BPEL process services commonly use the variables construct to store state
information related to the immediate workflow logic. Entire messages and data sets formatted as

XSD schema types can be placed into a variable and retrieved later during the course of the
process. The type of data that can be assigned to a variable element needs to be predefined using
one of the following three attributes: messageType, element, or type.
The messageType attribute allows for the variable to contain an entire WSDL-defined
message, whereas the element attribute simply refers to an XSD element construct. The type
attribute can be used to just represent an XSD simpleType, such as string or integer.
The variables construct hosting only some of the child variable elements used later by the
Timesheet Submission Process.
<variables>
<variable name="ClientSubmission"
messageType="bpl:receiveSubmitMessage"/>
<variable name="EmployeeHoursRequest"
messageType="emp:getWeeklyHoursRequestMessage"/>
<variable name="EmployeeHoursResponse"
messageType="emp:getWeeklyHoursResponseMessage"/>
<variable name="EmployeeHistoryRequest"
messageType="emp:updateHistoryRequestMessage"/>
<variable name="EmployeeHistoryResponse"
messageType="emp:updateHistoryResponseMessage"/>
...
</variables>
Typically, a variable with the messageType attribute is defined for each input and output
message processed by the process definition. The value of this attribute is the message name
from the partner process definition.
The getVariableProperty and getVariableData functions
WS-BPEL provides built-in functions that allow information stored in or associated with
variables to be processed during the execution of a business process.
getVariableProperty(variable name, property name)
This function allows global property values to be retrieved from variables. It simply
accepts the variable and property names as input and returns the requested value.

getVariableData(variable name, part name, location path )
Because variables commonly are used to manage state information, this function is
required to provide other parts of the process logic access to this data. The getVariableData
function has a mandatory variable name parameter and two optional arguments that can be used
to specify a part of the variable data.
Two getVariableData functions being used to retrieve specific pieces of data from different
variables.
getVariableData ('InvoiceHoursResponse', 'ResponseParameter')
getVariableData ('input','payload','/tns:TimesheetType/Hours/...')
The sequence element
The sequence construct allows you to organize a series of activities so that they are
executed in a predefined, sequential order. WS-BPEL provides numerous activities that can be
used to express the workflow logic within the process definition. The remaining element
descriptions in this section explain the fundamental set of activities used as part of our upcoming
case study examples.
<sequence>
<receive>
...
</receive>
<assign>
...
</assign>
<invoke>
...
</invoke>
<reply>
...
</reply>
</sequence>

The invoke element
This element identifies the operation of a partner service that the process definition
intends to invoke during the course of its execution. The invoke element is equipped with five
common attributes, which further specify the details of the invocation. Attributes of invoke
element:
 partnerLink
 portType
 operation
 inputVariable
 outputVariable
The invoke element identifying the target partner service details.
<invoke name="ValidateWeeklyHours"
partnerLink="Employee"
portType="emp:EmployeeInterface"
operation="GetWeeklyHoursLimit"
inputVariable="EmployeeHoursRequest"
outputVariable="EmployeeHoursResponse"/>
The receive element
The receive element allows us to establish the information a process service expects upon
receiving a request from an external client partner service. In this case, the process service is
viewed as a service provider waiting to be invoked.
The receive element contains a set of attributes, each of which is assigned a value relating
to the expected incoming communication. Attributes of receive element:
 partnerLink
 portType
 operation
 variable
 createInstance
.

<receive name="receiveInput"
partnerLink="client"
portType="tns:TimesheetSubmissionInterface"
operation="Submit"
variable="ClientSubmission"
createInstance="yes"/>
The reply element
The reply element is responsible for establishing the details of returning a response
message to the requesting client partner service. Because this element is associated with the same
partnerLink element as its corresponding receive element, it repeats a number of the same
attributes. Attributes of reply element:
 partnerLink
 portType
 operation
 variable
 messageExchange
A potential companion reply element to the previously displayed receive element.
<reply partnerLink="client"
portType="tns:TimesheetSubmissionInterface"
operation="Submit"
variable="TimesheetSubmissionResponse"/>
The switch, case , and otherwise elements
The switch element establishes the scope of the conditional logic, wherein multiple case
constructs can be nested to check for various conditions using a condition attribute. When a
condition attribute resolves to "true," the activities defined within the corresponding case
construct are executed.
The otherwise element can be added as a catch all at the end of the switch construct.
Should all preceding case conditions fail, the activities within the otherwise construct are
executed.

<switch>
<case condition=
"getVariableData('EmployeeResponseMessage', 'ResponseParameter')=0">
...
</case>
<otherwise>
...
</otherwise>
</switch>
Note: It has been proposed that the switch , case , and otherwise elements be replaced with if,
elseif, and else elements in WS-BPEL 2.0.
The assign , copy , from , and to elements
This set of elements simply gives us the ability to copy values between process variables,
which allows us to pass around data throughout a process as information is received and
modified during the process execution.
<assign>
<copy>
<from variable="TimesheetSubmissionFailedMessage"/>
<to variable="EmployeeNotificationMessage"/>
</copy>
<copy>
<from variable="TimesheetSubmissionFailedMessage"/>
<to variable="ManagerNotificationMessage"/>
</copy>
</assign>

faultHandlers, catch , and catchAll elements
This construct can contain multiple catch elements, each of which provides activities that
perform exception handling for a specific type of error condition.
The faultHandlers construct hosting catch and catchAll child constructs.
<faultHandlers>
<catch faultName="SomethingBadHappened"
faultVariable="TimesheetFault">
...
</catch>
<catchAll>
...
</catchAll>
</faultHandlers>
Other WS-BPEL elements
The following table provides brief descriptions of other relevant parts of the WS-BPEL
language.
Element Description
compensationHandler A WS-BPEL process definition can define a compensation process that
kicks in a series of activities when certain conditions occur to justify a
compensation.
correlationSets This element is used to implement correlation, primarily to associate
messages with process instances. A message can belong to multiple
correlationSets.
empty This simple element allows you to state that no activity should occur for a
particular condition.
eventHandlers The eventHandlers element enables a process to respond to events during
the execution of process logic.

Element Description
exit See the terminate element description that follows.
flow A flow construct allows you to define a series of activities that can occur
concurrently and are required to complete after all have finished
executing. Dependencies between activities within a flow construct are
defined using the child link element.
pick Similar to the eventHandlers element, this construct also can contain
child onMessage and onAlarm elements but is used more to respond to
external events for which process execution is suspended .
scope Portions of logic within a process definition can be sub-divided into
scopes using this construct. This allows you to define variables,
faultHandlers, correlationSets, compensationHandler , and eventHandlers
elements local to the scope.
terminate This element effectively destroys the process instance. The WS-BPEL 2.0
specification proposes that this element be renamed exit.
throw Using the throw element allows you to explicitly trigger a fault state in
response to a specific condition.
wait The wait element can be set to introduce an intentional delay within the
process. Its value can be a set time or a predefined date.
while This useful element allows you to define a loop. It contains a condition
attribute that, as long as it continues resolving to "true," will continue to
execute the activities within the while construct.
WS – COORDINATION
The CoordinationContext element
This parent construct contains a series of child elements that each house a specific part of
the context information being relayed by the header.

<Envelope
xmlns="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsc=
"http://schemas.xmlsoap.org/ws/2002/08/wscoor"
xmlns:wsu=
"http://schemas.xmlsoap.org/ws/2002/07/utility">
<Header>
<wsc:CoordinationContext>
<wsu:Identifier>
...
</wsu:Identifier>
<wsu:Expires>
...
</wsu:Expires>
<wsc:CoordinationType>
...
</wsc:CoordinationType>
<wsc:RegistrationService>
...
</wsc:RegistrationService>
</wsc:CoordinationContext>
</Header>
<Body>
...
</Body>
</Envelope>
The activation service returns this CoordinationContext header upon the creation of a
new activity. As described later, it is within the CoordinationType child construct that the
activity protocol (WS-BusinessActivity, WS-AtomicTransaction) is carried. Vendor-specific

implementations of WS-Coordination can insert additional elements within the
CoordinationContext construct that represent values related to the execution environment.
The Identifier and Expires elements
These two elements originate from a utility schema used to provide reusable elements.
WS-Coordination uses the Identifier element to associate a unique ID value with the current
activity. The Expires element sets an expiry date that establishes the extent of the activity's
possible lifespan.
Identifier and Expires elements containing values relating to the header.
<Envelope
...
xmlns:wsu=
"http://schemas.xmlsoap.org/ws/2002/07/utility">
...
<wsu:Identifier>
http://www.xmltc.com/ids/process/33342
</wsu:Identifier>
<wsu:Expires>
2008-07-30T24:00:00.000
</wsu:Expires>
...
</Envelope>
The RegistrationService element
The RegistrationService construct simply hosts the endpoint address of the registration
service. It uses the Address element also provided by the utility schema.
The RegistrationService element containing a URL pointing to the location of the
registration service.
<wsc:RegistrationService>
<wsu:Address>
http://www.xmltc.com/bpel/reg

</wsu:Address>
</wsc:RegistrationService>
The CoordinationType element
Designating the WS-BusinessActivity coordination type
The specific protocol(s) that establishes the rules and constraints of the activity are
identified within the CoordinationType element. The URI values that are placed here are
predefined within the WS-BusinessActivity and WS-AtomicTransaction specifications.
This first example shows the CoordinationType element containing the WS-
BusinessActivity coordination type identifier. This would indicate that the activity for which the
header is carrying context information is a potentially long-running activity.
The CoordinationType element representing the WS-BusinessActivity protocol.
http://schemas.xmlsoap.org/ws/2004/01/wsba
Designating the WS-AtomicTransaction coordination type
In the next example, the CoordinationType element is assigned the WS-
AtomicTransaction coordination type identifier, which communicates the fact that the header's
context information is part of a short running transaction.
The CoordinationType element representing the WS-AtomicTransaction protocol
http://schemas.xmlsoap.org/ws/2003/09/wsat
WS – POLICY

The WS-Policy framework establishes a means of expressing service metadata beyond the
WSDL definition. Specifically, it allows services to communicate rules and preferences in
relation to security, processing, or message content. Policies can be applied to a variety of Web
resources, positioning this specification as another fundamental part of the WS-* extensions
The WS-Policy framework is comprised of the following three specifications:
 WS-Policy
 WS-PolicyAssertions
 WS-PolicyAttachments
The Policy element and common policy assertions
The Policy element establishes the root construct used to contain the various policy
assertions that comprise the policy. The WS-PolicyAssertions specification supplies the
following set of common, predefined assertion elements:
 TextEncoding: Dictates the use of a specific text encoding format.
 Language: Expresses the requirement or preference for a particular language.
 SpecVersion: Communicates the need for a specific version of a specification.
 MessagePredicate: Indicates message processing rules expressed using XPath
statements.
These elements represent assertions that can be used to structure basic policies around common
requirements. Policy assertions also can be customized, and other WS-* specifications may
provide supplemental assertions.
Each assertion can indicate whether its use is required or not via the value assigned to its
Usage attribute. A value of "Required" indicates that its conditions must be met. Additionally,
the use of the Preference attribute allows an assertion to communicate its importance in
comparison to other assertions of the same type.
The ExactlyOne element
This construct surrounds multiple policy assertions and indicates that there is a choice
between them, but that one must be chosen.
<wsp:Policy

xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
<wsp:ExactlyOne>
<wsp:SpecVersion wsp:Usage="wsp:Required"
wsp:Preference="10"
wsp:URI= "http://schemas.xmlsoap.org/ws/2004/03/rm"/>
wsp:Preference="1"
wsp:URI="http://schemas.xmlsoap.org/ws/2003/02/rm"/>
</wsp:ExactlyOne>
</wsp:Policy>
The All element
The All construct introduces a rule that states that all of the policy assertions within the
construct must be met. This element can be combined with the ExactlyOne element, where
collections of policy assertions can each be grouped into All constructs that are then further
grouped into a parent ExactlyOne construct. This indicates that the policy is offering a choice of
assertions groups but that the assertions in any one of the alternative All groups must be met.
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
<wsp:ExactlyOne ID="Invoice1">
<wsp:All>
wsp:Preference="10" wsp:URI=
"http://schemas.xmlsoap.org/ws/2004/03/rm"/>
<wsp:TextEncoding wsp:Usage="wsp:Required"
Encoding="iso-8859-5"/>
</wsp:All>
<wsp:All ID="Invoice2">
<wsp: SpecVersion wsp:Usage="wsp:Required"

wsp:Preference="1"
wsp:URI="http://schemas.xmlsoap.org/ws/2003/02/rm"/>
<wsp:TextEncoding wsp:Usage="wsp:Required" Encoding="iso-8859-5"/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
The Usage attribute
A number of WS-Policy assertion elements contain a Usage attribute to indicate whether
a given policy assertion is required. This attribute is a key part of the WS-Policy framework as
its values form part of the overall policy rules. The Usage attribute actually has a number of
settings worth knowing about, as shown in below Table.
Attribute
Value
Description
Required The assertion requirements must be met, or an error will be generated.
Optional The assertion requirements may be met, but an error will not be generated if
they are not met.
Rejected The assertion is unsupported.
Observed The assertion applies to all policy subjects.
Ignored The assertion will intentionally be ignored.
Table: Possible settings for the Usage attribute.
The Preference attribute
Policy assertions can be ranked in order of preference using this attribute. This is
especially relevant if a service provider is flexible enough to provide multiple policy alternatives
to potential service requestors.

The Preference attribute is assigned an integer value. The higher this value, the more
preferred the assertion. When this attribute is not used, a default value of "0" is assigned to the
policy assertion.
The PolicyReference element
The PolicyReference element is one way to simply link an element with one or more
policies. Each PolicyReference element contains a URI attribute that points to one policy
document or a specific policy assertion within the document. (The ID attribute of the policy or
grouping construct is referenced via the value displayed after the "#" symbol.)
If multiple PolicyReference elements are used within the same element, the policy
documents are merged at runtime.
<Employee ...>
<wsp:PolicyReference URI=
"http://www.xmltc.com/tls/policy1.xml#Employee1"/>
</Employee>
The PolicyURIs attribute
Alternatively, the PolicyURIs attribute also can be used to link to one or more policy
documents. The attribute is added to an element and can be assigned multiple policy locations.
As with PolicyReference, these policies are then merged at runtime.
<Employee wsp:PolicyURIs=
"http://www.xmltc.com/tls/policy1.xml#Employee1"
The PolicyAttachment element
Another way of associating a policy with a subject is through the use of the
PolicyAttachment construct. The approach taken here is that the child AppliesTo construct is
positioned as the parent of the subject elements. The familiar PolicyReference element then
follows the AppliesTo construct to identify the policy assertions that will be used.

<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference
xmlns:emp="http://www.xmltc.com/tls/employee">
<wsa:Address>
http://www.xmltc.com/tls/ep1
</wsa:Address>
<wsa:PortType>
emp:EmployeeInterface
</wsa:PortType>
<wsa:ServiceName>
emp:Employee
</wsa:ServiceName>
</wsa:EndpointReference>
</wsp:AppliesTo>
"http://www.xmltc.com/EmployeePolicy.xml"/>
</wsp:PolicyAttachment>
Additional types of policy assertions
It is important to note that policy assertions can be utilized and customized beyond the
conventional manner in which they are displayed in the preceding examples.
For example:
 Policy assertions can be incorporated into WSDL definitions through the use of a special
set of policy subjects that target specific parts of the definition structure. A separate
UsingPolicy element is provided for use as a WSDL extension.
 WS-ReliableMessaging defines and relies on WS-Policy assertions to enforce some of its
delivery and acknowledgement rules.
 WS-Policy assertions can be created to communicate that a Web service is capable of
participating in a business activity or an atomic transaction.

 A policy assertion can be designed to express a service's processing requirements in
relation to other WS-* specifications.
 WS-Policy assertions commonly are utilized within the WS-Security framework to
express security requirements.
WS- Security
The WS-Security framework provides extensions that can be used to implement message-level
security measures. These protect message contents during transport and during processing by
service intermediaries. Additional extensions implement authentication and authorization
control, which protect service providers from malicious requestors.
The WS-Security framework is comprised of numerous specifications. The important
specifications are:
 WS-Security
 XML-Encryption
 XML-Signature
The Security element (WS-Security)
This construct represents the fundamental header block provided by WS-Security.
The Security element can have a variety of child elements, ranging from XML-Encryption and
XML-Signature constructs to the token elements provided by the WS-Security specification
itself.
Security elements can be outfitted with actor attributes that correspond to SOAP actor roles. This
allows you to add multiple Security blocks to a SOAP message, each intended for a different
recipient.
The UsernameToken, Username, and Password elements (WS-Security)
The UsernameToken element provides a construct that can be used to host token information for
authentication and authorization purposes. Typical children of this construct are
the Username and Password child elements, but custom elements also can be added.

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Header>
<wsse:Security xmlns:wsse=
"http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:UsernameToken>
<wsse:Username>
rco-3342
</wsse:Username>
<wsse:Password Type="wsse:PasswordDigest">
93292348347
</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</Header>
<Body> ...
</Body>
</Envelope>
The BinarySecurityToken element (WS-Security)
Tokens stored as binary data, such as certificates, can be represented in an encoded format within
the BinarySecurityToken element.
The SecurityTokenReference element (WS-Security)
This element allows you to provide a pointer to a token that exists outside of the SOAP message
document.
Composing Security element contents (WS-Security)
As previously mentioned, the WS-Security specification positions the Security element as a
standardized container for header blocks originating from other security extensions.

The EncryptedData element (XML-Encryption)
This is the parent construct that hosts the encrypted portion of an XML document. If located at
the root of an XML document, the entire document contents are encrypted.
The EncryptedData element's Type attribute indicates what is included in the encrypted content.
For example, a value of http://www.w3.org/2001/04/xmlenc#Element indicates that the
element and its contents will be encrypted, whereas the value
of http://www.w3.org/2001/04/xmlenc#Content states that encryption will only be applied to the
content within the opening and closing tags.
The CipherData, CipherValue, and CipherReference elements (XML-Encryption)
The CipherData construct is required and must contain either a CipherValue element hosting
the characters representing the encrypted text or a CipherReference element that provides a
pointer to the encrypted values.
<InvoiceType>
<Number>
2322
</Number>
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<CipherData>
<CipherValue>
R5J7UUI78
</CipherValue>
</CipherData>
</EncryptedData>
<Date>
07.16.05
</Date>
</InvoiceType>

XML-Signature elements
A digital signature is a complex piece of information comprised of specific parts that each
represent an aspect of the document being signed. Therefore, numerous elements can be involved
when defining the construct that hosts the digital signature information.
Table : XML-Signature elements
Element Description
CanonicalizationMethod This element identifies the type of "canonicalization algorithm" used
to detect and represent subtle variances in the document content (such
as the location of white space).
DigestMethod Identifies the algorithm used to create the signature.
DigestValue Contains a value that represents the document being signed. This value
is generated by applying the DigestMethod algorithm to the XML
document.
KeyInfo This optional construct contains the public key information of the
message sender.
Signature The root element, housing all of the information for the digital
signature.
SignatureMethod The algorithm used to produce the digital signature. The digest and
canonicalization algorithms are taken into account when creating the
signature.
SignatureValue The actual value of the digital signature.
SignedInfo A construct that hosts elements with information relevant to
the SignatureValue element, which resides outside of this construct.
Reference Each document that is signed by the same digital signature is
represented by a Reference construct that hosts digest and optional
transformation details.

SOA SUPPORT IN J2EE
Fig: Layers of J2EE Platform
Platform Overview
The Java 2 Platform is divided into three major development and runtime platforms:
 The Java 2 Platform Standard Edition (J2SE) is designed to support the creation of
desktop applications.
 The Micro Edition (J2ME) is geared toward applications that run on mobile devices.
 The Java 2 Platform Enterprise Edition (J2EE) is built to support large-scale, distributed
solutions. J2EE has used extensively to build traditional n- tier applications with and
without Web technologies.
Three of the more significant specifications that pertain to SOA are:
 Java 2 Platform Enterprise Edition Specification This important specification
establishes the distributed J2EE component architecture and provides foundation
standards that J2EE product vendors are required to fulfill in order to claim J2EE
compliance.
 Java API for XML-based RPC (JAX-RPC) This document defines the JAX-RPC
environment and associated core APIs. It also establishes the Service Endpoint Model

used to realize the JAX-RPC Service Endpoint, one of the primary types of J2EE Web
services. (Now replaced by JAX-WS)
 Web Services for J2EE The specification that defines the vanilla J2EE service
architecture and clearly lays out what parts of the service environment can be built by the
developer, implemented in a vendor-specific manner, and which parts must be delivered
according to J2EE standards.
Architecture components
J2EE solutions inherently are distributed and therefore componentized. The following types of
components can be used to build J2EE Web applications:
 Java Server Pages (JSPs) Dynamically generated Web pages hosted by the Web server.
JSPs exist as text files comprised of code interspersed with HTML.
 Struts An extension to J2EE that allows for the development of Web applications with
sophisticated user -interfaces and navigation.
 Java Servlets These components also reside on the Web server and are used to process
HTTP request and response exchanges. Unlike JSPs, servlets are compiled programs.
 Enterprise JavaBeans (EJBs) The business components that perform the bulk of the
processing within enterprise solution environments. They are deployed on dedicated
application servers and can therefore leverage middleware features, such as transaction
support.
While the first two components are of more relevance to establishing the presentation layer of a
service-oriented solution, the latter two commonly are used to realize Web services.
Runtime environments
The J2EE environment relies on a foundation Java runtime to process the core Java parts of any
J2EE solution. In support of Web services, J2EE provides additional runtime layers that, in turn,
supply additional Web services specific APIs. Most notable is the JAX-RPC runtime, which
establishes fundamental services, including support for SOAP communication and WSDL
processing.

Additionally, implementations of J2EE supply two types of component containers that provide
hosting environments geared toward Web services-centric applications that are generally EJB or
servlet-based.
 EJB container This container is designed specifically to host EJB components, and it
provides a series of enterprise-level services that can be used collectively by EJBs
participating in the distributed execution of a business task.
 Web container A Web container can be considered an extension to a Web server and is
used to host Java Web applications consisting of JSP or Java servlet components. Web
containers provide runtime services geared toward the processing of JSP requests and
servlet instances.
Programming languages
 As its name implies, the Java 2 Platform Enterprise Edition is centered around the Java
programming language. Different vendors offer proprietary development products that
provide an environment in which the standard Java language can be used to build Web
services.
Service providers
J2EE Web services are typically implemented as servlets or EJB components. Each option is
suitable to meet different requirements but also results in different deployment configurations, as
explained here:
 JAX-RPC Service Endpoint When building Web services for use within a Web
container, a JAX-RPC Service Endpoint is developed that frequently is implemented as a
servlet by the underlying Web container logic.
 EJB Service Endpoint The alternative is to expose an EJB as a Web service through an
EJB Service Endpoint. This approach is appropriate when wanting to encapsulate existing
legacy logic or when runtime features only available within an EJB container are
required. To build an EJB Service Endpoint requires that the underlying EJB component
be a specific type of EJB called a Stateless Session Bean.

Also a key part of either service architecture is an underlying model that defines its
implementation, called the Port Component Model. As described in the Web Services for J2EE
specification, it establishes a series of components that comprise the implementation of a J2EE
service provider, including:
 Service Endpoint Interface (SEI) A Java-based interpretation of the WSDL definition
that is required to follow the JAX-RPC WSDL-to-Java mapping rules to ensure
consistent representation.
 Service Implementation Bean A class that is built by a developer to house the custom
business logic of a Web service. The Service Implementation Bean can be implemented
as an EJB Endpoint (Stateless Session Bean) or a JAX-RPC Endpoint (servlet). For an
EJB Endpoint, it is referred to as an EJB Service Implementation Bean and therefore
resides in the EJB container. For the JAX-RPC Endpoint, it is called a JAX-RPC Service
Implementation Bean and is deployed in the Web container.
Service requestors
The JAX-RPC API also can be used to develop service requestors. It provides the ability to
create three types of client proxies, as explained here:
 Generated stub The generated stub (or just "stub") is the most common form of service
client. It is auto-generated by the JAX-RPC compiler (at design time) by consuming the
service provider WSDL, and producing a Java-equivalent proxy component.
 Dynamic proxy and dynamic invocation interface Two variations of the generated stub
are also supported. The dynamic proxy is similar in concept, except that the actual stub is
not created until its methods are invoked at runtime. Secondly, the dynamic invocation
interface bypasses the need for a physical stub altogether and allows for fully dynamic
interaction between a Java component and a WSDL definition at runtime.
Service agents
Vendor implementations of J2EE platforms often employ numerous service agents to perform a
variety of runtime filtering, processing, and routing tasks. A common example is the use of
service agents to process SOAP headers.

To support SOAP header processing, the JAX-RPC API allows for the creation of specialized
service agents called handlers, runtime filters that exist as extensions to the J2EE container
environments. Handlers can process SOAP header blocks for messages sent by J2EE service
requestors or for messages received by EJB Endpoints and JAX-RPC Service Endpoints.
Platform extensions
Different vendors that implement and build around the J2EE platform offer various platform
extensions in the form of SDKs that extend their development tool offering. The technologies
supported by these toolkits, when sufficiently mature, can further support contemporary SOA.
Following are two examples of currently available platform extensions.
 IBM Emerging Technologies Toolkit A collection of extensions that provide prototype
implementations of a number of fundamental WS-* extensions, including WS-
Addressing, WS-ReliableMessaging, WS-MetadataExchange, and WS-Resource
Framework.
 Java Web Services Developer Pack A toolkit that includes both WS-* support as well as
the introduction of new Java APIs. Examples of the types of extensions provided include
WS-Security (along with XML-Signature), and WS-I Attachments.
Primitive SOA support
The J2EE platform provides a development and runtime environment through which all primitive
SOA characteristics can be realized, as follows.
 Service encapsulation
The distributed nature of the J2EE platform allows for the creation of independent units
of processing logic through Enterprise Java Beans or servlets. Both EJBs and servlets can
be encapsulated using Web services.
 Loose coupling
The use of interfaces within the J2EE platform allows for the abstraction of metadata
from a component's actual logic. When complemented with an open or proprietary
messaging technology, loose coupling can be realized.
 Messaging

Prior to the acceptance of Web services, the J2EE platform supported messaging via the
JMS standard, allowing for the exchange of messages between both servlets and EJB
components. With the arrival of Web services support, the JAX-RPC API provides the
means of enabling SOAP messaging over HTTP.
Support for service-orientation principles
The J2EE platform supports and implements the first-generation Web services technology set.
There are four principles of service-orientation not automatically provided by Web services but
realized through J2EE.
 Autonomy
JAX-RPC Service Endpoints exist as standalone servlets and retain complete autonomy.
EJB Service Endpoints are required to exist as Stateless Session Beans, which supports
autonomy within the immediate endpoint logic.
 Reusability
Enterprise Java Beans natively supports object-orientation. As a result, reusability is
achievable on a component level. Reusability on a service level comes down to the
design of a service's business logic and endpoint.
 Statelessness
JAX-RPC Service Endpoints can be designed to exist as stateless servlets, but the JAX-
RPC API does provide the means for the servlet to manage state information through the
use of the HTTPSession object. J2EE supports statelessness through the use of Stateless
Session Bean,.
 Discoverability
Service discovery as part of a J2EE SOA is directly supported through JAXR, an API that
provides a programmatic interface to XML-based registries, including UDDI repositories.
Contemporary SOA support
Extending an SOA beyond the primitive boundary requires a combination of design and
available technology in support of the design. Because WS-* extensions have not yet been
standardized by the vendor-neutral J2EE platform, they require the help of vendor-specific tools
and features.

 Based on open standards
The Web services subset of the J2EE platform supports industry standard Web services
specifications, including WSDL, SOAP, and UDDI. The support for the WS-I Basic
Profile also has been provided. Further, the API specifications that comprise the J2EE
platform are themselves open standards, which further promotes vendor diversity.
 Supports vendor diversity
Java components can be designed for deployment mobility across different J2EE server
products.
Further, by designing services to be WS-I Basic Profile compliant, vendor diversity
beyond J2EE platforms is supported. For example, an organization that has built an SOA
based on J2EE technology may choose to build another using the .NET framework. Both
environments can interoperate if their respective services conform to the same open
standards.
 Intrinsically interoperable
Interoperability is, to a large extent, a quality deliberately designed into a Web service.
Aside from service interface design characteristics, conformance to industry-standard
Web services specifications is critical to achieving interoperable SOAs, especially when
interoperability is required across enterprise domains.
 Promotes federation
Building an integration architecture with custom business services and legacy wrapper
services can be achieved using basic J2EE APIs and features.
J2EE Connector Architecture (JCA), a structured, adapter-centric integration architecture
through which resource adapters are used to bridge gaps between J2EE platforms and
other environments.
 Architecturally composable
Given the modular nature of supporting API packages and classes and the choice of
service-specific containers, the J2EE platform is intrinsically composable.
 Extensibility
Because J2EE environments are implemented by different vendors, extensibility can
sometimes lead to the use of proprietary extensions. While still achieving extensibility

within the vendor environment, this can limit the portability and openness of Java
solutions.
 Supports service-oriented business modeling
There is no inherent support for service-oriented business modeling within J2EE. Instead,
orchestration services and design tools are provided by vendors to supplement the J2EE
Web services development and runtime environment.
 Logic-level abstraction
JAX-RPC Service Endpoints and EJB Service Endpoints can be designed into service
layers that abstract application-specific or reusable logic. Further, entire J2EE solutions
can be exposed through these types of services, when appropriate.
 Organizational agility and enterprise-wide loose coupling
The creation of service layers is possible with the help of a vendor-specific orchestration
server. Although the orchestration offering is proprietary, the fact that other Web services
are J2EE standardized further promotes an aspect of agility realized through the vendor
diverse nature of the J2EE marketplace.
APIs
J2EE contains several APIs for programming functions in support of Web services. The classes
that support these APIs are organized into a series of packages. Here are some of the APIs
relevant to building SOA.
JAX-WS (Java API for XML-Based Web Services)
 JAX-WS 2.0 is the center of a newly re-architected API stack for web services, which
also includes Java Architecture for XML Binding (JAXB) 2.0 and SOAP with
Attachments API for Java (SAAJ) 1.3.
 It replaces the place of Java API for XML-Based RPC (JAX-RPC).
 Put briefly, the JAX-WS architecture is an easier-to-understand architecture for web
services development. In previous web services offerings, the functionalities of the earlier
JAX-RPC and JAXB APIs overlapped quite a bit. When JAXB 1.x emerged after JAX-
RPC, and as data-binding functionality became more comprehensive with enhanced
standards such as XML Schema and Relax NG, Java platform developers recognized the
need to separate the web services definition from the data-binding components.

 You can use JAX-WS to build web applications and web services, incorporating the
newer XML-based web services functionality.
 JAX-WS Packages
 javax.xml.ws - This package contains the core JAX-WS APIs
 javax.xml.soap - Provides the API for creating and building SOAP messages.
 javax.jws
Using JAX-WS 2.0 to Create a Simple Web Service
package hello;
public class CircleFunctions {
public double getArea(double radius) {
return java.lang.Math.PI * (r * r);
}
public double getCircumference(double radius) {
return 2 * java.lang.Math.PI * r; }}
To export these methods, you must add two things: an import statement for
the javax.jws.WebService package and a @WebService annotation at the beginning that tells the
Java interpreter that you intend to publish the methods of this class as a web service.
package hello;
import javax.jws.WebService;
@WebService
public class CircleFunctions {
public double getArea(double r) {
return java.lang.Math.PI * (r * r);
}

public double getCircumference(double r) {
return 2 * java.lang.Math.PI * r;
}
}
 Now, compile the source code normally using javac. However, you must perform one
more step: Call the wsgen tool, as follows.
> wsgen –cp . hello.CircleFunctions
wsgen
The wsgen tool generates JAX-WS portable artifacts used in JAX-WS web services. The tool
reads a web service endpoint class and generates all the required artifacts for web service
deployment, and invocation.
Note: One can also use NetBeans IDE to create web services.
Other Features
JAX-WS RI 2.2.5 is the latest Implementation version.
 Development Tools
o WSDL to Java generator
 wsimport command line tool, ant task and Maven2 plugin
o Java to WSDL generator
 wsgen command line tool, ant Task and Maven2 plugin
 Standards
o Web Services Addressing 1.0 – Core, SOAP Binding, Metadata, WSDL Binding
(RI specific support)
o WS-Addressing - Member Submission
o SOAP 1.1 and 1.2
o REST and XML/HTTP
o WS-I Basic Profile 1.2 and 2.0
o WS-I Simple SOAP Binding Profile 1.0

o WS-I Attachment Profile 1.0
o MTOM
 Extensions
o Web Services Interoperable Technologies ( WSIT) - enables .NET 3.x
interoperability
 WS-ReliableMessaging
 WS-Policy
 WS-MEX
 WS-Security/WS-Security Policy
 WS-Trust/WS-Secure Conversation
 WS-AT/WS-Tx (Supported only on Glassfish v2)
 SOAP/TCP
JAXP (Java API for XML Processing)
 The Java API for XML Processing (JAXP) is for processing XML data using applications
written in the Java programming language.
 JAXP leverages the parser standards Simple API for XML Parsing (SAX) and Document
Object Model (DOM) so that you can choose to parse your data as a stream of events or
to build an object representation of it.
 JAXP also supports the Extensible Stylesheet Language Transformations (XSLT)
standard, giving you control over the presentation of the data and enabling you to convert
the data to other XML documents or to other formats, such as HTML.
 JAXP also provides namespace support, allowing you to work with DTDs that might
otherwise have naming conflicts.
 Designed to be flexible, JAXP allows you to use any XML-compliant parser from within
your application. It does this with what is called a pluggability layer, which lets you plug
in an implementation of the SAX or DOM API.
 The pluggability layer also allows you to plug in an XSL processor, letting you control
how your XML data is displayed.

Overview of the Packages
The SAX and DOM APIs are defined by the XML-DEV group and by the W3C, respectively.
The libraries that define those APIs are as follows:
 javax.xml.parsers: The JAXP APIs, which provide a common interface for different
vendors' SAX and DOM parsers.
 org.w3c.dom: Defines the Document class (a DOM) as well as classes for all the
components of a DOM.
 org.xml.sax: Defines the basic SAX APIs.
 javax.xml.transform: Defines the XSLT APIs that let you transform XML into other
forms.
 javax.xml.stream: Provides StAX-specific transformation APIs.
 The Simple API for XML (SAX) is the event-driven, serial-access mechanism that does
element-by-element processing. The API for this level reads and writes XML to a data
repository or the web. For server-side and high-performance applications, you will want
to fully understand this level. But for many applications, a minimal understanding will
suffice.
 The DOM API is generally an easier API to use. It provides a familiar tree structure of
objects. You can use the DOM API to manipulate the hierarchy of application objects it
encapsulates. The DOM API is ideal for interactive applications because the entire object
model is present in memory, where it can be accessed and manipulated by the user.
 On the other hand, constructing the DOM requires reading the entire XML structure and
holding the object tree in memory, so it is much more CPU- and memory-intensive. For
that reason, the SAX API tends to be preferred for server-side applications and data
filters that do not require an in-memory representation of the data.
 The XSLT APIs defined in javax.xml.transform let you write XML data to a file or
convert it into other forms. As shown in the XSLT section of this tutorial, you can even
use it in conjunction with the SAX APIs to convert legacy data to XML.
 Finally, the StAX APIs defined in javax.xml.stream provide a streaming Java technology-
based, event-driven, pull-parsing API for reading and writing XML documents. StAX
offers a simpler programming model than SAX and more efficient memory management
than DOM.

Java Architecture for XML Binding (JAXB)
 The typical way to access and use an XML document (that is, a file containing XML-
tagged data) through the Java programming language is:
 Through the use of parsers that conform to the Simple API for XML (SAX) or
the Document Object Model (DOM). Both of these parsers are provided by Java
API for XML Processing (JAXP).
 Now developers have another Java API at their disposal that can make it easier to access
XML documents: Java Architecture for XML Binding (JAXB).
An Example: Accessing an XML Document
Suppose you need to develop a Java application that accesses and displays data in XML
documents such as books.xml. These documents contain data about books, such as book name,
author, description, and ISBN identification number. You could use the SAX or DOM approach
to access an XML document and then display the data. For example, suppose you took the SAX
approach. In that case, you would need to:
 Write a program that creates a SAX parser and then uses that parser to parse the XML
document. The SAX parser starts at the beginning of the document. When it encounters
something significant (in SAX terms, an "event") such as the start of an XML tag, or the
text inside of a tag, it makes that data available to the calling application.
 Create a content handler that defines the methods to be notified by the parser when it
encounters an event. These methods, known as callback methods, take the appropriate
action on the data they receive.
Using JAXB, you would:
 Bind the schema for the XML document.
 Unmarshal the document into Java content objects. The Java content objects represent
the content and organization of the XML document, and are directly available to your
program.
After unmarshalling, your program can access and display the data in the XML document simply
by accessing the data in the Java content objects and then displaying it. There is no need to create
and use a parser and no need to write a content handler with callback methods. What this means
is that developers can access and process XML data without having to know XML or XML
processing.

Bind the Schema
 JAXB simplifies access to an XML document from a Java program by presenting the
XML document to the program in a Java format. The first step in this process is to bind
the schema for the XML document into a set of Java classes that represents the schema.
 Binding a schema means generating a set of Java classes that represents the schema. All
JAXB implementations provide a tool called a binding compiler to bind a schema.
Unmarshal the Document
 Unmarshalling an XML document means creating a tree of content objects that represents
the content and organization of the document. The content tree is not a DOM-based tree.
In fact, content trees produced through JAXB can be more efficient in terms of memory
use than DOM-based trees.
 Another important feature of JAXB is that you can have it validate the source data
against the associated schema (schemas created by XML Schema Language or DTD) as
part of the unmarshalling operation.
Java API for XML Registries (JAXR)
 The Java API for XML Registries (JAXR) provides a uniform and standard Java API for
accessing different kinds of XML Registries. An XML registry is an enabling
infrastructure for building, deploying, and discovering Web services.
 Currently there are a variety of specifications for XML registries including, most notably,
the ebXML Registry and Repository standard, which is being developed by OASIS and
U.N./CEFACT, and the UDDI specification, which is being developed by a vendor
consortium.

JAXR interoperability with any client to any registry
 JAXR enables Java software programmers to use a single, easy-to-use abstraction API to
access a variety of XML registries. Simplicity and ease of use are facilitated within
JAXR by a unified JAXR information model, which describes content and metadata
within XML registries.
 JAXR provides rich metadata capabilities for classification and association, as well as
rich query capabilities. As an abstraction-based API, JAXR gives developers the ability
to write registry client programs that are portable across different target registries.
Similarly, JAXR also enables value-added capabilities beyond those of the underlying
registries.
 The current version of the JAXR specification includes detailed bindings between the
JAXR information model and both the ebXML Registry and the UDDI Registry v2.0
specifications.
 JAXR works in synergy with related Java APIs for XML, such as JAXP, JAXB, JAX-
RPC, and SAAJ, to enable Web services within the Java 2 Platform, Enterprise Edition
(J2EE).
 javax.xml.registry: A series of registry access functions that support the JAXR API.
 javax.xml.registry.infomodel: Classes that represent objects within a registry.
Registry Provider
A registry provider provides an implementation of a registry specification or standard. Examples
include:

 A UDDI registry provider that implements the UDDI registry specifications
 An ebXML registry provider that implements the ebXML Registry specifications
A registry provider is not required to implement the JAXR specification.
JAXR Provider
A JAXR Provider provides an implementation of the JAXR specification. Typically, a JAXR
provider is implemented to access an existing registry provider.
JAXR Client
A JAXR client is a Java program that uses the JAXR API to access the services provided by a
JAXR provider.
Repository item
It is used to refer to actual content (e.g. an XML Schema document, as opposed to metadata
about the XML Schema document) submitted to a registry.
Repository item instance
It is used to refer to a single instance of some repository item.
Registry object
It is used to refer to metadata that catalogs or describes a repository item. It is reflected by the
RegistryObject interface in the JAXR information model and its sub-interfaces.
JAX-RPC
 Java APIs for XML-based Remote Procedure Call (JAX-RPC) help with Web service
interoperability and accessibility by defining Java APIs that Java applications use to
develop and access Web services.
 The most established and popular SOAP processing API, supporting both RPC-literal and
document-literal request-response exchanges and one-way transmissions.
 JAX-RPC fully embraces the heterogeneous nature of Web services -- it allows a JAX-
RPC client to talk to another Web service deployed on a different platform and coded in a
different language.
 Similarly, it also allows clients on other platforms and coded in different languages to
talk to a JAX-RPC service. JAX-RPC also defines the mapping between WSDL service
descriptions and Java interfaces.

 JAX-RPC hides the complexity of underlying protocols and message-level processing
from application developers crafting Web services using the Java 2 platform.
 The API combines XML with Remote Procedure Call (RPC), which is a mechanism
enabling clients to execute procedures on distributed or remote systems, so that
developers can build Web services and clients.
 The JAX-RPC remote procedure calls are represented by an XML infoset and they are
carried over a network transport. While the JAX-RPC APIs rely on a XML-based
protocol and a network transport, the APIs themselves are independent of a specific
protocol or transport.
 The JAX-RPC implementation relies on the SOAP 1.1 protocol and HTTP 1.1 network
transport.
Example packages that support this API include:
 javax.xml.rpc and javax.xml.rpc.server: These packages contain a series of core functions
for the JAX-RPC API.
 javax.xml.rpc.handler and javax.xml.rpc.handler.soap: API functions for runtime
message handlers are provided by these collections of classes.
 javax.xml.soap and javax.xml.rpc.soap: API functions for processing SOAP message
content and bindings.
WSIT
Web Services Interoperability Technologies (WSIT) — a product of Sun Microsystems web
services interoperability effort to develop Java clients and service providers that interoperate
with Microsoft .NET clients and service providers.
Sun is working closely with Microsoft to ensure interoperability of web services enterprise
technologies such as message optimization, reliable messaging, and security. The initial release
of WSIT is a product of this joint effort. WSIT is an implementation of a number of open web
services specifications to support enterprise features. In addition to message optimization,
reliable messaging, and security, WSIT includes a bootstrapping and configuration technology.
The below figure shows the underlying services that were implemented for each technology.

Fig: WSIT Web Services Features
 Bootstrapping and configuration consists of using a URL to access a web service,
retrieving its WSDL file, and using the WSDL file to create a web service client that can
access and consume a web service.
 Message Optimization: XML needs to be optimized for web services using Message
Optimization technology. It ensures that web services messages are transmitted over the
Internet in the most efficient manner when large binary objects are encoded into XML
format.
 Reliable Messaging Technology: Reliability is measured by a system’s ability to deliver
messages from point A to point B without error. The reliable messaging technology
ensures that messages in a given message sequence are delivered at least once and not
more than once and optionally in the correct order. When messages in a given sequence
are lost in transit or delivered out of order, this technology enables systems to recover
from such failures.
 Security Technology: WSIT implements WS-Security so as to provide interoperable
message content integrity and confidentiality, even when messages pass through
intermediary nodes before reaching their destination endpoint.
WSIT also enhances security by implementing WS-Secure Conversation, which enables
a consumer and provider to establish a shared security context when a multiple-message-
exchange sequence is first initiated. Subsequent messages use derived session keys that

increase the overall security while reducing the security processing overhead for each
message.
Further, WSIT implements two additional features to improve security in web services:
 Web Services Security Policy—Enables web services to use security assertions to
clearly represent security preferences and requirements for web service endpoints.
 Web Services Trust—Enables web service applications to use SOAP messages to
request security tokens that can then be used to establish trusted communications
between a client and a web service.
Java API for XML Messaging (JAXM) An asynchronous, document-style SOAP messaging
API that can be used for one-way and broadcast message transmissions (but can still facilitate
synchronous exchanges as well).
SOAP with Attachments API for Java (SAAJ) Provides an API specifically for managing
SOAP messages requiring attachments. The SAAJ API is an implementation of the SOAP
with Attachments (SwA) specification.
Java Message Service API (JMS) A Java-centric messaging protocol used for traditional
messaging middleware solutions and providing reliable delivery features not found in typical
HTTP communication.

IT6801 Service Oriented Architecture
Unit 1 - Prepared by CSE Department, RMKCET Page 1
1. Define XML.
Extensible Markup Language (XML) is a simple, very flexible text format derived
from SGML. Originally designed to meet the challenges of large-scale electronic
publishing, XML is also playing an increasingly important role in the exchange of a
wide variety of data on the Web and elsewhere.
2. Give the rules for well-formed documents in XML.
 All XML elements must have a closing tag
 XML tags are case sensitive
 All XML elements must have 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
3. Define XML Vocabulary.
An XML vocabulary is created by specifying a complete description of the elements
and attributes for a specific type of XML document.
(Eg) RSS, XSLT, SOAP, SVG etc
4. Define XML namespace.
An XML namespace is a collection of element and attribute names associated with a
particular XML vocabulary (SOAP) through an absolute URI known as the
namespace name.
5. Mention the need for XML namespace.
It is used to avoid name conflicts when XML elements defined by one vocabulary is
embedded within an XML document written using another vocabulary.
6. Define CDATA.
CDATA stands for Character Data. CDATA sections provide a way to tell the parser
that there is no markup in the characters contained by the CDATA section. This
makes it much easier to create documents containing sections where markup

characters might appear, but where no markup is intended. Everything inside a
CDATA section is ignored by the parser.
7. List the benefits of XML.
 Openness (W3C Standard)
 Extensibility (new tags can be created)
 Self-description (because of meta-data)
 Machine and human readable
 Interoperable (among different platform)
8. List the applications of XML.
 Data Interchange Format
 Web development
 Documentation (or) Document Publishing
 Database Development
 Configuration Files
 Web Services
9. Compare well-formed and valid XML document.
S.No. Well-Formed Document Valid XML Document
1 An XML document is well formed if
it follows all the syntax rules of
XML.
An XML document that conforms to
DTD or an XML Schema is said to
be valid XML document.
2 Not all well-formed XML documents
are valid.
A valid XML document is also well-
formed.
10. Compare Validating and Non-Validating Parser.
S.No. Non-Validating Parser Validating Parser
1 A non-validating parser is required to
verify that an input XML document
is well formed or not.
A validating parser requires that any
document it parses contain a DTD or
XSD. The validating parser will read
the DTD or XSD, verify that the
document conforms with DTD or

XSD, and also verify that the
document meets validity constraints
defined by the XML
recommendation.
2 Non-validating parsers have the
advantage that they will generally run
faster than validating parsers because
they perform less validation.
An advantage of validating parsers is
that every correct implementation of
a validating parser should produce
essentially the same results when
parsing a given XML document.
11. Define entity reference. Give example.
An entity reference is a group of characters used in text as a substitute for a single
specific character that is also a markup delimiter in XML. Entity references always
begin with an ampersand (&) and end with a semicolon (;).
Example: < (<) less than, & (&) Ampersand
12. Mention the usage of keywords SYSTEM and PUBLIC in DTD.
Both are used to refer an external DTD in the xml document.
13. Compare DTD and XML Schema.
S.No. Document Type Definition XML Schema Definition (XSD)
1 DTD is written using Extended Backus-
Naur Form (EBNF) grammar.
XSD is written using XML itself.
2 Namespaces are not supported by DTD. Namespaces are supported by XSD.
3 DTD supports only string data type
(parsed character).
XSD supports multiple data types.
14. Define XPath.
XML Path Language (XPath) is a syntax for specifying a collection of elements or
other information contained within an XML document.
15. Define XPointer.

XPointer is an extension to XPath. It is also used to locate elements or data in the
XML document.
16. Define XLink.
XLink is a W3C specification which describes methods for allowing elements to be
inserted into XML documents in order to create and describe links between resources,
whether internal or external to the original document.
17. List some XSD Indicators.
 Content models (Order)
o xs:sequence, xs:all, xs:choice
 Group Indicators
o xs:group, xs:attributeGroup
 Occurrence Indicators
o minOccurs, maxOccurs
18. List some XLink attributes.
 xlink:role, xlink:href, xlink:type, xlink:from, xlink:to
19. Define location path.
An XPath expression that represents one or more nodes within an XPath parse tree is
known as a location path. A location path can be absolute or relative. The location
path consists of one or more location steps, each separated by a slash.
The syntax for a location step is: axisname::nodetest[predicate]
Example: /bookstore/book/title
20. Define the terms Axis, node test and predicate.
 Axis: It specifies the tree relationship between the nodes selected by the location
step and the context node.
 Node Test: It specifies the node type and expanded-name of the nodes selected by
the location step.
 Predicate: It uses arbitrary expressions to further refine the set of nodes selected
by the location step.

1. Define a XML parser.
XML Parser or Processor is a software module that is used to read XML documents
and provide access to their content and structure.
2. Define DOM.
The DOM defines a standard for accessing documents (HTML and XML). The DOM
is a platform and language-neutral interface that allows programs and scripts to
dynamically access and update the content, structure, and style of a document.
3. Define DOM Traversal.
Traversal is a convenient way to walk through a DOM tree and select specific nodes.
This is useful when you want to find certain elements and perform operations on
them.
4. Define DOM Range.
Range interfaces provide a convenient way to select, delete, extract, and insert
content. A range consists of two boundary points corresponding to the start and the
end of the range.
5. List the fundamental DOM Interfaces.
 Node
 NodeList
 Document
 Element
 Text
6. List the disadvantages of DOM.
 It is memory intensive since the entire document is loaded into the memory.
 It is slower.
7. Define SAX.
SAX (Simple API for XML) is an event-based parser for XML documents. The parser
sends event notifications to the registered listeners whenever events like reading

element start tag, reading an end tag, reading text contained within an element etc.
occurs.
8. Compare Tree based and Event based parsing.
S.No. DOM (Tree based) SAX (Event based)
1
1
Using DOM approach, entire XML
document is read and parsed into a
tree representation and then it is
processed.
Using SAX approach, each element
is read separately and corresponding
event is generated.
2
2
More memory and CPU time is used. Comparatively less computationally
expensive.
9. List the disadvantages of SAX.
 Since SAX parsing is “single pass”, you can’t back up to an earlier part of the
document any more than you can back up from a serial data stream.
 There is no random access.
10. Define content handler in SAX.
Content handler or Event Listeners receives notifications whenever an event occurs. A
ContentHandler is a specific SAX interface, located at org.xml.sax.ContentHandler. It
has callback methods to receive these event notifications from the parsers.
11. Mention the use of LexicalHandler.
LexicalHandler is an interface that is part of the org.xml.sax.ext package. It is used to
capture events like comments, CDAT, DTD and entities.
12. Define JAXP.
The Java API for XML Processing (JAXP) enables applications to parse, transform,
validate and query XML documents using an API that is independent of a particular
XML processor implementation. JAXP provides a pluggability layer to enable
vendors to provide their own implementations without introducing dependencies in
application code.

13. Define XSL.
Extensible Stylesheet Language (XSL) is a language for expressing style sheets. It
describes how to display an XML document of a given type. It consists of three parts:
 XSLT
 XSL – FO
 XPath
14. Define XSLT.
Extensible Stylesheet Language Transformations (XSLT) is a language for
transforming XML documents into other XML documents, or other formats such as
HTML for web pages, plain text or into XSL Formatting Objects, which may
subsequently be converted to other formats, such as PDF, PostScript and PNG.
15. Define XSL formatting.
XSL Formatting Objects (XSL-FO) provides a way of describing the presentation of
an XML document. The main emphasis is on the document layout and structure. This
includes the dimensions of the output document, including page headers, footers, and
margins. XSL-FO also allows the developer to define the formatting rules for the
content, such as font, style, color, and positioning.
16. Write a simple stylesheet using XSL.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml">
<xsl:template match="students">
<html><body>
<strong>RegisterNumber:</strong>
<xsl:value-of select="registernumber" />
</body></html>
</xsl:template>
</xsl:stylesheet>

17. Define JAXB.
Java Architecture for XML Binding (JAXB) is an API to convert XML document into
Java objects and vice versa. There is no need to create or use parsers and thus
application programs can easily access and manipulate XML document.
18. Define binding the schema.
Binding a schema means generating a set of Java classes that represents the
schema(schema for XML document). A binding compiler provided by JAXB would
bind the schema.
19. Define marshaling and unmarshalling in JAXB.
Parsing XML document into appropriate java objects is known as unmarshalling. The
process of generating XML document from java objects is known as marshalling.
20. List the XML database solutions.
 XML database mapping (Relation database with options to convert into XML)
 Native XML Support (NXD - native XML database)

1. Define SOA.
“Service-oriented architecture” is a term that represents a model in which automation
logic is decomposed into smaller, distinct units of logic known as services. This
model should adhere to the principles of service-orientation like loose coupling,
autonomy, reusability, composability, statelessness, discoverability, abstraction etc.
2. Define Service.
It is a unit of processing logic in Service-Orientation environment. Collectively, these
units comprise a larger piece of business automation logic. Individually, these units
can be distributed.
3. What are the benefits of SOA?
 Interoperability - The cost and effort of cross-application integration is
significantly lowered
 Inherent reuse – It lowers the cost and effort of building service-oriented
solutions.
 Leveraging the legacy investment – The need for legacy systems to be
replaced is potentially lessened.
 Organizational agility - The cost and effort to respond and adapt to business or
technology-related change is reduced.
4. Define Architecture.
It is a baseline application that could act as a template for all other applications. It
specifically explains the technology, boundaries, rules, limitations, and design
characteristics that apply to all solutions based on this template.
5. List and define architecture types.
Application Architecture
 It is a technical blueprint for providing solutions.
 An organization can have several application architectures.
Enterprise Architecture

 It is a master specification providing high-level overview of all forms of
heterogeneity that exist within an enterprise. It also contains definition of the
supporting architecture.
 Any changes to enterprise architecture directly affect application architectures.
6. Compare Primitive SOA & Contemporary SOA.
S.No. Primitive SOA Contemporary SOA
1
Primitive SOA is the model of the
baseline service-oriented architecture
that is suitable to be realized by any
vendor.
Contemporary SOA is the classification
that is used to represent the extensions to
the primitive SOA implementations.
2
It is achieved by basic service-oriented
principles and Web Services
technology.
It is achieved by advanced design
techniques and Web Services extensions,
besides what is needed for primitive SOA.
7. List out some characteristics of Contemporary SOA.
 Contemporary SOA increases quality of service.
 Contemporary SOA is fundamentally autonomous.
 Contemporary SOA is based on open standards.
 Contemporary SOA supports vendor diversity.
 Contemporary SOA fosters intrinsic interoperability.
 Contemporary SOA promotes discovery.
 Contemporary SOA promotes loose coupling throughout the enterprise.
 Contemporary SOA promotes organizational agility.
8. How loose coupling concept achieved in SOA?
Loose coupling is achieved through the use of service contracts that allow services to
interact within predefined parameters.
9. How do components in an SOA inter-relate?
 An operation sends and receives messages to perform work.
 A service group is a collection of related operations.

 A process instance can compose service.
10. List out some common principles of service orientation.
 Loose Coupling
 Service Contract
 Autonomy
 Abstraction
 Reusability
 Composability
 Statelessness
 Discoverability
11. List out the Logical components of the Web services framework.
 SOAP Messages
 Web Service Operations
 Web Services
 Activity
12. List out and define the components of SOA.
 Messages: It is unit of communication. It represents the data required to
complete some or all parts of a unit of work.
 Operations: It is unit of work. It represents the logic required to process
messages in order to complete a unit of work.
 Services: It is unit of processing logic. It represents a logically grouped set of
operations capable of performing related units of work.
 Process: It is unit of automation logic. It represents a large piece of work that
requires the completion of smaller units of work.
13. What are coarse grained services?
It is a composition of many smaller-grained services. Usually an application service
can compose other, smaller-grained application services (such as proxy services) into
a unit of coarse-grained application logic.

14. Define Wrapper service.
Wrapper services most often are utilized for integration purposes. They consist of
services that encapsulate some or all parts of a legacy environment to expose legacy
functionality to service requestors.
15. Define loose coupling.
It is a relationship between two entities (services) that minimizes dependencies and
only requires that they retain an awareness of each other.
(Alternatively) Loose coupling is a condition wherein a service acquires knowledge of
another service while still remaining independent of that service.
16. Define Autonomy.
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.
17. Define Hybrid service.
Services that contain both application and business logic can be referred to as hybrid
application services or just hybrid services.
18. Define process service.
It is a service that implements a business process by orchestrating other services. It
resides in Orchestration Service layer.
19. Define Controller service.
It is a service that is responsible for service composition. It assembles and coordinates
independent services to execute overall business task.
20. Define Utility service.
It is a service designed for reusability and it is generic in nature.

1. Define Web Services.
A Web service is a software system designed to support interoperable machine-to-
machine interaction over a network. It has an interface described in a machine-
processable format (specifically WSDL). Other systems interact with the Web service
in a manner prescribed by its description using SOAP messages.
2. List out different service roles.
 Service Provider
 Service Requestor (Service Consumer)
 Intermediaries – Passive & Active
 Service Composition Members
3. List out different service models.
 Business Service Model
 Utility Service Model
 Controller Service Model
4. Define WSDL.
Web Services Description Language (WSDL) is an XML format for describing web
services. The description includes the name of the service, the operations supported
by the service, the location of the service, and ways to communicate with the service,
that is, what transport to use.
5. Compare Abstract and Concrete Description.
S.No. Abstract Description Concrete Description
1
It defines service interface
characteristics.
It describes transport and location
information about the service
2
This description contains three main
parts: portType, operation and
message.
This description contains three main
parts: binding, port, and service.

6. Define following terms:
Endpoint: Defines the address or connection point to a Web service. It is typically
represented by a simple HTTP URL string. (Known as port in WSDL 1.1)
Interface: Defines a Web service, the operations that can be performed, and the
messages that are used to perform the operation. (Known as portType in WSDL 1.1)
Binding: A binding defines message format and protocol details for operations and
messages defined by a particular portType.
7. Define SOAP.
SOAP is an XML-based protocol that provides specification for exchange of
structured message (information) between two services. It defines message format.
8. Define intermediary services.
Services which routes message from initial sender or other intermediaries and also
optionally process and alter the message contents before routing message to ultimate
receiver or other intermediaries.
9. Sketch the anatomy of a SOAP message.

10. List out some primitive MEPs.
 Request-response: Establishes a simple exchange – a message is first
transmitted from a source (service requestor) to a destination (service
provider). Upon receipt, the destination then responds with a message back to
the source.
 Fire-and-forget: This simple asynchronous pattern is based on the
unidirectional transmission of messages from a source to one or more
destinations.
11. Define UDDI.
Universal Description Discovery and Integration (UDDI) specify a relatively accepted
standard for structuring registries that keep track of service descriptions. WSDL
descriptions are stored in service registries.
12. List out the primary parts of UDDI Registry Record.
 Business Entity
 Business Service
 Binding templates
 tModels
13. Compare Public and Private registries.
S.No. Public registry Private registries
1
Public registries accept registrations
from any organizations, regardless of
whether they have Web services to
offer. Once signed up, organizations
acting as service provider entities can
register their services.
Private registries can be
implemented within organization
boundaries to provide a central
repository for descriptions of all
services the organization develops,
leases, or purchases.

14. Define Coordination.
Coordination is providing a means for context information in complex activities to be
managed, preserved and/or updated, and distributed to activity participants. WS-
Coordination establishes a framework for context management.
15. Compare Atomic Transaction & Business Activity.
S.No. Atomic Transaction Business Activity
1
It implements rollback feature when
transaction is failed.
It does not implement rollback
capability when an exception is
encountered. Instead it implements an
optional compensation process.
2
Participating services are required to
remain participants for the entire
duration of the activity.
Participating services are not required
to remain participants for the entire
duration of the activity.
3
Completion protocol, Durable 2PC
protocol, Volatile 2PC protocol are
the 3 protocols that supports WS-
Atomic Transactions.
BusinessAgreementWithParticipant
Completion protocol and
BusinessAgreementWithCoordinator
Completion protocol are the protocols
that supports WS-Business Activity
16. Define workflow logic.
It is a structured description of the activities or tasks that have to be done to fulfill a
certain business need.
17. List out the characteristics of ACID transactions.
 Atomic: Either all of the changes within the scope of the transaction succeed, or
none of them succeed.
 Consistent: None of the data changes made as a result of the transaction can
violate the validity of any associated data models. Any violations result in a
rollback of the transaction.
 Isolated: If multiple transactions occur concurrently, they may not interfere with
each other. Each transaction must be guaranteed an isolated execution
environment.

 Durable: Upon the completion of a successful transaction, changes made as a
result of the transaction can survive subsequent failures.
18. Define Orchestration.
An orchestration expresses a body of business process logic that is typically owned by
single organization.
In other words, orchestration is composition of various services by a central
controlling service (process service) and the workflow logic involved in it.
19. Define Choreography.
Choreography is a complex activity comprised of a service composition and a series
of MEPs.
20. Compare Orchestration & Choreography
S.No. Orchestration Choreography
1
An orchestration expresses
organization-specific business
workflow. This means that an
organization owns and controls the
logic behind an orchestration, even
if that logic involves interaction
with external business partners.
Choreography, on the other hand, is not
necessarily owned by a single entity. It
acts as a community interchange pattern
used for collaborative purposes by
services from different provider
entities.
2
An orchestration is based on a
model where the composition logic
is executed and controlled in a
centralized manner.
Choreography typically assumes that
there is no single owner of collaboration
logic.
3
A primary industry specification
that standardizes orchestration is
the Web Services Business Process
Execution Language (WS-BPEL).
A primary industry specification that
standardizes choreography is the
Web services Choreography
Description Language (WS-CDL).

1. Give the step-by-step process in the service oriented analysis.
 Define business requirements – Collecting business requirements and their
documentation.
 Identify automation systems – Existing application logic automating any of the
business requirements needs to be identified.
 Model candidate services – The process by which service operation candidates
are identified and then grouping them into service candidates.
2. List the steps involved in Service-oriented design.
 Composing SOA
 Design entity-centric business services
 Design application services
 Design task-centric business services
 Design service-oriented business process
3. List out the steps involved in Composing SOA.
 Choosing service layers
 Position core SOA standards
 Choose SOA extensions
4. Define Service Modeling.
Modeling services is fundamentally a process of gathering (from existing business
model documents, verbally interviewing key personnel etc.) and organizing business
model information. Service candidates and service operation candidates are the end-
result of service modeling.
5. Write the syntax for getVariableData function in WS BPEL.
getVariableData(variable name, part name, location path)
6. What are the Standards that Web service depends on?
 WSDL
 SOAP
 UDDI

7. Differentiate identifier and expire elements.
WS-Coordination uses the Identifier element to associate a unique ID value with the
current activity. The Expires element sets an expiry date that establishes the extent of
the activity's possible lifespan.
8. Mention the usage of CoordinationType element.
It specifies the coordination type as either Atomic Transaction or Business Activity
using predefined URI value.
9. How are the switch-case and otherwise elements used in WS-BPEL?
The switch element establishes the scope of the conditional logic, wherein multiple
case constructs can be nested to check for various conditions using a condition
attribute. When a condition attribute resolves to "true," the activities defined within
the corresponding case construct are executed.
The otherwise element can be added as a catch all at the end of the switch construct.
Should all preceding case conditions fail, the activities within the otherwise construct
are executed.
10. Differentiate getVariableProperty and getVariableData functions.
getVariableProperty function allows global property values to be retrieved from
variables. It simply accepts the variable and property names as input and returns the
requested value.
getVariableData function is required to provide other parts of the process logic access
to this data.
11. Define WS-Policy.
The WS-Policy framework establishes a means of expressing service metadata
beyond the WSDL definition. Specifically, it allows services to communicate rules
and preferences in relation to security, processing, or message content.
12. What are Policy element and common policy assertions?
The Policy element establishes the root construct used to contain the various policy
assertions that comprise the policy. The Policy Assertions specification supplies the

following set of common, predefined assertion elements: Text Encoding, Language, •
Specification Version, Message Predicate.
13. What is Digest method and Digest value?
Digest method: It is an XML Signature element used to identify the algorithm used to
create the signature.
Digest value: It is an XML Signature element used that contains a value that
represents the document being signed. This value is generated by applying the
DigestMethod algorithm to the XML document.
14. Write any four XML Signature elements.
 DigestMethod
 DigestValue
 Signature
 SignatureMethod
15. What do you mean by WS-Security?
This specification defines how to attach a digital signature, use encryption, and use
security tokens in SOAP messages.
16. Write about JAX-WS.
Java API for XML-Based Web Services (JAX-WS) is a fundamental technology for
developing SOAP based and RESTful Java Web services. JAX-WS has taken the
place of JAX-RPC in Web services and Web applications.
17. Compare JAX-RPC and JAX-WS.
S.No. JAX-RPC JAX-WS
1 Used previously to create Java
based Web Services and Clients.
Current API to create Java based Web
Services and Clients.
2 No annotations used. Use Annotations and thereby simplifies
development of web services.
3 Supports only synchronous
operations.
Supports both Synchronous and
Asynchronous operations.

18. What is J2EE?
The Java 2 Platform Enterprise Edition (J2EE) is built to support large-scale,
distributed solutions. J2EE has used extensively to build traditional n- tier
applications with and without Web technologies. The important components of Java
EE are: JSP, Servlets, and EJB etc.
19. Compare JAXP and JAXB.
 Both are used to process and access the XML document using a java application.
 JAXP uses any one of the parsers SAX or DOM to process the XML document.
 JAXB uses binding and unmarshalling to access and process the XML data. It
means developers need not know about XML parsing and hence processing is
faster.
20. Compare Generated Stubs, Dynamic Proxy and Dynamic Invocation Interface.
S.No. Generated Stub Dynamic Proxy
Dynamic Invocation
Interface
1. All are client proxies (Service Requestors) created by JAX-RPC API.
2.
It is auto-generated by
the JAX-RPC compiler
(at design time) by
consuming the service
provider WSDL, and
producing a Java-
equivalent proxy
component.
The dynamic proxy is
similar in concept,
except that the actual
stub is not created until
its methods are invoked
at runtime.
The dynamic invocation
interface bypasses the
need for a physical stub
altogether and allows
for fully dynamic
interaction between a
Java component and a
WSDL definition at
runtime.

IT6801-Service Oriented Architecture

More Related Content

What's hot

Similar to IT6801-Service Oriented Architecture

Recently uploaded

IT6801-Service Oriented Architecture