Soa

IT6801 Service Oriented Architecture Department of IT 2018-19
Unit-I Introduction To XML

XML document structure – Well formed and valid documents – Namespaces – DTD – XML Schema – X-Files.
PART-A
1. What is XML? (April/May 2017, Nov/Dec 2017)
XML stands for ―Extensible markup language‖ a language developed by the World wide
web consortium (W3C).It is considered a meta language because it is used To define other
languages through the use of markup language ,which add structure and Meaning to document.
2. What is meant by a XML namespace? (Nov/Dec 2016)

XML Namespaces provide a method to avoid element name conflicts. When using
prefixes in XML, a so-called namespace for the prefix must be defined. The namespace is
defined by the xmlns attribute in the start tag of an element. The namespace declaration
has the following syntax. xmlns:prefix="URI".
<root><h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Apples</h:td><h:td>Bananas</h:td></h:tr>
</h:table>
<f:table xmlns:f="http://www.w3schools.com/furniture">
<f:name>African Coffee Table</f:name>
<f:width>80</f:width><f:length>120</f:length></f:table>
</root>
3. Distinguish between expanded name space and qualified name space.

Expanded Namespace Qualified Namespace
An expanded name is a pair consisting of a A qualified name is a name subject to namespace
namespace name and a local name. interpretation.
For a name N in a namespace identified by an URI Documents conforming to this specification,
 I, the namespace name is I. For a name N that is element and attribute names appear as qualified
not in a namespace, the namespace name has no names. Syntactically, they are either prefixed
value names or unprefixed names.
4. What is the role of xml?
XML is the set of guidelines foe describing structured data in plaintext rather than binary
representation within the short period,time.XML has been widely used as language for variety of
application ranging from vertical industry vocabularies to horizontal industry application to
protocol.
5. Define XML attributes.

XML elements can have attributes in the start tag, just like HTML. Attributes are used to provide
additional information about elements.
<img src="computer.gif">
<a href="demo.asp">
In the example below, the file type is irrelevant to the data, but can be important to the software
that wants to manipulate the element:
<file type="gif">computer.gif</file>
6. List the characteristics of XML attributes.
 Attributes cannot contain multiple values (child elements can)
 Attributes are not easily expandable (for future changes)
 Attributes cannot describe structures (child elements can)
 Attributes are more difficult to manipulate by program code
 Attribute values are not easy to test against a Document Type Definition (DTD) - which is used
to define the legal elements of an XML document.
1
St. Joseph’s College of Engineering/St. Joseph’s Institute of Technology
7. What are the different revolution in which XML is playing a major role?
a)Data revolution b)Architectural revolution c)Software revolution
8. What are the advantages of xml?
 Simplicity - XML files are human readable
 Openness - Widespread industry support
 Extensibility – There is no fixed set of tags. New tags can be created as they are needed (User
defined tags).
 Major relational databases have the native capability to read and generate XML data
 Large family of XML support technologies is available.
9. What are entities? Give Example.
Entities are used to create substitution strings within a xml document. Example: Xml and data
evaluation can be defined with short string using entity declaration in DTD
10. List the advantages of XML over HTML.
XML is not a replacement for HTML, XML and HTML were designed with different goals:
 XML was designed to transport and store data, with focus on what data is
 HTML was designed to display data, with focus on how data looks
HTML is about displaying information, while XML is about carrying information.
11. List the industries where XML is used.
For exchanging between data in the internet, there are thousands of XML formats exist, for many
industries, to describe day-today-transactions.
-Stocks and shares -Scientific measurements -Financial transactions - Medical data -New
information -Weather services -Mathematical data
12. What are the advantages of schema over DTD?
 It provides more control over the type of data that can be assigned to elements and as
compared to DTD.
 DTD does not enable you to define your own customized data types. But
schema definition enables you to create your own data types and also allows specifying
restrictions on data.
 The syntax for defining DTD is different from the syntax used for creating an
xml document .But the syntax for defining XSD is the same as the syntax of an xml
document.
13. Define DTD and its types.
• Allows developers to create a set of rules to specify legal content and place restrictions on
an XML file, Parser generates error: if XML document does not follow the rules contained
within DTD
 Well Formed XML-Syntax is correct, Valid XML-Well formed, Validated against
a DTD/Schema
14. What is DTD? How is it different from XML schema?
 DTD stands for Document Type Definition
 DTD is a description of the structure & the elements and attributes that define a class of
XML document.
 DTD can be declared both internally in a XML document and as an external reference.
DTD Xml Schema
DTD is used to define the Xml schema is used to define the
structure of an xml document. structure of an xml document.
Data type for elements limited to Numerous predefined data types
text available.
Complex data types cannot be Ability to define complex type
defined. that map to application data
structure.
DTD document is stored as Xml schema document is stored
―filename.dtd‖ as ―filename.xml‖
2
15. What is W3C (World Wide Web)Consortium?
 W3c is responsible for the development of web specifications that describe
communication protocols and technologies for the web .XML was defined by w3c to
ensure that structured data is uniform and independent of vendors of applications.W3c
has laid down certain rules that meet to be followed by the all xml applications.
 Some of these rules are:
 XML must be directly usable over the internet.
 XML must support the wide variety of applications.
 XML must be SGML.
 XML documents must be human legible and clear.
 XML design must be formal and concise.
16. Write short notes on DTD.

A Document Type Definition (DTD) defines the structure and the legal elements and
attributes of an XML document.
A DTD can be declared inside an XML document or in an external file.
DTD can be XML DTD or XHTML DTD.
17. What does an XML document contain?

– An XML document consists ofMarkup
• Tags, which begin with < and end with >
• References, which begin with & and end with ;
– Character, e.g.
– Entity, e.g. <
– Character data: everything not markup
18. List some XML rules? (Nov/Dec 2016)

– Start and end tags must properly nest
– Corresponding pair of start and end element tags plus everything in between them
defines an element
– Character data may only appear within an element
– Start and empty-element tags may contain attribute specifications separated by
white space
– Syntax: name = quoted value
19. Write an example for XML syntax.

XML documents use a self-describing and simple syntax.
<?xml version="1.0" encoding="utf-8"?>
<World> <Continent Name="Africa"> </Continent>
<Continent Name="Europe">
</Continent>
<Continent Name="Asia">
</Continent>
<Continent Name="South America"> </Continent>
<Continent Name="North America" /> </World>
20. What is a Well-formed XML document?

A well-formed XML document
- follows the XML syntax rules and
- has a single root element
- Well-formed documents have a tree structure
3
21. What is an X-file?
XFiles is for hand coders. This means you will need to call the xFiles methods within your code,
for example self.Init(), self.Load() and self.Save(). This accessory is not purely template driven
and requires hand-coding to operate.
22. List the properties XML document?

– XML was designed to describe data
– XML tags are not predefined. You must define your own tags
– XML uses a Document Type Definition (DTD) or an XML Schema to describe the data
– XML with a DTD or XML Schema is designed to be self-descriptive
– XML is a W3C Recommendation.
– Documents must have a root element
– Elements must have a closing tag
– Elements must be properly nested
– Attribute values must be quoted
23. List the properties of Validating Parser?

- Validating
• Requires document type declaration
• Generates error if document does not
– Conform with DTD and
– Meet XML validity constraints
» Example: every attribute value of type ID must be unique
within the document
24. List the properties of Non-Validating Parser?

– Non-validating
• Checks for well-formedness
• Can ignore external DTD
25. How External plus Internal DTD embedded in a single file?
<!DOCTYPE greeting SYSTEM "hello.dtd" [
<!ENTITY excl "!">
]>
<greeting>Hello, world&excl;</greeting>
26. What is XML document prolog? (Nov/Dec 2017)

The XML prolog is optional. If it exists, it must come first in the document.
XML documents can contain international characters, like Norwegian øæå or French êèé.
To avoid errors, you should specify the encoding used, or save your XML files as UTF-8.
UTF-8 is the default character encoding for XML documents.
<?xml version="1.0" encoding="UTF-8"?>
PART-B
1. List and explain the XML syntax rules in detail. Explain how a XML document
can be displayed on a browser.
XML Rules:
– Start and end tags must properly nest
– Corresponding pair of start and end element tags plus everything in between them defines an
element
– Character data may only appear within an element
– Start and empty-element tags may contain attribute specifications separated by white space
Syntax: name = quoted value
Staff1.xml:
<?xml version="1.0"?>
<company>
4
<staff id="1001">
<firstname>yong</firstname>
<lastname>mook kim</lastname>
<nickname>mkyong</nickname>
<salary>100000</salary>
</staff>
<staff id="2001">
<firstname>low</firstname>
<lastname>yin fong</lastname>
<nickname>fong fong</nickname>
</staff>
</company>
2. Explain the XML document structure. (April/May 2017)
XML document consists of a number of discrete components or sections.
Although not all the sections of an XML document may be necessary, their use and inclusion helps to make
for a well-structured XML document that can easily be transported between systems and devices. 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 
a.XML Declaration
 The first part of an XML document is the declaration.

 is exactly as it sounds: It is a definite way of stating exactly what the document
A declaration
contains.
  
The XML declaration states that the following document contains XML content.
  
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.

 declaration indicates the presence of external markup declarations and
In addition, the XML
character encoding.
The XML declaration consists of a number of components.
ASCII - American Standard Code for Information Interchange;UTF - Unicode Transformation

Format Every XML document should use an XML declaration.
As documents increase in size and complexity, this importance likewise grows.
5
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.
Listing. illustrates a few valid XML declarations:
<?xml version= ―1.0‖ standalone= ―yes‖?>
<?xml version= ―1.0‖ standalone= ―no‖?>
<?xml version= ―1.0‖ encoding= ―UTF-8‖ standalone= ―no‖?>
The first declaration defines a well-formed XML document, whereas the second defines a well-formed
and valid XML document. The third declaration shows a more complete definition that states a typical
use-case for XML. Namely, the declaration states that the XML document complies with version 1.0
of the specification and requires external markup declarations that are encoded in UTF-8.
b.Document Type Declaration
Once we are aware that we are talking about a specific version of an XML document, the next step is
to be more specific about the content contained within. 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).
Eg. of DTD:
<!DOCTYPE note SYSTEM "Note.dtd">
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
Note.dtd
<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
Although well-formed XML documents don‟t require the inclusion of the DOCTYPE, valid XML
documents do.
A Document Type Declaration names the document type and identifies the internal content by
specifying the root element, in essence the first XML tag that the XML-processing tools will
encounter in the document.
A DOCTYPE can identify the constraints on the validity of the document by making a reference to
an external DTD subset and/or include the DTD internally within the document by means of an
internal DTD subset.
The general forms of Document Type Declarations:

<!DOCTYPE NAME SYSTEM ―file‖>
<!DOCTYPE NAME [ ]>
6
<!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.
In the case of shirt example, the DOCTYPE is <!DOCTYPE shirt SYSTEM ―shirt.dtd‖> because the first
tag in the document will be the <shirt> element and our DTD is saved to a file named shirt.dtd, which saved
in the same path as the XML document.
The difference between internally and externally defined DTD subsets is that the DTD content itself is
contained within the square brackets, in the case of internal subsets, whereas external subsets save this
content to a file for reference, usually with a .dtd extension.
The actual components of the Document Type Declaration are listed:
c. Markup and Content

In addition to the XML declaration and the Document Type Declaration, XML documents are
composed of 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..
d. 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. Eg., shirt element : <shirt> </shirt>.

 Everything between these tags is additional XML text thathas either been defined by a DTD or can
exist by virtue of the document merely being well formed.
  
When elements do not come in pairs, the element name is suffixed by the forward slash.
 
Eg, if we were merely making a statement that a shirt existed, we may use <on_sale/>.

  name used in a different
In this case, there would be no other matching element of the same
manner. These ―unmatched‖ elements are known as empty elements.
  
Elements can be arbitrarily nested within other elements.
7

XML is a hierarchical tree -This means that XML elements exist within other elements and
can branch off with various children nodes. This means that a single XML element can
 of child elements, and the depth of the XML tree can consist of any
contain any number
number of nodes.
e.Attributes

  can be communicated to XML processors that modify the
Within elements, additional information
nature of the encapsulated content.
Eg: we may have specified a <price> element to create a <currency> subtag.
 
Attributes are name/value pairs contained within the start element that can specify text strings that
modify the context of the element.
LISTING. Attribute Examples
<price currency= ―USD‖>…</price>
<on_sale start_date= ―10-15-2001‖/>

 There are times when we want to introduce special characters or make use of content thatis
constantly repeated without having to enter it multiple times. This is the role of the XML entity.

 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.
  
Entities can solve some intractable problems.

  would
For example, how do we insert a greater-than or less than sign in our text? XML processors
interpret those characters as parts of an XML tag, which may not be our desired result.

  declaration in a DTD or XML
Each entity has a unique name that is defined as part of an entity
Schema. Entities are used by simply referring to them by name.
  
Entity references are delimited by an ampersand at the beginning and a semicolon at the ending.
  
The content contained between the delimiters is the entity that will be replaced.
  
For example, < entity inserts the less-than sign (<) into a document.

 Elements can be encoded so they aren‟t processed or replaced by their entity equivalents in order
to be used for display or encoding within other element values.

 For example, the string  <element> can be encoded in an XML document as < element> and
it will not be processed.
 
There are 5 pre-defined entity references in XML:
< < less than

> > greater than
& & ampersand
' ' apostrophe
" " quotation mark
LISTING. Sample Entity References

<description>The following says that 8 is greater than
5</description> <equation>4 < 5</equation>
<prescription>The Rx prescription symbol is ℞ which is the same as ℞</prescription>


 Entities can be used to refer to often repeated or varying text as well as to include the content of
external files.
For example, an entity &legal; can be replaced with an organization‟s legal disclaimer,
consisting of any XML text that is included in the DTD or read from a file.
  
There are internal and external entities, and they both can be general or parameter entities.
  
Internal entities are defined and used within the context of a document

External entities are defined 
in a source that is accessible via a URI. Internal entities are largely
simple string replacements.
  
External entities can consist of entire XML documents or non-XML text, such as binary files.
 
When using an external entity, you must define the type of the file.
8
IT6801 Service

Oriented Architecture Department of IT 2018-19

 External entitiesthat refer to these files must declare that the data they contain is not XML by
using a notation.
  
Parameter entities are entities that are declared and used within the context of a DTD or schema.

 They allow users to create replacement text that can be used multiple times  to modularize the
creation of valid documents. Parameter entities can be either internal or external.

 
Another special form of entity is the character reference, which is used to insert arbitrary
Unicode characters into an XML document.

This allows international characters to be entered even if they can‟t be typed directly on a
 
keyboard. Character entities use decimal or hexadecimal references to describe their Unicode
data values.
E.g., ℞ and ℞ both encode the ―Rx‖ character, also known as character number
U+211E in Unicode.
f.Comments
  
One of the key benefits of XML is that humans can read it.

A side effect of this feature is that there is a necessity to providedocumentation around XML
content that describes the intent or context of a given XML markup.
  
Comments are quite simple to include in a document.
  
The character sequence  ends the comment.
  
Between these two delimiters, any text at all can be written, including valid XML markup.

The only restriction is that the comment delimiters cannot be used; neither can the literal string
--. Comments can be placed anywherein a document and are not considered to be part of the
 textual content of an XML document.

  are not required to pass comments along to an application.
As a result, XML processors
LISTING. A Sample Comment

<animal>Elephant</animal>
g.Processing Instructions


Processing Instructions (PIs) perform a similar function as comments in that they are not a textual
part of an XML document but provide information to applications as to how the content should be
processed. Unlike comments, XML processors are required to pass along PIs.
Processing
instructions have the following form: <?instruction options?>


The instruction name, called the PI target, is a special identifier that the processing application is
intended to understand. Any following information can be optionally specified so that the
application is able to understand the context or further requirements of the PI. PI names can be
formally declared as notations (a structure for sending such information). The restriction is
that PI names may not start with xml, which is reserved for the core XML standards. <? send-
message ―process complete‖?>
h.Marked CDATA Sections

Some documents will contain a large number of characters and text that an XML processor
  and pass to an application. These are known as Character DATA (or CDATA)
should ignore
sections.

  the parser to ignore all markup characters
Within an XML document, a CDATA section instructs
except the end of the CDATA markup instruction.
 
This allows for a section of XML code to be ―escaped‖ so that it doesn‟t inadvertently disrupt
XML processing. CDATA sections follow this general form: <![CDATA[content]]>

In the content section, any characters can be included, with the necessary exception of the
character string ]]>. All content  contained in the CDATA section is passed directly to the
 application without interpretation.
9

This means that elements, entity references, comments, and processing instructions are all ignored
and passed as string literals to processing applications.
 
CDATA instructions must exist in the context of XML elements and not as standalone entities.

3. Explain the role of XML namespaces with examples. (Nov/Dec 2017)

XML NAMESPACES:
• XML Namespace: Collection of element and attribute names associated with an XML
vocabulary (such as XHTML)
• Namespace Name: Absolute URI that is the name of the namespace
– Ex: http://www.w3.org/1999/xhtml is the namespace name of XHTML 1.0
• Default namespace for elements of a document is specified using a form of the xmlns
attribute:
Another form of xmlns attribute known as a namespace declaration can be used to associate a
namespace prefix with a namespace name:
xmlns:h="http://www.w3.org/TR/html4/"
• In a namespace-aware XML application, all element and attribute names are considered
qualified names
– A qualified name has an associated expanded name that consists of a namespace name and a
local name
– Ex: <table> is a qualified name with expanded name <null, table>
– Ex: <h:table> is a qualified name with expanded name
< http://www.w3.org/TR/html4, table>
Name Conflicts
In XML, element names are defined by the developer. This often results in a conflict when
trying to mix XML documents from different XML applications. This XML carries HTML
table information:
<table>
<tr>
<td>Apples</td>
<td>Bananas</td>
</tr>
</table>
This XML carries information about a table (a piece of furniture):
<table>
<name>African Coffee Table</name>
<width>80</width>
<length>120</length>
</table>
If these XML fragments were added together, there would be a name conflict. Both contain a
<table> element, but the elements have different content and meaning.An XML parser will
not know how to handle these differences.
Solving the Name Conflict Using a Prefix
When using prefixes in XML, a so-called namespace for the prefix must be defined. The
namespace is defined by the xmlns attribute in the start tag of an element. The namespace
declaration has the following syntax.
xmlns:prefix="URI".
<root>
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr> <h:td>Apples</h:td> <h:td>Bananas</h:td> </h:tr>
</h:table>
10
<f:table xmlns:f="http://www.w3schools.com/furniture">
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
</root>
4. Explain in detail the XML schema, built in and user defined data type in detail.
(Nov/Dec 2016)(Nov/Dec 2017)
XML SCHEMA
XML Schema is an XML-based alternative to DTD.
An XML schema describes the structure of an XML document.
The XML Schema language is also referred to as XML Schema Definition (XSD).
The purpose of an XML Schema is to define the legal building blocks of an XML document,
just like a DTD.
An XML Schema:
• defines elements that can appear in a document
• defines attributes that can appear in a document
• defines which elements are child elements
• defines the order of child elements
• defines the number of child elements
• defines whether an element is empty or can include text
• defines data types for elements and attributes
• defines default and fixed values for elements and attributes
Simple Xml Document:

<note>
<to>Tove</to>
<from>Jani</from>
</note>
DTD FILE:
<!ELEMENT note (to, from, heading, body)>
<!ELEMENT heading (#PCDATA)>
note.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
xmlns="http://www.w3schools.com"
elementFormDefault="qualified">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
11
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Reference to Schema:
<note
xmlns="http://www.w3schools.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3schools.com note.xsd">
<to>Tove</to>
<from>Jani</from>
</note>
Simple Element
A simple element is an XML element that contains only text. It cannot contain any other
elements or attributes.
A default value is automatically assigned to the element when no other value is specified.
<xs:element name="color" type="xs:string" default="red"/>
A fixed value is also automatically assigned to the element, and you cannot specify another
value.
<xs:element name="color" type="xs:string" fixed="red"/>
Complex Element
A complex element is an XML element that contains other elements and/or attributes.
Kinds of complex elements:
 Empty elements
 Elements that contain only other elements
A complex XML element, "product", which is empty:
<product pid="1345"/>
Define a complex element that contain attributes.
<xs:attribute name="lang" type="xs:string" default="EN"/>
<xs:attribute name="lang" type="xs:string" fixed="EN"/>
<xs:attribute name="lang" type="xs:string" use="required"/>
A complex XML element, "employee", which contains only other elements:
<employee>
<firstname>John</firstname>
<lastname>Smith</lastname>
</employee>
Define a complex element that contain other elements in an XML Schema two different ways
1. Only the "employee" element can use the specified complex type
<xs:element name="employee">
<xs:complexType>
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:sequence>
12
</xs:complexType>
</xs:element>
2. Several elements can refer to the same complex type
<xs:element name="employee" type="personinfo"/>
<xs:element name="student" type="personinfo"/>
<xs:element name="member" type="personinfo"/>
<xs:complexType name="personinfo">
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
5. Discuss in detail about XML DTDs, and their types with suitable examples.(Nov/Dec 2016)
XML DOCUMENT TYPE DEFINITION:
• Allows developers to create a set of rules to specify legal content and place restrictions on an
XML file
• Parser generates error, if XML document does not follow the rules contained within DTD
• Including a DTD
– Using internal declaration
– Using external file
– Both
• For custom documents
• Uses DOCTYPE declaration
Internal (standalone) DTD:
hello.xml:
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>
• Specify in XML declaration
<?xml version="1.0" standalone="yes"?>
greeting>Hello, world!</greeting>
External DTD:
• Most common dtd.
• Use DOCTYPE declaration before root element
hello.dtd:
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
hello.xml:
<!DOCTYPE greeting SYSTEM "hello.dtd">
<?xml version="1.0" standalone=―no"?>
<greeting>Hello, world!</greeting>
External plus Internal DTD:

• Usually to declare entities
• Use DOCTYPE declaration before root element
hello.xml:
<!DOCTYPE greeting SYSTEM "hello.dtd" [
<!ENTITY excl "!">
]>
13
<greeting>Hello, world&excl;</greeting>
XML Building Blocks:

• XML documents consist of following blocks
– Elements
– Attributes
– Entities
• < > & " &apos
– PCDATA
• Parsed Character DATA
• Entities will be expanded
– CDATA
• Character DATA
• Entities will not be expanded
DECLARING ELEMENTS:
An empty element
<!ELEMENT elementName (EMPTY)>
Example
<!ELEMENT br (EMPTY)>
<!ELEMENT Bool (EMPTY)>
Usage:
<br/>
<Bool Value="True"></Bool>
Element with data
<!ELEMENT elementName (#PCDATA)>
Example
<!ELEMENT question (#PCDATA)>
Usage:
<from>U. K. Roy</from>
<question>
What is the full form of DTD?
</question>
Example : Elements with Data

<!ELEMENT Month (#PCDATA)>
Valid Usage
<Month>April</Month>
<Month>This is a month</Month>
Invalid Usage:
<Month> <!—Invalid usage within XML file, can‘t have children!-->
<January>Jan</January>
<March>March</March>
</Month>
Element with Children (sequential)

<!ELEMENT elementName (child1, child2,…)>
Example
<!ELEMENT message (from, to, body)>
<!ELEMENT address (street, city, zip)>
Inner elements must also be declared
14
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT zip (#PCDATA)>
Occurrence Indicators:
Term Meaning Example
, Sequence Operators a, b, c
| Choice operators a|b|c
+ One or more a+
* Zero or more a*
? Single optional a?
() grouping (a)
DECLARING ATTRIBUTES:
General Syntax
<!ATTLIST elementName attributeName attributeType defaultType>
Example
<!ATTLIST HDD speed CDATA ―7200‖>
<!ATTLIST HDD unit CDATA #IMPLIED>
<!ATTLIST price currency CDATA ―INR‖>
<!ATTLIST question number ID #REQUIRED>
<HDD speed=―6000‖> … </HDD>
<price currency=―USD‖>10</price>
<question number=―1‖> … </question>
The attribute-type can be one of the following:
Type Description
CDATA The value is character data
(en1|en2|..) The value must be one from an enumerated list
ID The value is a unique id
IDREF The value is the id of another element
IDREFS The value is a list of other ids
NMTOKEN The value is a valid XML name
15
NMTOKENS The value is a list of valid XML names
ENTITY The value is an entity
ENTITIES The value is a list of entities
NOTATION The value is a name of a notation
xml: The value is a predefined xml value

The default-value can be one of the following:
Value Explanation
value The default value of the attribute
#REQUIRED The attribute is required
#IMPLIED The attribute is not required
#FIXED value The attribute value is fixed

Examples--#REQUIRED:
DTD:
<!ATTLIST person number CDATA #REQUIRED>
Valid XML:
<person number="5677" />
Invalid XML:
<person />
Examples--#IMPLIED:
DTD:
<!ATTLIST contact fax CDATA #IMPLIED>
Valid XML:
<contact fax="555-667788" />
valid XML:
<contact />
Examples--#FIXED:
DTD:
<!ATTLIST sender company CDATA #FIXED "Microsoft">
Valid XML:
<sender company="Microsoft" />
Invalid XML: <sender company="W3Schools" />
Examples—Enumerated:
DTD:
<!ATTLIST payment type (check|cash) "cash">
XML example:
<payment type="check" /> or <payment type="cash" />
DECLARING ENTITIES:
General Syntax
<!ENTITY entityName ―entityValue‖>
Example
<!ENTITY euro ―€‖> //€
<!ENTITY language ―XML‖>
<!ENTITY W3C ―World Wide Web Consortium‖>
<!ENTITY copyright ―©‖> //
16
<!ENTITY USD SYSTEM ―currency.dtd‖>
<tutorial>
&language; is standardized by &W3C;
&copyright; UKR
</tutorial>
6. Describe in detail how to create well-formed XML and write about XML Parsers. (April/MAY
2017) (or) Brief well-formed XML document. Also differentiate well-formed and valid XML
document.
17
12. Comments in XML

The syntax for writing comments in XML is similar to that of HTML. 
13.White-space is Preserved in XML
XML does not truncate multiple white-spaces in a document (while HTML truncates multiple white-spaces
to one single white-space):
XML: Hello Tove
HTML: Hello Tove
14. XML Stores New Line as LF
Windows applications store a new line as: Carriage Return and Line Feed (CR+LF). Unix and Mac OSX
uses LF. Old Mac systems uses CR.XML stores a new line as LF.
Need of Valid XML Document:
XML parsers
• Two types of XML parsers:
– Validating
• Requires document type declaration
• Generates error if document does not
– Conform with DTD and
– Meet XML validity constraints
» Example: every attribute value of type ID must be unique within the document
– Non-validating
• Checks for well-formedness
• Can ignore external DTD
XML
document
Optimize
XML XML d XML
schema Parser document
Error
message
7. Explain all XML Building Blocks.

18
XML Building Blocks:
• XML documents consist of following blocks
– Elements
– Attributes
– Entities
• < > & " &apos
– PCDATA
• Parsed Character DATA
• Entities will be expanded
– CDATA
• Character DATA
• Entities will not be expanded
DECLARING ELEMENTS:
An empty element
<!ELEMENT elementName (EMPTY)>
Example
<!ELEMENT br (EMPTY)>
<!ELEMENT Bool (EMPTY)>
Usage:
<br/>
<Bool Value="True"></Bool>
Element with data

<!ELEMENT elementName (#PCDATA)>
Example
<!ELEMENT question (#PCDATA)>
Usage:
<from>U. K. Roy</from>
<question>
What is the full form of DTD?
</question>
Example : Elements with Data
<!ELEMENT Month (#PCDATA)>
Valid Usage
<Month>April</Month>
<Month>This is a month</Month>
Invalid Usage:
<Month> <!—Invalid usage within XML file, can‘t have children!-->
<January>Jan</January>
<March>March</March>
</Month>
Element with Children (sequential)

<!ELEMENT elementName (child1, child2,…)>
Example
Inner elements must also be declared

19
<!ELEMENT zip (#PCDATA)>
General Syntax
Example
Type Description
Value Explanation
20
DTD:
Valid XML:
Invalid XML:
<person />
Examples--#IMPLIED:
DTD:
Valid XML:
<contact fax="555-667788" />
valid XML:
<contact />
Examples--#FIXED:
DTD:
Valid XML:
Invalid XML:
<sender company="W3Schools" />
DTD:
XML example:
DECLARING ENTITIES:
General Syntax
Example
<tutorial>
&copyright; UKR
</tutorial>
8. Explain the element types and Order, Occurrence indicators in XML Schema.
Indicators
Order indicators:
Order indicators are used to define the order of the elements.
 All
21
The <all> indicator specifies that the child elements can appear in any order, and that each child
element must occur only once:
 Choice
The <choice> indicator specifies that either one child element or another can occur:
 Sequence
The <sequence> indicator specifies that the child elements must appear in a specific order:
Occurrence indicators:
 maxOccurs
The <maxOccurs> indicator specifies the maximum number of times an element can occur:
 minOccurs
The <minOccurs> indicator specifies the minimum number of times an element can occur:
Schema:
<xs:element name="person">
<xs:complexType>
<xs:sequence> or <xs:choice> or <xs:all>
<xs:element name="full_name" type="xs:string"/>
<xs:element name="child_name" type="xs:string"
maxOccurs="10" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Xml:
<person>
<full_name>Tove Refsnes</full_name>
<child_name>Hege</child_name>
<child_name>Stale</child_name>
<child_name>Jim</child_name>
<child_name>Borge</child_name>
</person>
9. Create an External DTD containing 5 Elements, 3 attributes and 2 Entities, then write an
XML code to match the corresponding DTD. (or) Create a DTD that defines the structure for
e-mail message; further create a XML document that refers to the created document type
definition. (Nov/Dec 2016)
tutorials.dtd:
<!ELEMENT tutorials (tutorial)+>
<!ELEMENT tutorial (name,url)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ATTLIST tutorials type CDATA #REQUIRED>
<!ATTLIST tutorial id ID #REQUIRED>
<!ENTITY copyright ―©‖>
tutorials.xml:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE tutorials SYSTEM "tutorials.dtd">
<tutorials type="web">
<tutorial id="1" >
<name>XML Tutorial &copyright; </name>
<url>http://www.quackit.com/xml/tutorial</url>
</tutorial>
<tutorial id="2" >
<name>HTML Tutorial&copyright; </name>
<url>http://www.quackit.com/html/tutorial</url>
22
</tutorial>
</tutorials>
DTD that defines the structure for e-mail message
Syntax: <!ENTITY entity-name "entity-value">
DTD Example:
<!ENTITY writer "Donald Duck.">
<!ENTITY copyright "Copyright W3Schools.">
XML example:
<author>&writer;&copyright;</author>
A doctype declaration can also be used to define special characters and character strings, used in the
document:
<!DOCTYPE note [
<!ENTITY nbsp " ">
<!ENTITY writer "Writer: Donald Duck.">
<!ENTITY copyright "Copyright: W3Schools.">
]>
<note>
<to>Tove</to>
<from>Jani</from>
<footer>&writer; &copyright;</footer>
</note>
An External Entity Declaration
Syntax: <!ENTITY entity-name SYSTEM "URI/URL">
DTD Example:
<!ENTITY writer SYSTEM "http://www.w3schools.com/entities.dtd">
<!ENTITY copyright SYSTEM "http://www.w3schools.com/entities.dtd">
XML example:
<author>&writer;&copyright;</author>
10. Discuss XML attributes and entities in Detail.

General Syntax
Example
Type Description
23

Value Explanation

DTD:
Valid XML:
Invalid XML:
<person />
Examples--#IMPLIED:
DTD:
Valid XML:
<contact fax="555-667788" />
valid XML:
<contact />
Examples--#FIXED:
DTD:
Valid XML:
Invalid XML:
DTD:
XML example:
DECLARING ENTITIES:
24
General Syntax
Example
<tutorial>
&copyright; UKR
</tutorial>
10. Explain XML files: XPath, XPointer and XLink in detail.(Nov/Dec 2016)
X-Files is a collection of classes for hand-coders. It was built primarily to provide a simple and
exceptionally high-performance method to convert xml files or strings to Clarion data structures, and
vice-versa. xFiles explains about XPath, XLink, and XPointer.
XPath

 The XML Path Language (XPath) is a standard for creating expressions  that can be
used to find specific pieces of information within an XML document.

 XPath expressions are used by both XSLT (forwhich XPath provides the core
functionality) and XPointer to locate a set of nodes.

 To understand how XPath works, it helps to imagine an XML document as a tree of
nodes consisting of both elements and attributes.
 
XPath expressions have the ability to locate nodes based on the nodes‟ type, name, or value or by
the relationship of the nodes to other nodes within the XML document.
In addition to being able to find nodes based on these criteria, an XPath expression can return any of
the following: A node set, A Boolean value, A string value and A numeric value.
Similarity between URLs and XPath expressions
URLs represent a navigation path of a hierarchical file system, and XPath expressions represent a
navigation path for a hierarchical tree of nodes.
Operators and Special Characters
XPath expressions are composed using a set of operators and special characters, each with its own
meaning. Table.1 lists the various operators and special characters used within the XML Path
Language.
TABLE.1 Operators and Special Characters for the XML Path Language
25
The above table provides a list of operators and special characters that can be used within an XPath
expression. The table does not indicate what the order of precedence is.
The priority for evaluating XPath expressions: 1. Grouping, 2. Filters, 3. Path operations
XPath Syntax
The XML Path Language provides a declarative notation, termed a pattern, used to select the desired
set of nodes from XML documents.
Each pattern describes a set of matching nodes to select from a hierarchical XML document. Each
pattern describes a ―navigation‖ path to the desired set of nodes similar to the URI.
Each ―query‖ of an XML document occurs from a particular starting node defines the context for the
query.
The context for the query has a very large impact on the results.
One possible result from performing an XPath query is a node set, or a collection of nodes matching
specified search criteria.
To receive these results, a ―location path‖ is needed to locate the result nodes.
These location paths select the resulting node set relative to the current context.
The XML document shown in Listing.1 describes how the current context node is defined.
LISTING.1 Sample1.xml Contains a Simple XML Document
</a>
X- Pointer

The
 XML Pointer Language (XPointer), currently in thecandidate recommendation stage of the
W3C approval process, 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.
  
The axes for XPointer are the same as the axes for XPath.
  
The node tests for an XPointer are, for the most part, the same as for an XPath node test.

In

addition to the node tests already listed
 for XPath expressions, XPointer provides two more
important node tests: point() and range().
  
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 endpoint and contains all XML information between those
two points.

As with XPath expressions, XPointer expressions have specific functions to deal with each specific
predicate type.
  
The XPointer specification also adds an additional function named unique().

This new function indicates whether an XPointer expression selects a single location rather than

multiple locations or no locations at all.

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.
26
  
Four of the functions that return location sets, id(), root(), here(), and origin(), have the differences.
TABLE 1. Some XPointer Functions that return Location Sets
Points

Many
 times a link
 from one XML document into another must locate a specific point within the

target document. 
Two different types of points can be represented using XPointer points:
Node points and Character points
Node points are location points in an XML document that are nodes that contain child nodes. For
these node points, the index position indicates after which child node to navigate to.
If 0 is specified for the index, the point is considered to be immediately before any child nodes. A
node point could be considered to be the gap between the child nodes of a container node.
When the origin node is a text node, the index position indicates the number of characters. These
location points are referred to as character points.
Because you are indicating the number of characters from the origin, the index specified must be an
integer greater than or equal to 0 and less than or equal to the total length of the text within the text node. By
specifying 0 for the index position in a character point, the point is considered to be immediately before the
first character in the text string.
For a character point, the point represents the space between the characters of a text
string.
How does the XPointer work?
Use the sample XML document shown in listing which is a XML document containing a list of names and
addresses.
LISTING . Sample3.xml Contains a Small List of Names and Addresses
<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>
TABLE 2. Examples of XPointer Points and the Resulting Locations
27
Ranges
  
An XPointer range defines just that—a range consisting of a start point and an endpoint.

A range will contain the XML between the start point and endpoint but does not
 necessarily have to consist of neat subtrees of an XML document.

 A range can extend over multiple branches of an  XML document. The only criterion is
that the start point and endpoint must be valid.
TABLE 3. XPointer Range Functions
The following expression specifies a range beginning at the first character in the <Name> element for
Dillon Larsen and ending after the ninth character in the <Name> element for Dillon Larsen:
/People/Person[1]/Name/text()start-point()[position()=0] to ➥/People/Person[1]/Name/text()start-
point()[position()=9]
In this example, two node points are used as the starting and ending points for the range.
The result is the string Dillon La. Table lists the various range functions available.
The XML Pointer Language also has the ability to perform basic string matching by using a function
named string-range().
This function returns a location set with one range for every nonoverlapping match to the search string
by performing a case-sensitive search. The general syntax for string-range() is as follows: string-
range(location-set, string, [index, [length]])
The location-set argument for the string-range() function is any XPointer expression that would create
a location set as its result—for instance, /, /People/Person,/People/Person[1], and so on.
XLink:

The anchor element, <a>, within HTML indicates a link to another resource on an
 HTML page. Thiscould be a location within the same document or a document
located elsewhere.

In HTML terms, the anchor element creates a hyperlink to another location. The
 hyperlink
 can either appear as straight text, a clickable image, or a combination of
both.

The XML Linking Language, XLink, addresses and overcomes these limitations by
 allowing 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.
 The XML Linking Language specification supports the attributes are listed below.
TABLE. XLink Attributes
28
XML Linking Language offers two major types of links: simple and extended.
Within XLink, a simple link is a convenient, shorthand notation by which to associate two resources. These
resources—one local and one remote—are connected by an arc, always making a simple link an outbound
link. An extended link associates any number of resources together. Those resources may be both local and
remote.
i.Simple Links
A simple link combines the functionality provided by the different pieces available through an extended link
together into a shorthand notation.
A simple link consists of an xlink:type attribute with a value of simple and, optionally, an xlink:href attribute
with a specified value.
A simple link may have any content, and even no content; it is up to the application to provide some means
to generate a traversal request for the link.
If no target resource is specified with the xlink:href attribute, the link is simply considered ―dead‖ and will
not be traversable.
ii.Extended Links
Within the XML Linking Language, extended links give you the ability to specify relationships
between an unlimited number of resources, both local and remote.
These links can involve multiple paths between the linked resources. Local resources are part of the actual
extended link, whereas remote resources identify external resources to the link.
An out-of-line link is created when there are no local resources at all for a link. LISTING.
Sample4.xml Contains a Modified Version of the Names List in Sample3.xml <People
xmlns:xlink= ―http://www.w3.org/1999/xlink‖
➥xlink:type= ―extended‖ xlink:title= ―Phone book‖>
<Person>
<Name>Dillon Larsen</Name>
<Address>
<Street>123 Jones Rd.</Street>
<State>TX</State>
29
<Zip>77380</Zip>
</Address>
</Person>
<Person xlink:type= ―resource‖ xlink:label= ―John‖>
<Name>John Smith</Name>
<Spouse xlink:type= ―resource‖ xlink:label= ―JohnSpouse‖>Jane Smith</Spouse>
<Address>
<Street>522 Springwood Dr.</Street>
<State>TX</State>
<Zip>77069</Zip>
</Address>
</Person>
<Marriage xlink:type= ―arc‖ xlink:from= ―JohnSpouse‖
➥xlink:to= ―Jane‖ xlink:actuate= ―onRequest‖ xlink:show= ―new‖/>
<Marriage xlink:type= ―arc‖ xlink:from= ―JaneSpouse‖
➥xlink:to= ―John‖ xlink:actuate= ―onRequest‖ xlink:show= ―new‖/>
</People>
11. Discuss XML attributes and entities in Detail.
General Syntax
Example
Type Description

30
Value Explanation

DTD:
Valid XML:
Invalid XML:
<person />
Examples--#IMPLIED:
DTD:
Valid XML:
<contact fax="555-667788" />
valid XML:
<contact />
Examples--#FIXED:
DTD:
Valid XML:
Invalid XML:
DTD:
XML example:
DECLARING ENTITIES:
General Syntax
Example
<tutorial>
&copyright; UKR
</tutorial>
31
Unit-II Building XML- Based Applications

Parsing XML – using DOM, SAX – XML Transformation and XSL – XSL Formatting – Modeling Databases in XML.
PART-A
1. What is the purpose of XSLT?
The XSLT stands for XSL Transformations and XSL stands for extensible Style sheet Language. The
XSLT is used for defining the XML document transformation and presentations.
2. List the advantages of XML over Databases.
– XML brings benefits of DBs to documents:Schema to model information directly
– Formal validation, locking, versioning, rollback...
– But Not all traditional database concepts map cleanly, because documents are
fundamentally different in some ways
3. What is Electronic Data Interchange (EDI)?
EDI is often used as the replacement for business communication through conventional business documents
such as purchase orders,request for quotations,invoice and shipping notices.This kind of exchange takesplace
between trading partners.Inorder to interchange data using EDI to trading partners must be agreed upon a
common format.
4. What is an XPath?
Xpath is used to navigate XML tree structures. XPath gets its name from its use of a path notation to
navigate through the hierarchical tree structure of an XML document. It is an important XML technology
due to its role in providing a common syntax and semantics for functionality in both XSLT and XPointer.
5. What is XQuery?
XQuery is a W3C initiative to define a standard set of constructs for querying and searching
XML documents. XQuery brings database query processing to XML.
6. What are all the Transformation techniques?
 XSLT - it is an XML- based languages used to transform XML documents into others format such as
HTML for web display.
 XLINK - highlighting that element or taking the user directly to that point in the document.
 XPATH - xpath gets its name from its use of a payh notation to navigate through the hierarchical tree
structure of an XML document
7. 
What isXQUERY
XForm? - it is W3C initiative to define a standard set of constructs for querying & searching
XMLXForm
document.
is an XML approach that overcomes the limitations of HTML forms. XForm
includes a variety of buttons, scrollbars and menus. It generates XML form data as output.
XForm's model has the capability to work with the variety of user interfaces.
8. What is content management?

A content management system (CMS) is a system used to manage the content of a Web site. Typically, a
CMS consists of two elements: the content management application (CMA) and the content delivery
application (CDA). The CMA element allows the content manager or author, who may not know
Hypertext Markup Language (HTML), to manage the creation, modification, and removal of content
from a Web site without needing the expertise of a Webmaster. The CDA element uses and compiles that
information to update the Web site. The features of a CMS system vary, but most include Web-based
publishing, format management, revision control, and indexing, search, and retrieval.
9. How is XML parsing done with SAX?

A SAX parser is a mechanism for transforming an XML text document into stream of events corresponding to
the markup and character data contained in the original document.
32
10. What input files passed to XSLT Processor?
The Extensible Stylesheet Language (XSL) is an XML vocabulary typically used to transform XML
documents from one form to another form
11. Define XML Parser. (Nov/Dec 2016)

XML Parser provides a way to access or modify data in an XML document. Java provides multiple options to
parse XML documents. Following are the examples of parsers which are commonly used to parse XML
documents.
Dom Parser − Parses an XML document by loading the complete contents of the document and creating its
complete hierarchical tree in memory.
SAX Parser − Parses an XML document on event-based triggers. Does not load the complete document into the
memory.
12. Compare DOM and SAX in XML processing. (Nov/Dec 2016)

DOM SAX
DOM is an interface-oriented Application SAX parser works incrementally and
Programming Interface. generates events that are passed to the
application.
It allows for navigation of the entire DOM parser reads the whole XML document
document. and returns a DOM tree representation of xml
document.
DOM allows you to read and write. SAX is essentially an API for reading XML
13. What are complex types?

complex types are an important aspects of xml schema that allow application developers to define application-
specific data types that can be checked by programs that check XML document for validity. XML schema
divides complex types into two categories: those with simple content& those with complex content.
14. What is DOM? List some DOM interfaces. (Nov/Dec 2017)
Dom Parser − Parses an XML document by loading the complete contents of the document and creating its
complete hierarchical tree in memory.
 Node − The base datatype of the DOM.
 Element − The vast majority of the objects you'll deal with are Elements.
 Attr − Represents an attribute of an element.
 Text − The actual content of an Element or Attr.
 Document − Represents the entire XML document. A Document object is often referred to as a DOM
tree.
15. What is SAX? List the disadvantages of SAX.(Nov/Dec 2017)
SAX Parser − Parses an XML document on event-based triggers. Does not load the complete document into the
memory.
Disadvantages of SAX
 We have no random access to an XML document since it is processed in a forward-only manner.
 If you need to keep track of data that the parser has seen or change the order of items, you must write
the code and store the data on your own.
33
16. Write a simple stylesheet using XSL. (Nov/Dec 2016)
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h2>My CD Collection</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>Artist</th>
</tr>
<tr>
<td>.</td>
<td>.</td>
</tr>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
17. Explain any two XForm implementations?
X-Smiles - it is a java based XML browser.it implements a large part of X-forms & uses X-form together with
XSL-FO on user interface side. Mozquito Xforms preview - is an XML based Web developement s/w that
implements Xforms & gives current Web browser the ability to send,receive & process XML document.
18. List the advantage of XPATH?

 Queries are compact and Queries are easy to type and read.
 Query strings are easily embedded in programs, scripts, and XML or HTML attributes.
 Query conditions can be evaluated at any level of a document and are not expected to navigate from the
top node of a document.
 XPath is designed to be used in many contexts. It is applicable to providing links to nodes, for
searching repositories, and for many other applications.
19. List the Relationship between Xpath Nodes
 Parent
 Children
 Siblings
 Ancestors and Descendants
20. List some Xpath axis.
descendant::* All elements being children and children's
children, etc, of context node.
descendant::stock All "stock" elements being children and
children's children, etc, of context node.
descendant::comment() All comment nodes being children of context
node.
descendant::*|comment() All element and comment nodes being
children or children's children, etc, of context
descendant::node() All nodes being children or children's children,
node.
21. Define Schemas and it’s types. etc, of context node.
• XML-schema documents themselves are XML documents and therefore use the same syntax and
can themselves be validated with schemas
• XML-schema has more powerful possibilites to define custom data types
• XML-schema allows to define multiple elements with the same name but different content
34
22. How a table is represented un XML.
Each table of the database is represented by an element node with the records as its children:
<customer>
record1
record2
...
recordm
</customer>
23. How a database is modelled using XML.
We can model the database with a document node and its associated element node:
<?xml version=―1.0‖ ?>
<myDatabase>
table1
table2
...
tablen
</myDatabase>
Order of tables is immaterial
24. What are the major types of XML databases?
There are two major types of XML databases:
XML-enabled. These map all XML to a traditional database (such as a database), accepting XML as input and
rendering XML as output.
Native XML (NXD) The internal model of such databases depends on XML and uses XML documents as the
fundamental unit of storage.
25. What is meant by XSL Formatting? (April/May 2017)
XSL-Formatting or XSL-FO (XSL Formatting Objects) is a markup language for XML document
formatting that is most often used to generate PDF files. XSL-FO is part of XSL (Extensible
Stylesheet Language), a set of W3C technologies designed for the transformation and formatting of
XML data. The other parts of XSL are XSLT and XPath.
26. Compare CSS and XSL.
CSS XSL
CSS can be used with HTML XSL can‗t be used in HTML
CSS is not a transformation language XSL is a transformation language
CSS does not have the formatting object differently
from the source tree. XSL is having the formatting object differently from
the source tree.
CSS provides the inheritance of the formatting XSL cant provide the inheritance of the formatting
object that is related to the source tree Part-B object that is related to the source tree
1. Given an XSLT document and a source XML document explain the XSLT transformation
process that produces a single result XML document.(April/May 2017)
XSLT TRANSFORMATION: (XSLT)
• The Extensible Stylesheet Language (XSL) is an XML vocabulary typically used to transform
XML documents from one form to another form
XSL document
Input XML Output XML

document XSLT Processor document
35
• JAXP allows a Java program to use the Extensible Stylesheet Language (XSL) to extract data
from one XML document, process that data, and produce another XML document containing the
processed data.
For example, XSL can be used to extract information from an XML document and embed it within
an XHTML document so that the information can be viewed using a web browser.
TRANSFORMER:
Main.java:
import java.io.FileOutputStream;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.stream.StreamResult;
import javax.xml.transform.stream.StreamSource;
public class Main
{
static String xml="D://WebTech//trans.XML";
static String xslt="D://WebTech//trans.XSL";
static String output="D://WebTech//trans.HTML";
public static void main(String[] args)
{
try
{
TransformerFactory tf = TransformerFactory.newInstance();
Transformer tr = tf.newTransformer(new StreamSource(xslt));
tr.transform(new StreamSource(xml),new StreamResult(new FileOutputStream(output)));
System.out.println("Output to " + output);
}
catch(Exception e)
{
}
}
}
trans.xsl:
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<html>
<body>
<h1>Indian Languages details</h1>
<table border="1">
<tr>
<th>Language</th>
<th>Family/Origin</th>
<th>No. of speakers</th>
<th>Region</th>
</tr>
<xsl:for-each select="language">
<tr>
<td><xsl:value-of select="name"/></td>
<td><xsl:value-of select="family"/></td>
<td><xsl:value-of select="users"/></td>
<td><xsl:value-of select="region"/></td>
</tr>
36
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
trans.xml:

<language>
<name>Kannada</name>
<region>Karnataka</region>
<users>38M</users>
<family>Dravidian</family>
</language>
trans.html:
Indian Languages details
Language Family/Origin No. of speakers Region
Kannada Dravidian 38M Karnataka
2. Explain in detail about the various XML parsers with suitable examples. (Nov/Dec 2016)
(Nov/Dec 2017)
PARSING XML:
DOM BASED XML PROCESSING:
DOM:
• Include Java DOM API defined by org.w3c.dom package
• Nodes of DOM tree belong to classes such as Node, Document, Element, Text.
• Non-method properties of Node instances are accessed via methods
parentNode is accessed by calling getParentNode()
• Methods such as getElementsByTagName() (that returned an arraylike list of Node instances in
JavaScript) will in Java return an object implementing the NodeList interface.
PROGRAM:
DOM:
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
import java.io.File;
public class Main {
{
try
{
File fXmlFile = new File("D:/Web Tech/Staff1.XML");
DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
Document doc = dBuilder.parse(fXmlFile);
System.out.println("RootSystem element :" + doc.getDocumentElement().getNodeName());
NodeList nodes = doc.getElementsByTagName("staff");
37
System.out.println("Input Elements has:" + nodes.getLength() + "nodes");
}
catch(Exception e)
{
System.out.println("XML Doc not Well formed" + e);
}
}
}
EVENT-ORIENTED PARSING: SAX-PARSER
SAX:
 An alternative approach is to have the parser interact with an application as it reads an XML
document. This is the approach taken by SAX (Simple API for XML).
 SAX allows an application to register event listeners with the XML parser.
 SAX parser calls these listeners as events occur and passes them the information about the
events.
Main.Java:
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
public class Main
{
public static void main(String args[])
{
try
{
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
saxParser.parse("D://Staff1.XML",new CountHelper());
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
CountHelper.JAVA:
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;
public class CountHelper extends DefaultHandler
{
int no_elms;
/*CountHelper()
{
super();
}*/
@Override
public void startDocument() throws SAXException
{
no_elms=0;
//return;
}
@Override
public void startElement(String u,String ln,String qname,Attributes atts)
38
throws SAXException{
if(qname.equals("firstname"))
{
no_elms++;
}// return;
}
@Override
public void endDocument() throws SAXException
{
System.out.println("I/p Doc has " + no_elms + "firstname Elements");
}
}
Staff1.xml:
<company>
<staff id="1001">
</staff>
<staff id="2001">
</staff>
</company>
OUTPUT:
DOM OUTPUT:
RootSystem element :company
Input Elements has:2nodes
SAX OUTPUT:
I/p Doc has 2 firstname Elements
3. How XML is mapped against relational data.

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.
Depending on the sophistication of the product, it may provide a graphical tool to map the
database fields to the desired XML elements. Other tools support a configuration file that
defines the mapping. These tools continue to store the information in relational database
management system (RDBMS) format. They simply provide an XML conversion process that
is normally implemented as a server-side Web application.
39
<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>
In the JAXB framework, we can parse XML documents into a suitable Java object. This
technique is referred to as unmarshaling. The JAXB framework also provides the capability
to generate XML documents from Java objects, which is referred to as marshaling.
Mapping xml with relational schema:

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.
4. With examples discuss various Xpath operators and special characters.

XPath axes
An XPath axis is a path through the node tree making use of particular relationship between nodes.
We use the "child::*" axis and the "attribute::*" axis all the time but mostly their short form: "*"
and "@*".
1. Axis examples
40
Most often the axes, e.g.: "descendant::", are followed by an "*" (element) or an element name
but comment(), processing-instruction() andtext-node() can also be used. Only root node and
elements can have children.
The construct node() only selects nodes being children of other
nodes: element(), text(), comment(), processing-instruction(). An attribute has a parent element
but attribute and namespace nodes are not children and not included in the node() construct or
type.
descendant::* All elements being children and children's children, etc, of context node.
descendant::stock All "stock" elements being children and children's children, etc, of
context node.
descendant::comment() All comment nodes being children of context node.
descendant::*|comment() All element and comment nodes being children or children's children,
etc, of context node.
descendant::node() All nodes being children or children's children, etc, of context node.
2. Axis diagrams
The diagrams are not showing attribute() and namespace() nodes and I have not made diagrams
for the attribute and namespace axes. The namespace axis is deprecated. The functions in-scope-
prefixes() and namespace-uri-for-prefix() should be used instead.
When using axes it is often important to remember that the nodes are processed in document
order (indicated below). If both a node's children and siblings are included in an axis, the node's
children are always processed before its following siblings. The order is sometimes a little tricky
especially for reverse axes until you get used to it. See the preceding axis as example.
2.1 ancestor
Ancestor axis: parent and parent's parent, etc.
India is context node: count(ancestor::*) returns 2.

2.2 ancestor-or-self
Ancestor-or-self axis: context node and parent and parent's parent, etc.
41
India is context node: count(ancestor-or-self::*) returns 3.

2.3 child
Child axis: children of context node.
Charlie is context node, e.g.: count(child::*) returns 2. Same as count(*).

2.4 descendant
Descendant axis: children and their children, etc.
Charlie is context node, e.g.: count(descendant::*) returns 5.

2.5 descendant-or-self
Descendant-or-self axis: context node and children and their children, etc.
42
Charlie is context node, e.g.: count(descendant-or-self::*) returns 6.
2.6 following
Following axis: following siblings and their children and their children, etc.
Charlie is context node, e.g.: count(following::*) returns 4.
2.7 following-sibling
Following-sibling axis: following siblings.
43
Charlie is context node, e.g.: count(following::*) returns 2.
2.8 parent
Parent axis: The parent of context node.
India is context node, e.g.: if (parent::* eq 'Charlie') then '...' else '...'
2.9 preceding
Preceding axis: preceding siblings and their children and their children, etc.
44
Charlie is context node, e.g.: count(preceding::*) returns 3
2.10 preceding-sibling
Preceding-sibling axis: preceding siblings.
Charlie is context node, e.g.: count(preceding-sibling::*) returns 1
2.11 self
Self axis: context node.
45
Charlie is context node, e.g.: if (self::* eq 'Charlie') then '...' else '...'
5. Explain DOM tree based parser with suitable examples.

DOM BASED XML PROCESSING:
DOM:
• Include Java DOM API defined by org.w3c.dom package
• Nodes of DOM tree belong to classes such as Node, Document, Element, Text.
• Non-method properties of Node instances are accessed via methods
parentNode is accessed by calling getParentNode()
• Methods such as getElementsByTagName() (that returned an arraylike list of Node instances in
JavaScript) will in Java return an object implementing the NodeList interface.
PROGRAM:
DOM:
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
import java.io.File;
public class Main {
{
try
{
File fXmlFile = new File("D:/Web Tech/Staff1.XML");
DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
Document doc = dBuilder.parse(fXmlFile);
System.out.println("RootSystem element :" + doc.getDocumentElement().getNodeName());
NodeList nodes = doc.getElementsByTagName("staff");
System.out.println("Input Elements has:" + nodes.getLength() + "nodes");
}
catch(Exception e)
{
System.out.println("XML Doc not Well formed" + e);
}
}}
46
Staff1.xml:
<company>
<staff id="1001">
</staff>
<staff id="2001">
</staff>
</company>
DOM OUTPUT:
RootSystem element :company
Input Elements has:2nodes
6. Explain SAX-Event based parser with suitable examples.

SAX:
 An alternative approach is to have the parser interact with an application as it reads an XML
document. This is the approach taken by SAX (Simple API for XML).
 SAX allows an application to register event listeners with the XML parser.
 SAX parser calls these listeners as events occur and passes them the information about the
events.
Main.Java:
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
public class Main
{
public static void main(String args[])
{
try
{
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
saxParser.parse("D://Staff1.XML",new CountHelper());
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
CountHelper.JAVA:
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;
public class CountHelper extends DefaultHandler
{
int no_elms;
47
/*CountHelper()
{
super();
}*/
@Override
public void startDocument() throws SAXException
{
no_elms=0;
//return;
}
@Override
public void startElement(String u,String ln,String qname,Attributes atts)
throws SAXException
{
if(qname.equals("firstname"))
{
no_elms++;
}
// return;
}
@Override
public void endDocument() throws SAXException
{
System.out.println("I/p Doc has " + no_elms + "firstname Elements");
}
}
Staff1.xml:
<company>
<staff id="1001">
</staff>
<staff id="2001">
</staff>
</company>
SAX OUTPUT:
I/p Doc has 2 firstname Elements
7. Write a XSLT program to extract XML document details and XSL formatting. (or) With
example show how XSLT can transform an XML document into HTML. (Nov/Dec 2016)
trans.xsl:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<html>
48
<body>
<h1>Indian Languages details</h1>
<table border="1">
<tr>
<th>Language</th>
<th>Family/Origin</th>
<th>No. of speakers</th>
<th>Region</th>
</tr>
<xsl:for-each select="language">
<tr>
<td><xsl:value-of select="name"/></td>
<td><xsl:value-of select="family"/></td>
<td><xsl:value-of select="users"/></td>
<td><xsl:value-of select="region"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
trans.xml:
<?xml-stylesheet type="text/xsl" href="trans.xsl"?>
<language>
<name>Kannada</name>
<region>Karnataka</region>
<users>38M</users>
<family>Dravidian</family>
</language>
trans.html:
Indian Languages details

Language Family/Origin No. of speakers Region
Kannada Dravidian 38M Karnataka
Formatting Objects
The XSL technology is composed of XSL Formatting Objects (XSL-FO).

o
XSL-FO was designed to assist with the printing and displaying of XML data.
o
The main emphasis is on the document layout and structure. This includes the dimensions of
the output document, including page headers, footers, and margins.
o
XSL-FO allows the developer to define the formatting rules for the content, such as font, style,
color, and positioning.
o
XSL-FO is a sophisticated version of Cascading Style Sheets (CSS). XSL-FO borrows a lot of
the terminology and elements from CSS.
o
XSL-FO documents are well-formed XML documents.
o
Use two techniques for creating XSL-FO documents.
49
o
To develop the XSL-FO file with the included data.
o
To dynamically create the XSL-FO file using an XSLT translation.
An XSL-FO formatting engine processes XSL-FO documents.

XSL-FO Formatting Engines
We‗ll use the Apache XSL-FOP to generate PDF documents from XML. Table 1 contains a list of XSL-FO
formatting engines.
TABLE 1. XSL-FO Formatting Engines
Once the document is created, we will use the Apache XSL-FOP formatter to convert the document to
a PDF file.
The application interaction is illustrated in Figure 1.
FIGURE 1 Apache XSL-FOP generating PDF
documents
8. Write a java code for Generating XML from relational data

// JDBCSAXParser.java
package dbxml.sax;
import java.io.IOException;
import java.sql.*;
import org.xml.sax.*;
import org.xml.sax.helpers.AttributeListImpl;
public class JDBCSAXParser extends ParserBase {
private static final AttributeList _stockEmptyAttributeList
= new AttributeListImpl();
//------------------------------------------------------------------
// Methods from the Parser interface
//------------------------------------------------------------------
public void parse (InputSource source) throws SAXException, IOException {
if (! (source instanceof JDBCInputSource)) {
throw new SAXException("JDBCSAXParser can work only with source "
+ "of JDBCInputSource type");
}
parse((JDBCInputSource)source);
}
public void parse (String systemId) throws SAXException, IOException {

throw new SAXException("JDBCSAXParser needs more information to "
+ "connect to database");
}
//------------------------------------------------------------------
// Additional methods
//------------------------------------------------------------------
public void parse(JDBCInputSource source)
50
throws SAXException, IOException {
try {
Connection connection = source.getConnection();
if (connection == null) {
throw new SAXException("Could not establish connection with "
+ "database");
}
String sqlQuery = getSelectorSQLStatement(source.getTableName());

PreparedStatement pstmt = connection.prepareStatement(sqlQuery);
ResultSet rs = pstmt.executeQuery();
parse(rs, source.getTableName());
rs.close();
connection.close();
} catch (SQLException ex) {
throw new SAXException(ex);
}
}
public void parse(ResultSet rs, String tableName)

throws SAXException, SQLException, IOException {
if (_documentHandler == null) {
return; // nobody is interested in me, no need to sweat!
}
ResultSetMetaData rsmd = rs.getMetaData();

int numCols = rsmd.getColumnCount();
String tableMarker = getTableMarker(tableName);

String rowMarker = getRowMarker();
_documentHandler.startDocument();
_documentHandler.startElement(tableMarker, _stockEmptyAttributeList);
while(rs.next()) {
_documentHandler.startElement(rowMarker,
_stockEmptyAttributeList);
for (int i = 1; i <= numCols; i++) {
generateSAXEventForColumn(rsmd, rs, i);
}
_documentHandler.endElement(rowMarker);
}
_documentHandler.endElement(tableMarker);
_documentHandler.endDocument();
}
public void parse(String connectionURL, String userName, String passwd,

String tableName) throws SAXException, IOException {
parse(new JDBCInputSource(connectionURL, userName, passwd, tableName));
}
//------------------------------------------------------------------
51
// Protected methods that derived classes could override to
// customize the parsing.
//------------------------------------------------------------------
protected void generateSAXEventForColumn(ResultSetMetaData rsmd,
ResultSet rs,
int columnIndex)
throws SAXException, SQLException {
String columnValue = rs.getString(columnIndex);
if (columnValue == null) {
return;
}
String columnMarker
= getColumnMarker(rsmd.getColumnLabel(columnIndex));
char[] columnValueChars = columnValue.toCharArray();
_documentHandler.startElement(columnMarker,
_stockEmptyAttributeList);
_documentHandler.characters(columnValueChars,
0, columnValueChars.length);
_documentHandler.endElement(columnMarker);
}
protected String getTableMarker(String tableName) {

return tableName;
}
protected String getRowMarker() {
return "row";
}
protected String getColumnMarker(String columnName) {
return columnName;
}
protected String getSelectorSQLStatement(String tableName) {
return "select * from " + tableName;
}
}
9 .Write a XSL code illustrating <xsl:apply-templates> Element.
THE <XSL:APPLY-TEMPLATES> ELEMENT
The <xsl:apply-templates> element applies a template to the current element or to the current
element's child nodes.
If we add a select attribute to the <xsl:apply-templates> element it will process only the child
element that matches the value of the attribute. We can use the select attribute to specify the
order in which the child nodes are processed.
It will not process the other nodes that are not in the select attribute list.
XML:
<catalog>
<cd>
<title>Empire Burlesque</title>
<artist>Bob Dylan</artist>
<country>USA</country>
<company>Columbia</company>
<price>10.90</price>
<year>1985</year>
</cd>
</catalog>
52
XSL:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<html>
<body>
<h2>My CD Collection</h2>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="cd">
<p>
<xsl:apply-templates select="title"/>
<xsl:apply-templates select="artist"/>
</p>
</xsl:template>
<xsl:template match="title">
Title: <span style="color:#ff0000">
<xsl:value-of select=".."/></span>
<br />
</xsl:template>
<xsl:template match="artist">
Artist: <span style="color:#00ff00">
<xsl:value-of select="."/></span>
<br />
</xsl:template>
</xsl:stylesheet>
Title: Empire Burlesque Bob Dylan USA Columbia 10.90 1985 (Parent)
Artist: Bob Dylan(Self)
10. Explain how XML database model is different from relational model,
S
relational database. The ideal solution is a database that can combine the flexibility of the
XML model with the performance of the relational model; that is, support for an XML data
type within a relational database. This XML data type would fully support the XML model,
both logically and physically, yet allow the data to be physically managed by a single
database.
Fundamental properties of XML that make it different from the relational model:
• XML is self-describing. A given document contains not only the data, but also the
necessary metadata. As a result, an XML document can be searched or updated without
requiring a static definition of the schema. Relational models, on the other hand, require
more static schema definitions. All the rows of a table must have the same schema.
53
• XML is hierarchical. A given document represents not only base information, but also
Information about the relationship of data items to each other in the form of the hierarchy.
Relational models require all relationship information to be expressed either by primary
key or foreign key relationships or by representing that information in other relations.
• XML is sequence-oriented—order is important. Relational models are set oriented—
order is unimportant.
None of these differences indicate that XML is better or worse than purely relational
models. In fact, XML and relational models are complementary solutions. Some data is
inherently hierarchical while other data is inherently tabular; some data has more rigid schema
while other data has less rigid schema; some data needs to follow a specific order while other
data does not.
11. Explain in detail about the modeling databases in XML. (Nov/Dec 2016) (April/May 2017)
Modeling Databases in XML using JAXB
When we model a database, we provide an external representation of the database contents.
We‗ll model the rental property database as an XML document. Figure 1 shows the desired output.
FIGURE 1. Desired output for rental properties
One possible solution is to use Java servlets and JDBC. Java servlets are server-side components that
reside in a Web server or application server.
Java servlets are used to handle requests from Web browsers using the HTTP protocol.
A key advantage to using servlets is the thin-client interface.
The servlets handle the request on the server side and respond by generating an HTML page
dynamically. This lowers the requirement on the client browser.
The browser has to provide support of HTML. There is zero client-side administration. Java applets
require the browser to support the correct version of the Java Virtual Machine (JVM). This has been a thorny
issue with the Java community. If the browser doesn‗t support Java, the applet will not execute. There are a
number of workarounds, such as the Java Plug-In and Java Web Start.
These technologies require an initial installation on the client machine—which can prove to be time
consuming and error prone.
We can develop a servlet that uses Java Database Connectivity (JDBC). The servlet will make the
appropriate query to the database and use JDBC API results set metadata to create the elements. We‗ll
leverage the XML data binding features of Java Architecture for XML Binding (JAXB). JAXB provides a
framework for representing XML documents as Java objects. Using the JAXB framework, we can guarantee
that the documents processed by our system are well-formed.
We have the option of validating the XML data against a schema. In the JAXB framework, we can
parse XML documents into a suitable Java object. This technique is referred to as unmarshaling. The JAXB
framework provides the capability to generate XML documents from Java objects, which is referred to as
marshaling. The process is illustrated in the Figure 2.
FIGURE 2. JAXB marshaling and unmarshaling
54
JAXB is easier to use and a more efficient technique for processing XML documents than the SAX
or DOM API.
Using the SAX API, you have to create a custom content handler for each XML document structure.
During the development of the content, you have to create and manage your own state machine to keep track
of your place in the document.
Using JAXB, an application can parse an XML document by unmarshaling the data from an
input stream. JAXB is similar to DOM in that we can create XML documents programmatically and
perform validation. The hindrance with DOM is the complex API.
If we have an XML tree, using the DOM API, we have to traverse through the tree to retrieve
elements. With JAXB, we retrieve the data from the XML document by calling a method on an object.
JAXB allows us to define Java objects that map to XML documents, so we can retrieve data. The JAXB
framework ensures the type safety of the data.
i.JAXB Solution
In the JAXB solution, we will model the rental property database as an XML document.
First we need to review the database schema. After reviewing the schema, we will develop our desired XML
document based on an XML schema.
After we have the XML schema developed, we can create the JAXB binding schema.
The JAXB binding schema contains instructions on how to bind the XML schema to a Java class.
We‗ll take the JAXB binding schema and generate the appropriate Java classes.
To summarize, we‗ll follow these steps:
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.
Figure 3 illustrates the application architecture. RentalXMLServlet communicates with RentalDAO to

retrieve information from the database.
Once the information is retrieved by RentalDAO, RentalXMLServlet generates an XML document.
FIGURE 3. The rental property application architecture
ii.Reviewing the Database Schema
We have an existing database for the rental properties. Table 1 contains the database schema.
TABLE 1. Rental Property Database Schema
55
The source code includes a sample MS Access database. The file is located at rental_property.mdb.
iii.Constructing the Desired XML Document

The XML document does not use the exact field names listed in the database schema.
The XML document provides a custom mapping of the database fields to XML element names. Table 2
contains the mapping.
TABLE. 2 XML Database Mapping
A rental property described with a root element of <rental_property>, as shown in the following code:
<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>
The <address> element contains the subelements <street>, <city>, <state>, and <postal_code>. A similar
approach is taken for the contact information.
The <contact> element contains the <phone> and <fax> elements for the voice number and fax number,
respectively.
In our system, we‗ll normally work with a collection of rental properties. This collection is modeled using
a <rental_property_list> element, as shown here:
<rental_property_list>
<rental_property> … </rental_property>
<rental_property> … </rental_property>
……
</rental_property_list>
iv.Defining a Schema for the XML Document
Based on the desired document format, we can create a schema definition. The DTD schema format
was chosen because JAXB 1.0 supports DTDs.
In the future, JAXB is supposed to support the formal XML Schema definition. Listing contains the DTD
for our rental property list.
LISTING. rental_property.dtd
<!ELEMENT rental_property_list (rental_property)*>
56
<!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 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)>
v.Creating the JAXB Binding Schema
The JAXB binding schema is an XML document that contains instructions on how to bind a DTD to
a Java class. Using the JAXB binding schema, we can define the names of the generated Java classes, map
element names to specific properties in the Java class, and provide the mapping rules for attributes.
The following code example informs the JAXB system that the element <rental_property_list> should be
mapped to a Java class and that it is the root element for the XML document:
<element name= ―rental_property_list‖ type= ―class‖ root= ―true‖/>
There‗s no requirement to define a mapping for every element in the XML document.
JAXB uses a default binding schema that will create properties in the Java class based on the XML element
name. The binding schema allows us to define a conversion rule for elements. For example, the numerical
data for the rental property, such as price, square footage, and number of rooms, is represented in the DTD
as text data (#PCDATA). This is one of the limitations of the DTD format. By using JAXB, we can specify
that a given element should be converted to a Java primitive type or class.
In the following code example, we inform JAXB to convert the values of <square_footage>,
<bedrooms>, and <bath> to the double type; <price> is converted to an instance of the java.math.
BigDecimal class:
<element name= ―square_footage‖ type= ―value‖ convert= ―double‖/>
<element name= ―bedrooms‖ type= ―value‖ convert=
―double‖/> <element name= ―bath‖ type= ―value‖ convert=
―double‖/> <element name= ―price‖ type= ―value‖ convert=
―BigDecimal‖/> <conversion name= ―BigDecimal‖ type=
―java.math.BigDecimal‖/>
We can use the binding schema to define enumerated types, constructors, and interfaces.
In the JAXB 1.0 early access version, constructors are not implemented. The binding schema includes a
section for controlling the output of the generated Java source code. For example, we can inform the system
to use a given package name.
The following code defines the package name as xmlunleashed.ch10.jaxb:
<options package= ―xmlunleashed.ch10.jaxb‖/>
Look at the JAXB binding schema file for our rental property example. The schema files use the filename
extension .xjs (for XML Java schema).
vi.Generating the JAXB Classes Based on Schemas
We are ready to generate the Java source files based on our schemas. JAXB provides a schema
compiler for generating the Java source files.
The schema compiler takes as input the DTD and the JAXB binding schema. Figure 3 illustrates the process.
FIGURE 3. Generating Java classes with the JAXB compiler
We pass our DTD (rental_property.dtd) and binding schema (rental_property.xjs) to the JAXB schema
compiler with the xjc command.
57
The command should be entered in the directory, e.g. <install_dir>\ch10_xmldb\. Type everything on one
line: 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.
Unified Modeling Language (UML) class diagram can be drawn for the generated Java classes.
Using the default schema-binding definition, the JAXB schema compiler generates a property in the Java
class for each XML element.
In the event the XML element contains subelements, the schema compiler will create a new class.
Unit-III SERVICE ORIENTED ARCHITECTURE
Characteristics of SOA, Comparing SOA with Client-Server and Distributed architectures – Benefits of SOA --
Principles of Service orientation – Service layers.
PART-A
1. Define SOA. (Nov/Dec 2017)
SOA is a form of technology architecture that adheres to the principles of service-orientation.
When realized through web services technology platform, SOA establishes the potential to support
and promote these principles throughout the business process and Automation domains of an
enterprise.
2. How does SOA address the issues that arise in client-server architecture?
a. Service oriented solutions eliminate dependencies on user environment by delegating all
processing to the server side.
b. SOA establishes an adaptable and extensible architecture mode that allows solutions to be
enhanced with minimal impact. Services can encapsulate existing legacy logic providing a
standardized API that can plug into larger integrated solution.
3. How is SOA different from distributed internet architecture?
SOA introduces processing and security requirements that differ from distributed internet
architecture and SOA administration is typically more complex due to its reliance on message-
based communication.
4. Give any 2 differences between service orientation and object orientation.
Service orientation Object Orientation
Emphasizes loose coupling between units of Emphasizes tightly bound units of
processing logic. processing logic.
Encourages coarse-grained interfaces so that Supports fine-grained interfaces so that
units of communication contain as much units of communication perform various
information as possible for completion of a sized tasks.
given task.
5. Define application architecture.
Application architecture is to an application development team what a blueprint is to a team of
construction workers. Application architecture includes high-level abstract, physical and logical
representation of the technical blueprint or common data models, communication flow diagrams,
application-wide security requirements and aspects of infrastructure.
6. Define enterprise architecture.
Enterprise architecture specification is to an organization what an urban plan is to a city. A master
specification created, providing high-level overview of all forms of heterogeneity that exist within
an enterprise. i.e. when multiple applications architecture exist within an organization they are
always accompanied by and kept in alignment with a governing enterprise architecture.
7. List any 4 characteristics of SOAs. (Nov/Dec 2016) (April/May 2017)(Nov/Dec 2017)
a. SOA supports vendor diversity.
b. SOA is fundamentally autonomous.
c. SOA promotes discovery.
d. SOA fosters intrinsic interoperability.
58
8. List the components SOA.
Messages- contains data for operation
Operations-holds the logic
Services- group the operation together
Processes-large units of work with business logic
9. Define service. How do services communicate?
A service represents a logically grouped set of operations capable of performing the related units
of work.Services communicate via SOAP messages.
10. What do you mean by loose coupling? or How loose coupling concept achieved in SOA?
(Nov/Dec 2016)
It is a condition wherein a service acquires knowledge of another service while still remaining
independent of that service. It is achieved through the use of service contracts that allow services.
11. What are the fundamental parts of SOA? How do they interrelate(Nov/Dec 2017)
12. List any 4 principles of service orientation.

Services are reusable.
Services share a formal contract.
Services are loosely coupled.
Services are autonomous.
13. What do you mean by loose coupling?
It is a condition wherein a service acquires knowledge of another service while still remaining
independent of that service. It is achieved through the use of service contracts that allow services.
14. What does contemporary SOA represent?
An open, extensible, federated, composable architecture that promotes service-orientation and is
composed of autonomous, QoS-capable, vendor diverse, interoperable, discoverable and
potentially reusable services implemented as web services.
15. What are the core principles that form the baseline foundation for SOA?
Autonomy, loose coupling, abstraction and the need for formal contract.
16. What is a service contract?
Service contract provides a formal definition of :
a. Service endpoint.
b. Each service operation.
c. Every input and output message supported by each service operation.
d. Rules and characteristics of the service and its operations.
17. What is the principle behind service interface –level abstraction?
The principle behind service interface-level abstraction is to allow services to act as black
boxes, hiding their details from outside world.
18. What are the 2 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.
19. What are the issues to be addressed by service layer abstraction?
a) What logic should be represented by services
b) How should services relate to existing application logic
c) How can services best represent business process logic
d) How can services be built and positioned to promote agility
59
20. What are the business service models that business service layer offers?
a) Task-centric business service
b) Entity-centric business service
21. What is the role of orchestration service layer?
It consists of one or more process services that compose business and application services
according to business rules and business logic embedded within process definition.
22. What are wrapper services?
They consist of services that encapsulate (―wrap‖) some or all parts of a legacy environment to
expose legacy functionality to service requestors. They are used for legacy purpose. Example of
wrapper service: service adapter provided by legacy vendors.
23. What are the reponsibilities of SOA? (April/May 2017)(Nov/Dec 2017)
 Improved integration and intrinsic interoperability
 Inherent reuse
 Streamlined architectures and solutions
 Leveraging of legacy investment
 Establishing standardized XML data representation
 Focused investment on communication infrastructure
 Best of breed alternatives
 Organizational agility
24. State Service component.
A service component represents a logically grouped set of operations capable of
performing the related units of work. Services communicate via SOAP messages.
Part B
1. Compare SOA with Client Server and Distributed Internet Architecture.(Nov/Dec 2016)
(April/May 2017) (Apr/May 2018)
SOA is a radical departure from client-server architecture. Current SOAs employ
technologies used to build client-server applications.
SOAs introduce complexity that sharply contrasts the simplicity of two-tier client-server
architecture.
Any environment in which one piece of software requests or receives information from
another can be referred to as "client-server".
Every variation of application architecture that ever existed (including SOA) has an element of
client-server interaction in it.
Client-server architecture: The environments, in which bulky mainframe back-ends served thin
clients, are considered an implementation of the single-tier client-server architecture (Figure 1).
Figure 1. A typical Single-tier Client Server Architecture
60


o
Mainframes supported synchronous and asynchronous communication.

 Client-side software performed the bulk of the processing, including all presentation-related and data
access logic Figure.2.
 Asynchronous allow the server to continuously receive characters from the terminal in response to
individual key-strokes.
The reign of the mainframe as the computing platform began to decline when a two-tier
variation of the client-server design emerged in the 80s. This new approach introduced the
delegating logic and processing duties onto individual workstations, resulting in the fat client.
Figure 2. A typical Two-tier Client Server Architecture
Supported by the innovation of the GUI, two-tier client-server was considered and
dominates the IT world for years during the early 90s. The configuration of this architecture
consisted of multiple fat clients, each with its own connection to a database on a central server. One
or more servers facilitated these clients by hosting scalable RDBMSs.
61
62
SOA vs Traditional Distributed Internet Architecture
In response to the costs and limitations associated with the two-tier client server
architecture, the concept of building component-based applications hit the mainstream.
Multi-tier client-server architectures surfaced, breaking up the monolithic client executable into
components designed to varying extents of compliance with object-orientation.
Distributing application logic among multiple components (some residing on the client,
others on the server) reduced deployment headaches by centralizing a greater amount of the logic
on servers.
Server-side components located on dedicated application servers, would share and manage
pools of database connections, alleviating the burden of concurrent usage on the database server
(Figure.1). A single connection could facilitate multiple users.
Figure 1. Multi-tier Client Server Architecture
These benefits came at the cost of increased complexity and ended up shifting expense and
effort from deployment issues to development and administration processes.
Building components capable of processing multiple, concurrent requests were difficult and
problem-ridden than developing a straight-forward executable intended for a single user.
Additionally, replacing client-server database connections was the client-server Remote Procedure
Call (RPC) connection.
RPC technologies such as CORBA and DCOM allowed for remote communication between
components residing on client workstations and servers.
Issues similar to the client-server architecture problems involving resources and persistent
connections emerged.
Adding to this was an increased maintenance effort resulting from the introduction of the
middleware layer. For example, application servers and transaction monitors required significant
attention in larger environments.
Upon the arrival of the World Wide Web as a viable medium for computing technology in
the mid-to-late 90s, the multi-tiered client-server environments began incorporating Internet
technology.
Significant was the replacement of the custom software client component with the browser.
Not did this change radically alter (and limit) user-interface design, it practically shifted 100% of
application logic to the server (Figure. 2).
63
Figure 2. A typical distributed Internet architecture.
Distributed Internet architecture introduced a new physical tier, the Web server. This
resulted in HTTP replacing proprietary RPC protocols used to communicate between the user's
workstation and the server.
The role of RPC was limited to enabling communication between remote Web and
application servers.
Distributed Internet architectures represented the de facto computing platform for custom
developed enterprise solutions.
The commoditization of component-based programming skills and the increasing
sophistication of middleware lessened some of the overall complexity.
Although multi-tier client-server is a distinct architecture in its own right, we do not provide
a direct comparison between it and SOA.
DIA vs SOA
The following primary characteristics are used for comparison between DIA and SOA:
1) Application Logic
2) Application Processing
3) Technology
4) Security
5) Administration
64
65
2. Explain SOA vs. hybrid Web service architecture with case study.
The use of Web services within traditional architectures is completely legitimate. Due to the
development support for Web services in many established programming languages, they can be
positioned to fit in with older application designs.
A. Web services as component wrappers
The role of Web services introduces an integration layer that consists of wrapper services
that enable synchronous communication via SOAP-compliant integration channels (Figure.1).
The initial release of the SOAP specification and the first generation of SOAP servers were
specifically designed to duplicate RPC-style communication using messages.
Figure 1. Wrapper services encapsulating components
66
These integration channels are utilized in integration architectures to facilitate
communication with other applications or outside partners.
They are used to enable communication with other solutions and to take advantage of the
features offered by third-party utility Web services.
Regardless of their use within traditional architectures, it clarify that a distributed Internet
architecture that incorporates Web services in this manner does not qualify as a true SOA. It is a
distributed Internet architecture that uses Web services.
Instead of mirroring component interfaces and establishing point-to-point connections with
Web services, SOA provides strong support for a variety of messaging models.
Web services within SOAs are subject to specific design requirements, such as those
provided by service-orientation principles. These and other characteristics support the pursuit of
consistent loose coupling. Once achieved, a single service is never limited to point-to-point
communication; it can accommodate any number of current and future requestors.
B.Web services within SOA
While SOAs can vary in size and quality, there are tangible characteristics that distinguish
an SOA from other architectures that use Web services. SOAs are built with a set of Web services
designed to collectively automate one or business processes and that SOA promotes the
organization of these services into specialized layers that abstract specific parts of enterprise
automation logic. By standardizing on SOA across an enterprise, a natural interoperability emerges
that transcends proprietary application platforms. This allows for previously disparate environments
to be composed in support of new and evolving business automation processes.
3. Give a comparative study of service orientation with object orientation.

a. SO emphasizes loose coupling between units of processing logic (services)
b. OO supports reusability of loosely coupled programming routines, much of it is based
on predefined class dependencies, resulting in tightly bound processing logic
(objects)
c. SO encourages coarse-grained interfaces (service descriptions) with information
loaded messages
d. OO supports fine-grained interfaces (APIs) so units of communication (RPC or local
API calls) can perform various tasks
e. SO expects the scope of a service to vary significantly
f. OO objects tend to be smaller and more specific in scope
g. SO promotes activity-agnostic units of processing logic (services) that are driven into
action by intelligent messages
h. OO encourages the binding of processing logic with data into objects
i. SO prefers services be designed to remain as stateless as possible
j. OO promotes binding data and logic into stateful objects
k. SO supports loosely coupled services
OO supports composition but also inheritance among classes which leads to tightly coupled class
dependencies
4. Explain about common characteristics of contemporary SOA. (April/May 2017) (Nov/Dec

2017)
i. Contemporary SOA is at the core of the service-oriented computing platform.
ii. Contemporary SOA increases quality of service.
iii. Contemporary SOA is fundamentally autonomous.
iv. Contemporary SOA is based on open standards.
v. Contemporary SOA supports vendor diversity.
vi. Contemporary SOA fosters intrinsic interoperability.
vii. Contemporary SOA promotes discovery.
viii. Contemporary SOA promotes federation.
ix. Contemporary SOA promotes architectural composability.
x. Contemporary SOA fosters inherent reusability.
67
xi. Contemporary SOA emphasizes extensibility.
xii. Contemporary SOA supports a service-oriented business modeling paradigm.
xiii. Contemporary SOA implements layers of abstraction.
xiv. Contemporary SOA promotes loose coupling throughout the enterprise.
xv. Contemporary SOA promotes organizational agility.
xvi. Contemporary SOA is a building block.
xvii. Contemporary SOA is an evolution.
xviii. Contemporary SOA is still maturing.
xix. Contemporary SOA is an achievable ideal
5. Explain in detail the principles of service orientation. (Nov/Dec 2016) (Nov/Dec 2017)
Service-orientation can be viewed as a manner in which to realize a separation of concerns.
Common principles of service-orientation

Services are reusable Regardless of whether immediate reuse opportunities exist; services are
designed to support reuse.
Figure 1. A reusable service exposes reusable operations.
Services share a formal contract: For services to interact, they need not share anything but a
formal contract that describes each service and defines the terms of information exchange.
Figure 2. Service contracts formally define the service, operation, and message components of
a service-oriented architecture.
68
Services are loosely coupled: Services must be designed to interact without the need for tight,
cross-service dependencies.
Figure 3. Services limit dependencies to the service contract, allowing underlying provider
and requestor logic to remain loosely coupled.
Services abstract underlying logic: The part of a service that is visible to the outside world is
what is exposed via the service contract. Underlying logic, beyond what is expressed in the
descriptions that comprise the contract, is invisible and irrelevant to service requestors.
Figure 4. Service operations abstract the underlying details of the functionality they expose.
Services are composable Services may compose other services. This allows logic to be represented
at different levels of granularity and promotes reusability and the creation of abstraction layers.
Figure 5. The UpdateEverything operation encapsulating a service composition
69
Services are autonomous: The logic governed by a service resides within an explicit boundary.
The service has control within this boundary and is not dependent on other services for it to execute
its governance.
Figure 6. Autonomous services have control over underlying resources
Services are stateless Services should not be required to manage state information, as that can
block their ability to remain loosely coupled. Services should be designed to maximize statelessness
even if that means deferring state management elsewhere.
Figure 7. Stateless and stateful stages a service passes through while processing a message.
Services are discoverable Services should allow their descriptions to be discovered and
understood by humans and service requestors that may be able to make use of their logic.
Of these eight, autonomy, loose coupling, abstraction, and the need for a formal contract can be
considered the core principles that form the baseline foundation for SOA.
70
There are other qualities associated with services and service-orientation. Examples include self-
descriptive and coarse-grained interface design characteristics.
6. Explain the anatomy of SOA. Also list the benefits of SOA.
 Logic components of the Web services framework
 W
 Each operation governs the process of a specific function the web service is capable of
performing.
 Web services form an activity though which they can collectively automate a task.
SOAs offer the following advantages over traditional approaches to distributed computing:
 They offer business services across the platforms
 They provide location independence
 Services need not be at a particular system or particular network
 Completely loosely coupled approach
 Authentication and authorization support at every level
 The search and connectivity to other services is dynamic
Short-term benefits of implementation:
 Enhances reliability
 Reduces hardware acquisition costs
 Leverages existing development skills
 Accelerates movement to standards-based server and application consolidation
 Provides a data bridge between incompatible technologies
71
Long-term benefits of implementation:
 Provides the ability to build composite applications
 Creates a self-healing infrastructure that reduces management costs
 Provides truly real-time decision-making applications
 Enables the compilation of a unified taxonomy of information across an enterprise and
its customer and partners
Benefits from the perspective of Business Value
 Ability to more quickly meet customer demands
 Lower costs associated with the acquisition and maintenance of technology
 Management of business functionality closer to the business units
 Leverages existing investments in technology
 Reduces reliance on expensive custom development
1. 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 SOI architecture.
Because of the vendor-neutral communications framework established by Web services-
driven SOAs, there are 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 of a modeling exercise. The cost and effort of cross-
application integration is lowered when applications being integrated are SOA-compliant.
2. 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 supporting a degree of reuse by future requestors establishes
an environment wherein investments into existing systems can be leveraged and re-leveraged as
new solutions are built.
Building services to be inherently reusable results in a moderately increased development
effort and requires the use of design standards. Leveraging reuse within services lowers the cost and
effort of building service-oriented solutions.
3. Streamlined architectures and solutions
The concept of composition is another fundamental part of SOA. It is not 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 the technologies required become part of the
architecture.
Realizing this benefit requires adherence to design standards that govern allowable
extensions within each application environment. Benefits of streamlined solutions and architectures
include for reduced processing overhead and reduced skill-set requirements.
The reduced performance requirements refer that SOA extensions are composable and allow
application-level architecture to contain extensions relevant to its solution requirements.
Message-based communication in SOAs can increase performance requirements when compared to
RPC-style communication within traditional distributed architectures.
4. 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.
This allows IT departments to work toward a state of federation, where previously isolated
environments can interoperate without requiring the development of expensive and fragile point-to-
point integration channels.
72
Though 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 and in the future is extremely attractive.
The cost and effort of integrating legacy and contemporary solutions is lowered. The need for
legacy systems to be replaced is lessened.
5. Establishing standardized XML data representation

SOA is built upon and driven by XML. An adoption of SOA leads to the opportunity to
fully leverage the XML data representation platform.
A standardized data representation format 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 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 for data within messages to be maintained, traced, and
understood.
The standardization level of data representation lays the groundwork for intrinsic
interoperability. By promoting the use of standardized vocabularies, the need to translate
discrepancies between how respective applications have interpreted corporate data models is
reduced.
Past efforts to standardize XML technologies have resulted in limited success, as XML was
either incorporated in an ad-hoc manner or on an "as required" basis. These approaches inhibited
the benefits XML could introduce to an organization. With contemporary SOA, establishing XML
data representation architecture becomes a necessity, providing organizations the opportunity to
achieve a broad level of standardization. The cost and effort of application development is reduced
after a proliferation of standardized XML data representation is achieved.
6. Focused investment on communications infrastructure
Because Web services establish a 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 cost of scaling communications infrastructure is reduced, as one communications technology
is required to support the federated part of the enterprise.
7. "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.
IT departments are 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
business and IT communities. 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 scope of business requirement fulfillment increases, as does the quality of business
automation.
8. Organizational agility
73
Agility is a quality inherent in just about any aspect of the enterprise. A simple algorithm, a
software component, a solution, a platform, a process all of these parts contain a measure of agility
related to how they are constructed, positioned, and leveraged.
How building blocks such as these can be realized and maintained within existing financial
and cultural constraints ultimately determines the agility of the organization as a whole.
Much of service-orientation is based on the assumption that what you build today will evolve over
time. One of the 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.
The predictability of these qualities within the enterprise leads to a reliable level of
organizational agility. All of this is attainable through proper design and standardization.
Change can be disruptive, expensive, and 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 reusable services establishes adaptive automation environment that empowers IT
departments to adjust to change.
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.
Regardless of what parts of service-oriented environments are leveraged, the increased
agility with which IT can respond to business process or technology-related changes is significant.
The cost and effort to respond and adapt to business or technology-related change is reduced.
Summary:
When assessing the return on investment for an SOA there are several concrete benefits that can be
taken into account. Many of the benefits promised by SOA do not manifest themselves until the use
of service-orientation principles becomes established within an enterprise.
7. Discuss about three service layers in detail. (Nov/Dec 2017) (Apr/May 2018)
Application service layer
The application service layer intentionally abstracts non-business-related logic into a set
of services that are referred to as application services (utility services) provides
reusable functions that address cross-cutting concerns by representing common
enterprise resources and capabilities
Common characteristics of application services:
 Expose functionality within a specific processing context
 Draw upon available resources within a given platform
 Are solution-agnostic
 Are generic and reusable
 Can be used to achieve point-to-point integration with other application services
 Are often inconsistent in terms of the interface granularity they expose
 May consist of a mixture of custom-developed services and third-party services
that have been purchased or leased
 When a separate business service layer exists there is a strong motivation to turn
all application services into generic utility services
 Generic utility services are implemented in a solution-agnostic manner, provide
reusable operations are composed by business services to fulfill business-centric
processing requirements
 If business logic does not reside in a separate layer, application services may be
required to implement services models more associated with business services
layer
 A single application service can also be classified as a business service if it
74
interacts directly with application logic and contains embedded business rules
Hybrid application services (hybrid services) – services that contain both application
and business logic
Typically found within traditional distributed architectures
Not a recommended design when building service abstraction layers
An application service can compose other, smaller-grained application services into a
unit of course-grained application logic
Application integration services (integration services) – application services that exist
solely to enable integration between systems
Application services are very similar to the utility service model
Application service layer is sometimes called the utility service layer, or infrastructure
service layer (infrastructure services)
Wrapper service model –
- used for integration purposes and consist of services that encapsulate (―wrap‖) some or
all parts of a legacy environment to expose legacy functionality to service requestors
- most frequent form is a service adapter provided by legacy vendors
establishes a vendor-defined service interface that expresses an underlying API to legacy
logic
Proxy service (auto-generated WSDL) –
provides a WSDL definition that mirrors an existing component interface establishes an
endpoint on the component‘s behalf, allowing it to participate in SOAP
communication
Proxy service should not be confused with a service proxy, used by service requestors to
contact service providers
Summary
The application service layer consists of application services that represent technology-
specific logic
Typical incarnations of application services are the utility and wrapper models
Application services are ideally reusable utility services composed by business services,
but also can exist as hybrid services that contain both business and application logic
Business service layer
 The business service layer represents a collection of services based on the
business service model called business services
 achieves a close alignment between an organization‘s business and technology
domains
 Each business service is assigned a functional context derived from one or more
existing organizational business models or specifications
 Designing a business service layer leads to the creation of two common business
service models, each of which establishes its own sub-layer
Task-centric business service –
a service that encapsulates business logic specific to a task or business process that
involves two or more business entities generally have limited potential and can be
simply referred to as task services
Entity-centric business service
A service that encapsulates processing logic associated with a specific business entity are
useful for creating highly reusable and business-process agnostic services and can be
called business entity services or entity services. If a separate application service
exists, these two types of business services can be positioned to compose application
services to carry out their business logic
A hybrid service is a service that contains both business and application logic often
referred to as a type of business service and is considered a variation of an application
service and resides in the application service layer. The business service layer is
reserved for services that only abstract business logic
75
Summary
 The business service layer is comprised of business services, a direct
implementation of the business service model
 Business services are ideally also controllers that compose application services to
execute their business logic
 Even though hybrid services contain business logic, they are not classified as
business services
Orchestration service layer
When orchestration is incorporated as part of a service-oriented architecture, it
assumes the role of the process. Orchestration allows a direct link to process logic to
service interaction within workflow logic combines business modeling with service-
oriented modeling and design brings the business process into the service layer
positioned as a master composition controller orchestration languages (WS-BPEL)
realize workflow management through a process service model. The orchestration layer
introduces a parent level of abstraction that alleviates the need for other services to
manage interaction details required to ensure that service operations are executed in a
specific sequence. Within the orchestration layer, process services compose other
services that provide specific sets of functions, independent of the business rules and
scenario-specific logic required to execute a process instance. All process services are
controller services by their very nature. They are required to compose other services to
execute business process logic
Process services can also be referred to as orchestrated task services parent business
process layer
The introduction of an orchestration layer typically brings with it the requirement to
introduce new middleware into the IT infrastructure
Summary
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
8. Explain briefly about: i)Service Layer Abstraction. ii) Application Service layer.
Service layer abstraction
The service interface layer is
located between the business process and application layers
where service connectivity resides
the area of our enterprise wherein the characteristics of SOA are most prevalent
Problems solved by layering services
Need to answer the following questions:
What logic should be represented by services?
How should services relate to existing application logic?
How can services best represent business process logic?
How can services be built and positioned to promote agility?
Application service layer
The application service layer intentionally abstracts non-business-related logic into a set
of services that are referred to as application services (utility services) provides
reusable functions that address cross-cutting concerns by representing common
enterprise resources and capabilities
Common characteristics of application services:
 Expose functionality within a specific processing context
 Draw upon available resources within a given platform
 Are solution-agnostic
 Are generic and reusable
76
 Can be used to achieve point-to-point integration with other application services
 Are often inconsistent in terms of the interface granularity they expose
 May consist of a mixture of custom-developed services and third-party services
that have been purchased or leased
 When a separate business service layer exists there is a strong motivation to turn
all application services into generic utility services
 Generic utility services are implemented in a solution-agnostic manner, provide
reusable operations are composed by business services to fulfill business-centric
processing requirements
 If business logic does not reside in a separate layer, application services may be
required to implement services models more associated with business services
layer
 A single application service can also be classified as a business service if it
interacts directly with application logic and contains embedded business rules
9. Discuss about Business Service layer and Orchestration Service Layer.
Business service layer
 The business service layer represents a collection of services based on the business
service model called business services
 achieves a close alignment between an organization‘s business and technology
domains
 Each business service is assigned a functional context derived from one or more
existing organizational business models or specifications
 Designing a business service layer leads to the creation of two common business
service models, each of which establishes its own sub-layer
Task-centric business service –
a service that encapsulates business logic specific to a task or business process that involves
two or more business entities generally have limited potential and can be simply referred to as
task services
Entity-centric business service
A service that encapsulates processing logic associated with a specific business entity are
useful for creating highly reusable and business-process agnostic services and can be called
business entity services or entity services. If a separate application service exists, these two
types of business services can be positioned to compose application services to carry out their
business logic
A hybrid service is a service that contains both business and application logic often referred
to as a type of business service and is considered a variation of an application service and
resides in the application service layer. The business service layer is reserved for services that
only abstract business logic
Orchestration service layer
When orchestration is incorporated as part of a service-oriented architecture, it
assumes the role of the process. Orchestration allows a direct link to process logic to service
interaction within workflow logic combines business modeling with service-oriented
modeling and design brings the business process into the service layer positioned as a master
composition controller orchestration languages (WS-BPEL) realize workflow management
through a process service model. The orchestration layer introduces a parent level of
abstraction that alleviates the need for other services to manage interaction details required to
ensure that service operations are executed in a specific sequence. Within the orchestration
layer, process services compose other services that provide specific sets of functions,
independent of the business rules and scenario-specific logic required to execute a process
instance. All process services are controller services by their very nature. They are required to
compose other services to execute business process logic
Process services can also be referred to as orchestrated task services parent business
process layer
77
The introduction of an orchestration layer typically brings with it the requirement to
introduce new middleware into the IT infrastructure
Unit IV Web Services

Service descriptions – WSDL – Messaging with SOAP – Service discovery – UDDI – Message Exchange
Patterns – Orchestration – Choreography –WS Transactions.
PART-A
1. What are the design classifications of web services?

Service roles: temporary classification based on the roles it assumes during the runtime processing
of a message.
Service Models: permanent classification based on the application logic it provides and the roles it
assumes within a solution environment.
2. What are the conditions under which the web service takes the role of a service provider?
Web service is invoked via an external source such as service requestor.
Web service provides a published service description offering information about its features and
behaviors.
3. Define the term service provider.
Service provider replies to a request message with a response message . It is also used to identify
the organization responsible for actually providing the web service.
4. What are the conditions under which the web service takes the role of a service requestor?
The web service invokes a service provider by sending it a message.
The web service searches for and assesses the most suitable provider by studying available service
descriptions.
5. Define the term intermediaries.
Web services and service agents that route and process a message after it is initially sent and before
it arrives at its ultimate destination is referred to as intermediary services.
6. What are types of intermediaries?
Passive Intermediary- Responsible for sending messages to a subsequent location. It uses the info.
in SOAP message header. To determine the routing path of uses native routing logic to achieve
load balancing.
Active Intermediary- Also routes message to a forwarding destination. These services actively
process and alter the message contents. They alter data in header blocks and may even insert |
delete header blocks entirely.
7. Compare abstract and concrete description.
Abstract Description Concrete Description
It contains a series of parts that includes It is comprised of binding and

types, messages and port type (or interface). service parts.
8. Define the term service composition.

It does not apply to a single web-service but to a composite relationship between collections of
services. Any service can enlist one or more additional services to complete a given task. Any of
the enlisted services can call other services to complete a given sub-task.
9. How do you classify services based on service models?
Business Service model

Controller Service model
Utility Service model
78
10. How are the business services used within SOA?
As fundamental building blocks for representing business logic.
To represent corporate entity or information set
To represent business process logic.
As service composition members.
11. Define service endpoint.

A WSDL describes the point of contact for a service provider also known as service end point. It
provides a formal definition of the end point interface and also establishes the physical location of
the service.
12. What do you mean by a service contract?
It is the set of conditions that must be met and accepted by a potential service requester to enable
successful communication. It also refers to additional documents or agreements not expressed by
service descriptions.
13. Sketch the anatomy of a SOAP message. (Nov/Dec 2016)(Apr/Dec 2018)
A SOAP message is an ordinary XML document containing the following elements.

Envelope:(Mandatory): Defines the start and the end of the message.
Header:(Optional): Contains any optional attributes of the message used in processing the
message, either at an intermediary point or at the ultimate end point.
Body:(Mandatory): Contains the XML data comprising the message being sent.
Fault:(Optional): An optional Fault element that provides information about errors that
occurred while processing the message
14. Mention the SOAP nodes that are available.

1. SOAP sender
2. SOAP receiver
3. SOAP intermediary
4. Initial SOAP sender
5. Ultimate SOAP receiver
15. List out some primitive MEPs. (Nov/Dec 2016)
a. Request Response
 Define synchronous communication (also asynchronous)
 Establishes a simple exchange in message from a source to destination then
responds with a message back to the source
b. Fire and forget
 This asynchronous pattern is based on the unidirectional transmission of messages
from a source to one or more destinations
79
16. What are the variations of fire and forget message exchange?
a) Single destination pattern
b) Multi-cast destination pattern
c) Broadcast destination pattern
17. What are the services that a coordinator composition consists of?
a) Activation service
b) Registration service
c) Protocol-specific service
d) Co-ordinator service
18. What are the atomic transaction protocols that are available?
a. Completion Protocol
b. Durable 2PC Protocol
c. Volatile 2PC Protocol
19. Why is orchestration called ―the heart of SOA‖ ?
As it establishes a means of centralizing and controlling a great deal of inter and intra application
logic through a standardized service model.
20. Distinguish between orchestration and choreography.
Orchestration Choreography
Expresses organization-specific business Not necessarily owned by a single entity.

workflow . An organization owns and controls the Acts as a community interchange pattern
logic behind an orchestration, even if that logic used for collaborative purposes by
involves interaction with external business services from different provider entities.
partners.
21. What are the issues to be addressed by service layer abstraction?

a) What logic should be represented by services
b) How should services relate to existing application logic
c) How can services best represent business process logic
d) How can services be built and positioned to promote agility
22. What are wrapper services?

They consist of services that encapsulate (―wrap‖) some or all parts of a legacy environment to
expose legacy functionality to service requestors. They are used for legacy purpose. Example of
wrapper service: service adapter provided by legacy vendors.
23. What do you mean by service metadata?
The WSDL, XSD schema and policy together is called as service metadata.
24. What do you mean by UDDI? (April/May 2017)(Nov/Dec 2017)
UDDI is a platform-independent framework for describing services, discovering businesses, and
integrating business services by using the Internet.
 UDDI stands for Universal Description, Discovery and Integration
 UDDI is a directory for storing information about web services
 UDDI is a directory of web service interfaces described by WSDL
 UDDI communicates via SOAP
 UDDI is built into the Microsoft .NET platform
25. What are the two types of WSDL elements? / What are the types of service description?
(April/May 2017)
A WSDL document has two parts: abstract and concrete descriptions. The abstract section defines
SOAP messages in a language- and platform-independent manner. In contrast, the concrete
descriptions define site-specific matters such as serialization.
80
26. Mention the three types of choreography. (Apr/May 2018)
 Abstract Choreography
 Portable Choreography
 Concrete Choreography
Part B
1. Explain the structure of SOAP message and the importance of messaging with SOAP in detail.
(April/May 2017)
SOAP stands for Simple Object Access Protocol

ii. SOAP is a communication protocol
iii. SOAP is for communication between applications
iv. SOAP is a format for sending messages
v. SOAP communicates via Internet
vi. SOAP is platform independent
vii. SOAP is language independent
viii. SOAP is based on XML
ix. SOAP is simple and extensible
x. SOAP allows you to get around firewalls
xi. SOAP is a W3C recommendation
Message structure:
A SOAP message is an ordinary XML document containing the following elements.

Envelope:(Mandatory): Defines the start and the end of the message.
Header:(Optional): Contains any optional attributes of the message used in processing the message,
either at an intermediary point or at the ultimate end point.
Body:(Mandatory): Contains the XML data comprising the message being sent.
Fault:(Optional): An optional Fault element that provides information about errors that occurred
while processing the message
All these elements are declared in the default namespace for the SOAP envelope
SOAP Header element can be explained as:
• Header elements are optional part of SOAP messages.
• Header elements can occur multiple times.
• Headers are intended to add new features and functionality
• The SOAP header contains header entries defined in a namespace.
• The header is encoded as the first immediate child element of the SOAP envelope.
A message Exchange Pattern (MEP) is a pattern for the exchange of messages between two
communicating parties like a server and a client. The most common such pattern is the request-
response pattern where the client sends a request and the server sends a response back. From a
81
server perspective this is an input-output operation. Based on different combinations of input and
output, the WSDL specification defines 4 patterns:
 Input-Output Operations
 Input-Only Operations.
 Output-Input Operations.
 Output-Only Operations.
Request-Response (Input – Output operation)
The WSDL port receives a message and sends a correlated response back; and there will be an input
message followed by output in WSDL.
One way input (Input only operation)
Client sends a message without expecting a response from the service. An example might be a heart
beat server that listens to client ping at regular interval to see if it is up and running. WSDL port
only receives a message and there is an input message only in the WSDL
Solicit response (Output – input operation)
Server sends a message and client sends a response back mostly an acknowledgement or status
update. The WSDL port sends a message and receives a correlated message, and hence there is an
output message followed by an input message in WSDL.
Notification or Publish-Subscribe(Output only operation)
Here server sends a message without expecting a response. Could be used in a publish subscribe
scenario that connects a set of publishers to a set of subscribers.The WSDL port sends a message
without response, and hence there is an output message only in WSDL.
Synchronous and asynchronous web service calls
 Web service calls may be synchronous or asynchronous.
 Synchronous calls usually follow the request-response message exchange pattern over
HTTP.
 Solicit response may also be done synchronous.
 Asynchronous calls may follow one way input or publish-Subscribe message exchange
patterns.
 The client and the service may need to establish a mechanism to correlate the messages in
case of asynchronous calls, as the response may be sent later through a callback mechanism
implemented at the web service side.
2. What are the different types of SOAP nodes involved with processing a message.
SOAP Nodes
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:
82
3. Explain in detail about atomic transactions process with suitable examples. (Nov/Dec 2016)
(Apr/May 2017)
The WS-Transaction specification is an activity of the Web Service Interoperability

Organization (WS-I Organization) which is an industry-wide effort at standardizing how Web
services are requested and delivered.
Transactions have been around for almost as long as automated computer solutions have
existed. When managing certain types of corporate data, the need to wrap a series of changes into a
single action is fundamental to many business process requirements. Atomic transactions
implement the familiar commit and rollback features to enable cross-service transaction support
(Figure 1).
Figure 1. Atomic transactions apply an all-or-nothing requirement to work performed as
part of an activity.
Atomic transaction protocols

WS-Atomic Transaction is a coordination type, meaning that it is an extension created for
use with the WS-Coordination context management framework.
To participate in an atomic transaction, a service first receives a coordination context from
the activation service. It can subsequently register for available atomic transaction protocols. The
following primary transaction protocols are provided:
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.
These protocols are used to enable a two-Phase Commit (2PC) that manages an atomic transaction
across multiple service participants.
The atomic transaction coordinator:
Figure 2. The atomic transaction coordinator service model
The atomic transaction process
83
When WS-Atomic Transaction 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 (Figure 2) plays a key role in managing the participants of the
transaction process and in deciding the transaction's ultimate outcome.
Figure 3. The coordinator requesting that transaction participants prepare to vote
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 (Figure 3), 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 (Figure 4).
Figure 4. The transaction participants voting on the outcome of the atomic transaction
After the votes are collected, the atomic transaction coordinator enters the commit phase. It
reviews all votes and decides whether to commit or rollback the transaction.
The conditions of a commit decision are simple: if all votes are received and if all participants
voted to commit, the coordinator declares the transaction successful, and the changes are
committed.
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 (Figure 5).
84
Atomic transactions and SOA

The transactional functionality implemented in service-oriented solutions is done among the
components that executes an activity on behalf of a single service.
Figure 5. The coordinator aborting the transaction and notifying participants to rollback
all changes.
As more services emerge within an organization and as 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.
Not only do atomic transactional capabilities lead to a robust execution environment for SOA
activities, 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. WS-Atomic Transaction
is supported by the affected applications; this option broadens the application of the two-phase
commit protocol beyond traditional application boundaries (supporting service interoperability).
Figure 6 illustrates how atomic transactions support these aspects of SOA.
Figure 6. Atomic transaction relating to other parts of SOA.
4. Explain how a business activity is related to SOA in detail.

Business activities consist of long-running, complex transactions involving numerous
services.
85
Business Activity Protocols

•The Business Agreement With Participant Completion protocol, which allows a participant
to determine when it has completed its part in the business activity.
•The Business Agreement With Coordinator Completion protocol, which requires that a
participant rely on the business activity coordinator to notify it that it has no further processing
The Business Activity Coordinator
.
5. Explain in detail about orchestration. (Nov/Dec 2016)
Organizations that have employed Enterprise Application Integration (EAI) middleware

products to automate business processes or to integrate various legacy environments will be
familiar with the concept of orchestration.
A centrally controlled set of workflow logic facilitates interoperability between two or more
different applications.
A common implementation of orchestration is the hub-and-spoke model that allows multiple
external participants to interface with a central orchestration engine.
One of the driving requirements behind the creation of these solutions was to accommodate the
merging of large business processes.
With orchestration, different processes can be connected without having to redevelop the
solutions that originally automated the processes individually. Orchestration bridges this gap by
introducing new workflow logic.
The use of orchestration can significantly reduce the complexity of solution environments.
Workflow logic is abstracted and easily maintained than when embedded within individual solution
components.
The role of orchestration broadens in service-oriented environments.
Through the use of extensions that allow for business process logic to be expressed via services,
orchestration can represent and express business logic in a standardized, services-based venue.
When building service-oriented solutions, this provides a means of housing and controlling the
logic representing the process being automated.
Orchestration leverages the intrinsic interoperability sought by service designs by providing
potential integration endpoints into processes.
A key aspect to how orchestration is positioned within SOA is the fact that orchestrations
themselves exist as services.
86
Building upon orchestration logic standardizes process representation across an organization,
while addressing the goal of enterprise federation and promoting service-orientation.
Figure 1. An orchestration controls almost every facet of a complex activity
A primary industry specification that standardizes orchestration is the Web services - Business
Process Execution Language (WS-BPEL). WS-BPEL is a key second-generation extension and
uses its concepts and terminology as the basis relating to business process modeling.
1. Business protocols and process definition

The workflow logic that comprises an orchestration can consist of numerous business rules,
conditions, and events. Collectively, these parts of an orchestration establish a business protocol
that defines how participants can interoperate to achieve the completion of a business task.
The details of the workflow logic encapsulated and expressed by an orchestration are contained
within a process definition.
2. Process services and partner services
Identified and described within a process definition are the allowable process participants. First,
the process itself is represented as a service, resulting in a process service (Figure 2). 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 (Figure 3).
Figure 2. A process service coordinating and exposing functionality from three partner
services
Figure 3. The process service, after first being invoked by a partner service, then invokes
another partner service.
87
3. Basic activities and structured activities

WS-BPEL breaks down workflow logic into a series of predefined primitive
activities.
Basic activities (receive, invoke, reply, throw, wait) represent fundamental workflow actions
which can be assembled using the logic supplied by structured activities (sequence, switch, while,
flow, pick).
4. Sequences, flows, and links

Basic and structured activities can be organized so that the order in which they execute is
predefined.
A sequence aligns groups of related activities into a list that determines a sequential execution
order. Sequences are useful when one piece of application logic is dependent on the outcome of
another. Flows contain groups of related activities, but they introduce different execution
requirements.
Pieces of application logic can execute concurrently within a flow, meaning that there is not a
requirement for one set of activities to wait before another finishes. The flow does not finish until
all encapsulated activities have completed processing. This ensures a form of synchronization
among application logic residing in individual flows.
Links are used to establish formal dependencies between activities that are part of flows.
Before an activity fully can complete, any requirements established in outgoing links are met.
Before any linked activity can begin, requirements contained within any incoming links must
be satisfied. Rules provided by links are referred to as synchronization dependencies.
5. Orchestrations and activities
An activity is a term that can be applied to any logical unit of work completed by a service-
oriented solution.
The scope of a single orchestration can be classified as a complex, and long-running activity.
6. Orchestration and coordination

Orchestration, as represented by WS-BPEL, can fully utilize the WS-Coordination context
management framework by incorporating the WS-BusinessActivity coordination type.
This specification defines coordination protocols designed to support complex, long-running
activities.
7. Orchestration and SOA
Business process logic is at the root of automation solutions. Orchestration provides an
automation model where process logic is centralized, extensible and composable (Figure 4).
Through the use of orchestrations, service-oriented solution environments become extensible and
adaptive.
Orchestrations establish a point of integration for other applications, which makes an
implemented orchestration a key integration enabler.
Figure 4. Orchestration relating to other parts of SOA.
88
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 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. Orchestration
is an ingredient to achieving a state of federation within an organization that contains applications
based on different computing platforms.
Advancements in middleware allow orchestration engines to become fully integrated in
service-oriented environments.
The orchestration establishes comprehensive process logic that encompasses the business
activity and extends it to govern additional interaction scenarios with multiple vendor services.
For example, when one vendor cannot fulfill an order, the next vendor in line is sent the same
purchase order.
This cycle is repeated until either one vendor can complete the order in its entirety or until all
vendors have been queried. In the latter situation, the system assesses the best deal on the table by
applying a formula that takes into account the price, percentage of order to be filled, and backorder
terms. The orchestration logic manages all aspects of the process, including the involvement of
multiple vendor partner services and the business activity.
SUMMARY
An orchestration expresses a body of business process logic that is owned by a single organization.
An orchestration establishes a business protocol that defines a business process definition. The
workflow logic within an orchestration is broken down into a series of basic and structured
activities that can be organized into sequences and flows. Orchestration has been called the "heart
of SOA," as it establishes a means of centralizing and controlling a deal of inter and intra-
application logic through a standardized service model.
6. Explain in detail about choreography. (Nov/Dec 2016)
All organizations would agree on how internal processes should be structured, so that they
have to interoperate and automation solutions in perfect alignment.
The requirement for organizations to interoperate via services is becoming increasingly real
and increasingly complex.
This is true when interoperation requirements extend into the collaboration, where multiple
services from different organizations need to work to achieve a goal.
The Web Services-Choreography Description Language (WS-CDL) is specifications to
organize information exchange between multiple organizations, with a public collaboration (Figure
1).
Figure 1. Choreography enables collaboration between its participants
89
1. 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 organization controls the collaboration logic.
Choreographies establish universal interoperability patterns for inter-organization business tasks.
While the emphasis on choreography is B2B interaction, it can be applied to enable collaboration
between applications belonging to a single organization.
2. Roles and participants
Within any given choreography, a Web service assumes one of a number of predefined roles. This
establishes what the service does and what the service can do within the context of a particular
business task.
Roles can be bound to WSDL definitions, and those related are grouped accordingly, categorized as
participants (services).
3. Relationships and channels
Every action that is mapped out within choreography can be broken down into a series of message
exchanges between two services.
Each exchange between two roles in choreography is defined individually as a relationship.
Every relationship consists of exactly two roles.
Channels define the characteristics of the message exchange between two specific roles.
To facilitate complex exchanges involving multiple participants, channel information can be passed
around in a message.
This allows one service to send another the information required for it to be communicated with by
other services.
This is a feature of the WS-CDL specification, as it fosters dynamic discovery and increases the
number of participants within large-scale collaborative tasks.
4. Interactions and work units
The logic behind a message exchange is encapsulated within an interaction.
Interactions are the building blocks of choreographies because the completion of an interaction
represents progress within choreography.
Related to interactions are work units. These impose rules and constraints that must be followed to
for an interaction to successfully complete.
5. Reusability, composability, and modularity
Figure 2. Choreography composed of two smaller choreographies
Choreography can be designed in a reusable manner, allowing it to be applied to different

business tasks comprised of the same fundamental actions.
Using an import facility, choreography can be assembled from independent modules.
These modules can represent distinct sub-tasks and can be reused by different parent
choreographies (Figure 2).
Choreography composes a set of non-specific services to accomplish a task, choreographies can
be assembled into larger compositions.
90
6. Orchestrations and choreographies

While both represent complex message interchange patterns, there is a common distinction that
separates the terms "orchestration" and "choreography."
An orchestration expresses organization-specific business workflow. This means that an
organization owns and controls the logic behind an orchestration, if that logic involves interaction
with external business partners.
Choreography is not owned by a single entity. It acts as a community interchange pattern used
for collaborative purposes by services from different provider entities (Figure.3).
Figure 3. A choreography enabling collaboration between two different orchestrations
One can view an orchestration as a business-specific application of choreography. This view is

accurate, some of the functionality provided by the corresponding specifications (WS-CDL and
WS-BPEL) overlaps.
This is a consequence of these specifications being developed in isolation and submitted to separate
standards organizations (W3C and OASIS, respectively).
An orchestration is based on a model where the composition logic is executed and controlled in a
centralized manner. Choreography assumes that there is no single owner of collaboration logic. One
area of overlap between the current orchestration and choreography extensions is that orchestrations
can be designed to include multi-organization participants.
An orchestration can effectively establish cross-enterprise activities in a similar manner as
choreography. An orchestration is owned and operated by a single organization.
7. Choreography and SOA
The concept of exposing business logic through autonomous services can be applied to about
any implementation scope. Two services within a single organization, each exposing a simple
function, can interact via a MEP to complete a simple task.
Two services belonging to different organizations, exposing functionality from entire enterprise
business solutions can interact via choreography to complete a complex task.
Both scenarios involve two services, and both scenarios support SOA implementations.
Choreography can assist in the realization of SOA across organization boundaries (Figure 4). While
it natively supports composability, reusability, and extensibility, choreography can increase
organizational agility and discovery.
Organizations are able to join into multiple online collaborations, which can dynamically extend
or alter related business processes that integrate with the choreographies.
By being able to pass around channel information, participating services can make third-party
organizations aware of other organizations with which they have had contact.
Figure 4. Choreography relating to other parts of SOA

91
SUMMARY
Choreography is a complex activity comprised of a service composition and a series of MEPs.
Choreographies consist of multiple participants that can assume different roles and that have
different relationships.
Choreographies are reusable, composable, and can be modularized.
The concept of choreography extends the SOA vision to standardize cross-organization
collaboration.
7. Explain in detail about message exchange patterns in web services. (April/May 2017)
(Nov/Dec 2017)
Every task automated by a Web service can differ in the application logic being executed and the
role played by the service in the overall execution of the business task.
Regardless of how complex a task is, all require the transmission of multiple messages. The
challenge lies in coordinating these messages in a particular sequence so that the individual actions
performed by the message are executed properly and in alignment with the overall business task
(Figure 1).
Figure. 1 Not all message exchanges require both requests and responses.
Message Exchange Patterns (MEPs) represent a set of templates that provide a group of already
mapped out sequences for the exchange of messages.
The example is a request and response pattern where the MEP states that upon successful
delivery of a message from one service to another, the receiving service responds with a message
back to the initial requestor.
Many MEPs have been developed, each addressing a common message exchange requirement. It
is useful to have a understanding of important MEPs, as you will be applying MEPs to specific
communication requirements when designing service-oriented solutions.
i. Primitive MEPs
92
Before the arrival of contemporary SOA, messaging frameworks were used by various
messaging-oriented middleware products. A set of primitive MEPs has been in existence for some
time.
a.Request-response
This is the popular MEP in use among distributed application environments and the one pattern
that defines synchronous communication (this pattern can be applied asynchronously).
The request-response MEP (Figure.2) establishes a simple exchange in which a message is first
transmitted from a source (service requestor) to a destination (service provider).
Upon receiving the message, the destination (service provider) then responds with a message
back to the source (service requestor).
Figure 2. The request-response MEP
b.Fire-and-forget
This asynchronous pattern is based on the unidirectional transmission of messages from a source
to one or more destinations (Figure 3).
A number of variations of the fire-and-forget MEP exist, including:
The single-destination pattern, where a source sends a message to one destination only.
The multi-cast pattern, where a source sends messages to a predefined set of destinations.
The broadcast pattern, which is similar to the multi-cast pattern, except that the message
is sent out 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.
Figure 3. The fire-and-forget MEP
ii.Complex MEPs
Even though a message exchange pattern can facilitate the execution of a simple task, it is a
building block intended for composition into larger patterns.
Primitive MEPs can be assembled in various configurations to create different types of messaging
models, sometimes called complex MEPs. A classic example is the publish-and-subscribe model.
The publish-and-subscribe pattern introduces new roles for the services involved with the message
exchange.
They become publishers and subscribers, and each may be involved in the transmission and
receipt of messages.
This asynchronous MEP accommodates a requirement for a publisher to make its messages
available to a number of subscribers interested in receiving them. The steps involved are similar to
the following:
Step 1. The subscriber sends a message to notify the publisher that it wants to receive
messages on a particular topic.
93
Step 2. Upon the availability of the requested information, the publisher broadcasts messages
on the particular topic to all of that topic's subscribers.
This pattern is an example of how to aggregate primitive MEPs, as shown in Figure 4.
Step 1 in the publish-and-subscribe MEP could be implemented by a request-response MEP,
where the subscriber's request message, indicating that it wants to subscribe to a topic, is responded
to by a message from the publisher, confirming that the subscription succeeded or failed.
Figure 4. The publish-and-subscribe messaging model is a composite of two primitive
MEPs.
Step 2 then could be supported by one of the fire-and-forget patterns, allowing the
publisher to broadcast a series of unidirectional messages to subscribers. WS-* specifications
that incorporate this messaging model include:
 WS-BaseNotification
 WS-BrokeredNotification
 WS-Topics
 WS-Eventing
iii.MEPs and SOAP

The SOAP standard provides a messaging framework designed to support single-direction
message transfer. The extensible nature of SOAP allows countless messaging characteristics and
behaviors to be implemented via SOAP header blocks. The SOAP language provides an optional
parameter that can be set to identify the MEP associated with a message.
iv. MEPs and WSDL
Operations defined within service descriptions are comprised of message definitions.
The exchange of these messages constitutes the execution of a task represented by an
operation. MEPs play a role in WSDL service descriptions as they can coordinate the input and
output messages associated with an operation.
The association of MEPs to WSDL operations embeds expected conversational behavior into
the interface definition.
WSDL operations support different configurations of incoming, outgoing, and fault messages.
These configurations are equivalent to message exchange patterns, but within the WSDL
specification, they are referred to as patterns.
WSDL definitions do not restrict an interface to these patterns; they are considered minimal
conversational characteristics that can be extended.
Release 1.1 of the WSDL specification provides support for four message exchange patterns.
These patterns are applied to service operations from the service provider or endpoint.
In WSDL 1.1 terms, they are represented as follows:
94
 Request-response operation: Upon receiving a message, the service must respond with a
standard message or a fault message.
 Solicit-response operation: Upon submitting a message to a service requestor, the service
expects a standard response message or a fault message.
 One-way operation: The service expects a single message and is not obligated to respond.
 Notification operation: The service sends a message and expects no response.
Of these four patterns (Figure 5), the request-response operation and one-way operation MEPs
are recommended by the WS-I Basic Profile.
Figure 5. The four basic patterns supported by WSDL 1.1
WSDL support recent revisions of the MEPs specification and extended this support to
include additional variations.
Release 2.0 of the WSDL specification extends MEP support to eight patterns 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 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 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 or processing error.
 The robust out-only pattern, which, like the out-only pattern, has an outbound message
initiating the transmission. 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. The
delivery of a response message is optional and should not be expected by the service
requestor that originated the communication. This pattern 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 supported.
Until version 2.0 of WSDL becomes commonplace, these new patterns will be of limited
importance to SOA. Version 2.0 of the WSDL specification was labeled 1.2.
The working group responsible for the new specification decided that the revised feature set
constituted a full new version number.
iv.MEPs and SOA
MEPs are highly generic and abstract in nature. They relate to an interaction between two
services.
Their relevance to SOA is equal to their relevance to the abstract Web services framework.
95
They are a fundamental and essential part of any Web services-based environment, including
SOA.
SUMMARY:
An MEP is a generic interaction pattern that defines the message exchange between two services.
MEPs have been around for as long as messaging-based middleware products have been used.
MEPs can be composed to support the creation of larger, more complex patterns.
The WSDL and SOAP specifications support specific variations of common MEPs.
8. Discuss in detail about service discovery and UDDI. (April/May 2017)

The Service Registry/Repository and Service Discovery play a major role in SOA lifecycle.
During Service Modeling, a registry and repository can be used to create or reuse service metadata,
vocabularies and XML schemas.
During service development, a registry and repository can be used to locate services for reuse
and to enable service composition.
During service deployment, service descriptions stored in a registry and repositories are used by
runtimes such as ESB (Enterprise Service Bus) to enable dynamic interaction between services.
Service discovery is the process of locating Web service providers, and retrieving Web services
descriptions that have been previously published.
The mechanism involved in performing Service Discovery is a service registry, which contains
relevant metadata about available and upcoming services as well as pointers to the corresponding
service contract documents that can include Service Level Agreement (SLA).
In modern architectures nodes come and go and you need to decouple individual service
instances from the knowledge of the deployment topology of your architecture.
After the discovery process is complete, the service developer or client application should know
the exact location of a Web service (URI), its capabilities, and how to interface with it.
Benefits of Service Discovery:
Discovery of the service, its status, and its owner will be critical to achieve the reuse benefits of
SOA.
Dynamic service registration and discovery becomes more important in these scenarios in order
to avoid service interruption.
Handling Fail over of service instances
Load balancing across multiple instances of a Service Handling issues arising due to unreliable
network.
Service Registry and/or Repository and Service Discovery should be considered right from the
design of SOA Implementation.
Universal Description, Discovery and Integration (UDDI) is an XML-based standard for

describing, publishing, and finding Web services.
UDDI is a specification for a distributed registry of Web services.
UDDI is platform independent, open framework.
UDDI can communicate via SOAP, CORBA, Java RMI Protocol.
UDDI uses WSDL to describe interfaces to web services.
UDDI is seen with SOAP and WSDL as one of the three foundation standards of web
services.
UDDI is an open industry initiative enabling businesses to discover each other and
define how they interact over the Internet.
UDDI has two parts:
A registry of all web service's metadata including a pointer to the WSDL description of a
service.
A set of WSDL port type definitions for manipulating and searching that registry.
A business or company can register three types of information into a UDDI registry. This
information is contained into three elements of UDDI. The three elements White pages, Yellow
pages and Green pages.
(1) White pages: This category contains:
96
Basic information about the Company and its business.
Basic contact information including business name, address, contact phone number etc. A
unique identifiers for the company tax IDs. This information allows others to discover
your web service based upon your business identification.
(2) Yellow pages: This category contains:
This has more details about the company, and includes descriptions of the kind of
electronic capabilities the company can offer to anyone who wants to do business with it.
It uses accepted industrial categorization schemes, industry codes, product codes, business
identification codes. It make easier for companies to search through the listings and find
exactly what they want.
(3) Green pages:
This category contains technical information about a web service. This is what allows someone
to bind to a Web service after it's been found. This includes:
The various interfaces
The URL locations
Discovery information and similar data required to find and run the Web service.
UDDI is not restricted to describing web services based on SOAP. UDDI can be used to
describe any service, from a single web page or email address to SOAP, CORBA, and Java
RMI services.
UDDI Data Model
UDDI includes an XML Schema that describes five data structures:
businessEntity, businessService, bindingTemplate, tModel and publisherAssertion.
A.businessEntity data structure:
The business entity structure represents the provider of web services. Within the UDDI registry,
this structure contains information about the company including contact information, industry
categories, business identifiers, and a list of services provided.
Here is an example of a fictitious business's UDDI registry entry:
<businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-
70E212685A40" operator="http://www.ibm.com"
authorizedName="John
Doe"> <name>Acme
Company</name>
<description>
We create cool Web services
</description>
<contacts>
<contact useType="general info">
<description>General
Information</description> <personName>John
Doe</personName> <phone>(123) 123-
1234</phone>
<email>jdoe@acme.com</email>
</contact>
</contacts>
<businessServices>
...
</businessServices>
<identifierBag>
<keyedReference
tModelKey="UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823"
name="D-U-N-S"
value="123456789" />
</identifierBag>
97
<categoryBag>
<keyedReference
tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"
name="NAICS"
value="111336" />
</categoryBag> </ businessEntity >
B.businessService data structure:
The business service structure represents an individual web service provided by the business
entity. Its description includes information on how to bind to the web service, what type of
web service it is, and what taxonomical categories it belongs to.
Here is an example of a business service structure for the Hello World web service:
<businessService serviceKey="uuid:D6F1B765-BDB3-4837-828D-
8284301E5A2A" businessKey="uuid:C0E6D5A8-C446-4f01-99DA-
70E212685A40">
<name>Hello World Web Service</name>
<description>A friendly Web service</description>
<bindingTemplates>
...
</bindingTemplates>
<categoryBag />
</businessService
Universally Unique Identifiers (UUIDs) uses the businessKey and serviceKey attributes.
Every business entity and business service is uniquely identified in all UDDI registries through
the UUID assigned by the registry when the information is first entered.
C.bindingTemplate data structure:
Binding templates are the technical descriptions of the web services represented by the
business service structure. A single business service may have multiple binding templates.
The binding template represents the actual implementation of the web service.
Here is an example of a binding template for Hello World:
<bindingTemplate serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
bindingKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
<description>Hello World SOAP
Binding</description> <accessPoint
URLType="http">
http://localhost:8080
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
<instanceDetails>
<overviewDoc>
<description>
references the description of the
WSDL service definition
</description>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
98
Because a business service may have multiple binding templates, the service may specify
different implementations of the same service, each bound to a different set of protocols or a
different network address.businessEntity>.
D.tModel data structure:
The tModel is the last core data type. The tModel stands for technical model.
A tModel is a way of describing the various business, service, and template structures stored
within the UDDI registry. Any abstract concept can be registered within UDDI as a tModel.
If you define a new WSDL port type, you can define a tModel that represents that port type
within UDDI.
Then, you can specify that a given business service implements that port type by associating
the tModel with one of that business service's binding templates.
Here is an example of tModel representing the HelloWorldInterface port type:
<tModel tModelKey="uuid:xyz987..."
operator="http://www.ibm.com"
authorizedName="John Doe">
<name>HelloWorldInterface Port Type</name>
<description>
An interface for a friendly Web service
</description>
<overviewDoc>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</tModel>
E.publisherAssertion data structure:
This is a relationship structure putting into association two or more businessEntity structures
according to a specific type of relationship, such as subsidiary or department.
The publisherAssertion structure consists of the three elements fromKey (the first
businessKey), toKey (the second businessKey) and keyedReference.
The keyedReference designates the asserted relationship type in terms of a keyName keyValue
pair within a tModel, uniquely referenced by a tModelKey.
<element name="publisherAssertion" type="uddi:publisherAssertion"
/> <complexType name="publisherAssertion">
<sequence>
<element ref="uddi:fromKey" />
<element ref="uddi:toKey" />
<element ref="uddi:keyedReference" />
</sequence>
</complexType>
9. Explain service description with WSDL in detail. (Nov/Dec 2017)
WSDL:
A WSDL document can be thought of as a contract between a client and a server. It
describes what the Web Service can do, where it can be found, and how to invoke it. Essentially,
WSDL defines an XML grammar that describes Web Services (and in general, any network
service) as collections of communications endpoints (that is, the client and the server) that are able
to exchange messages with each other.
WSDL documents use the following elements:
• definitions. Associates the Web Service with its namespaces.

• types. A container for data type definitions, typically using a XML Schema Definition
(XSD) or possibly some other type system.
• message. An abstract, typed definition of the data contained in the message.
• operation. An abstract description of an action that the Web Service supports.
99
• portType. The set of operations supported by one or more endpoints.
• binding. A specification of the protocol and data format for a particular portType.
• port. An endpoint, defined in terms of a binding and its network address (typically a URL).
This is not a TCP/IP port, which is represented by a number.
• service. A collection of related endpoints.
The structure of a typical WSDL document is shown
WSDL Ports
The <portType> element is the most important WSDL element.
It describes a web service, the operations that can be performed, and the messages that are involved.
The <portType> element can be compared to a function library (or a module, or a class) in a
traditional programming language.
WSDL Messages
The <message> element defines the data elements of an operation.
Each message can consist of one or more parts. The parts can be compared to the parameters of a
function call in a traditional programming language.
WSDL Types
The <types> element defines the data types that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
WSDL Bindings
The <binding> element defines the data format and protocol for each port type.
Calculator.xsd_1(http://localhost:8080/Calc/Calculator?xsd=1):
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:tns="http://p1/" xmlns:xs=http://www.w3.org/2001/XMLSchema version="1.0"
targetNamespace="http://p1/">
<xs:element name="add" type="tns:add"/>

<xs:element name="addResponse" type="tns:addResponse"/>
<xs:element name="sub" type="tns:sub"/>
<xs:element name="subResponse" type="tns:subResponse"/>
<xs:complexType name="sub">
<xs:sequence>
<xs:element name="a" type="xs:int"/>
<xs:element name="b" type="xs:int"/>
</ xs:sequence>
</xs:complexType>
<xs:complexType name="subResponse">
<xs:sequence>
100
<xs:element name="return" type="xs:int"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="add">
<xs:sequence>
<xs:element name="a" type="xs:int"/>
<xs:element name="b" type="xs:int"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="addResponse">
<xs:sequence>
<xs:element name="return" type="xs:int"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
10. Briefly explain the characteristics of web service framework and web service roles.
(April/May 2017) (Nov/Dec 2017)
Service Requestor - application that is looking for and invoking an interaction with a service Service
Provider - owner of the services
Service Registry - searchable registry where service provider publishes their service descriptions and where
service find service request.
101
Unit- V Building SOA-Based Applications

Service Oriented Analysis and Design – Service Modeling – Design standards and guidelines -- Composition –
WS-BPEL – WS-Coordination – WS-Policy – WS-Security – SOA support in J2EE.
Part – A
1. What are the objectives of service-oriented analysis?
a.What services need to be built.
b.What logic should be encapsulated by each service.
2. Define service modeling.
It is the process of identifying candidate service operations and grouping them in candidate
services
3. What are the benefits for incorporating service-orientation into business process level?
a. Business services build agility into business models.
b. Business services prepare a process for orchestration.
c. Business services enable reuse.
d. Business services can realize service-oriented enterprise.
4. How are the business services derived?
They are derived from common business model document, including use-case models, business
process definitions and entity models.
5. What is service modeling process? (Nov/Dec 2017)
It is fundamentally a process of gathering and organizing business model information. It is the
process of identifying candidate service operations and grouping them in candidate services.
6. Mention any 2 goals of performing service oriented design.
a. Determine the core set of architectural extensions.
b. Set the boundaries of the architecture.
7. Give the steps for composing SOA.
a. Choose the service layers.
b. Position the core standards.
c. Choose SOA extensions.
8. What are the standards that web service depends on? (April/May 2017)
• XML
• XML schema
• WSDL
• SOAP
9. Mention any 4 practical considerations that must be taken into account on deciding what
service layer configuration an SOA is to be standardized upon.
a. Existing configuration
b. Required standards
c. Service composition performance
d. Service deployment
10. Give the step-by-step process in service oriented analysis. (Nov/Dec 2016)
Step 1: Define business automation requirements
Step 2: Identify existing automation systems
Step 3: Model candidate services
11. List the goals of service-oriented analysis.
a. Define a preliminary set of service operation candidates.
b. Group service operation candidates into logical contexts. These contexts represent
service candidates.
c. Define preliminary service boundaries so that they do not overlap with any existing or
planned services.
d. Identify encapsulated logic with reuse potential.
e. Ensure that the context of encapsulated logic is appropriate for its intended use.
f. Define any known preliminary composition models.
102
12. Write the steps in the individual design process.
The first step is an SOA composition exercise that helps identify the architectural
boundary of our planned solution. The remaining steps consist of the following individual
design processes:
• Entity-centric business service design
• Application service design
• Task-centric business service design
• Service-oriented business process design
13. What is J2EE? (April/May 2017)
The Java 2 Platform is a development and runtime environment based on the Java programming
language. It is a standardized platform that is supported by many vendors that provide
development tools, server runtimes, and middleware products for the creation and deployment of
Java solutions. The Java 2 Platform Enterprise Edition (J2EE) is built to support large-scale,
distributed solutions. The Servlets + EJBs and Web + EJB Container layers (as well as the JAX-
RPC Runtime) relate to the Web and Component Technology layers.Web technology is
incorporated is largely dependent on how a vendor chooses to implement this part of a J2EE
14. architecture.
List the components used to build J2EE web applications.
a. Java Server Pages
b. Struts
c. Java servlets
d. Enterprise Java Beans(EJB)
15. Compare "Building Blocks" versus "Service Models".
 Building blocks are not an independent means of classifying service logic.
 While service models are useful for classifying the nature of logic encapsulated by a
service, building blocks classify the scope of service logic.
 The service model always will apply to a single service, but a building block can apply to a
range of logic.
 A building block can also represent a subset of a service's logic or the collective logic of
multiple services.
16. What do you mean by the binding element in WSDL?
 The binding element begins the concrete portion of the service definition, to assign a
communications protocol that can be used to access and interact with the WSDL.
 The binding element appears similar in structure to the portType element. The binding
construct contains one or more operation elements.
 The additional soap:binding and soap:operation elements combined within the construct
syntax. These are what establish the SOAP protocol as the manner in which this WSDL
can be communicated with.
17. What is JAX-WS?
JAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for building web
services and clients that communicate using XML. JAX-WS allows developers to write
message- oriented as well as RPC-oriented web services.
18. What does the Java web service developer pack include?
Java API for XML Messaging (JAXM),Java API for XML Processing (JAXP),Java API
for XML Registries (JAXR),Java API for XML based RPC (JAX-RPC),Java API for XML
Web Services (JAX-WS),SOAP with Attachments API for Java (SAAJ),Java Server Pages
Standard Tag Library (JSTL),Java Server Faces,Java WSDP Registry Server,Web
Applications Deployment Tool,Ant Build Tool,Apache Tomcat servlet container
19. What are the types of WS-Coordination?
a. Central Coordination
b. Distributed Coordination
103
20. Define WS-Policy.(Apr/May 2017)
• The WS-Policy framework is comprised of the following three specifications:
– WS-Policy
– WS-PolicyAssertions WS-PolicyAttachments
• These collectively provide the following elements covered in this section,
which demonstrate how policies are formulated and attached to element or
document-level subjects:
– Policy element
– TextEncoding, Language, SpecVersion, and MessagePredicate
assertions
– ExactlyOne element
– All element
– Usage and Preference attributes
– PolicyReference element
21. List the components in WS-Policy Framework.
a. Top-level container element.
b. Policy operators that group assertions
c. Attributes that determine policy usage.
22. List the initial set of assertions in WS-Policy assertions.
a. Text encodingb.b.Language c. SpecVersion d. MessagePredicate
23. What is the purpose of WS-Security language basics?
WS-Security framework provides extensions that is used to implement message-based
security measures. These protect message contents during transport and during processing
by service intermediaries.
24. How WS-Security relates to the other WS-* specifications?
a. WS-Security can be used to sign and encrypt headers provided by WS-Addressing.
b. WS-Security can protect messages exchanged via WS-Meta-data exchange.
c. WS-Security protects SOAP messages.
d. WS-Security can be used to protect message sequences governed by WS-Reliable
messaging.
25. What do you mean by WS-Security? (April/May 2017)
WS-Security:
 soap message protection through message integrity, confidentiality, and single
message authentication
 extensible and flexible (multiple security tokens, trust domains, signature formats,
and encryption technologies. )
 a flexible set of mechanisms that can be used to construct a range of security
protocols
26. What are the two protocols that are used with WS-Coordination?
a. WS-Business activity
b. WS-Atomic transaction
27. What is BPEL?
Business Process Execution Language is the ability to capture both the constituent
activities of a workflow and relationship between partners involved in that workflow in a
platform neutral format (XML) and supports the highest possible level of interoperability
by basing the technology on commonly adopted web service standard.
28. What are the components of BPEL stack?

a. A means of capturing enterprise interdependencies with partners and associated
service links and service references to an active partner at runtime.
b. Message correlation layers that ties together message and specific workflow instances.
c. State Management features to maintain, update and interrogate parts of the process
state.
d. Scopes where individual activities are composed to form actual algorithmic
workflows.
104
29. Give the activity types in BPEL.
a. Structuring activities
b. Communication activities
c. Miscellaneous activities
d. Exception handling activities.
30. Write the syntax for getVariableData function in WS-BPEL. (Nov/Dec 2016)
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.
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.
31. What are the attributes of invoke element in BPEL? (Nov/Dec 2017)
Attribute Description
partnerLink This element names the partner service via its corresponding
partnerLink.
portType The element used to identify the portType element of the partner service.
operation The partner service operation to which the process service will need to
send its request.
inputVariable The input message that will be used to communicate with the partner
service operation. Note that it is referred to as a variable because it is
referencing a WSBPEL variable element with a messageType attribute.
outputVariable This element is used when communication is based on the request-

response MEP.
The return value is stored in a separate variable element.
105
Part B
1. Discuss the step by step process of service modeling in detail. (Nov/Dec 2016) (Nov/Dec
2017)
 A service modeling process is essentially an exercise in organizing the information we
gathered in Steps 1 and 2 of the parent service-oriented analysis process.
 "Services" versus "Service Candidates"
o Candidate - The primary goal of the service-oriented analysis stage is to figure
out what it is we need to later design and build in subsequent project phases.
We are producing abstract candidates that may or may not be realized as part
of the eventual concrete design.
Service Candidates - Their behavior has significant departure from the corresponding original
candidate having subjected to the realities of the technical architecture. Then we propose service
 operation candidates. Finally, service candidates and service operation candidates are
the end-result of a process called service modeling
 Process description
o A series of 12 steps that comprise a proposed service modeling process
=
Step 1: Decompose the business process

o 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
o 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.
o 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.
o By filtering out these parts we are left with the processing steps most relevant
to our service modeling process.
Step 3: Abstract orchestration logic
106
o We should identify the parts of the processing logic that this layer would
potentially abstract. (If you are not incorporating an orchestration service layer,
then skip this step.)
o Potential types of logic suitable for this layer include:
 business rules
 conditional logic
 exception logic
 sequence logic
o These forms of orchestration logic may or may not be represented accurately
by a step description. In this case, only remove the condition and leave the
action.
 Also some of the identified workflow logic likely will be dropped
eventually. This is because not all processing steps necessarily become
service operations
Step 4: Create business service candidates
o 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 you end up with will depend on the types of
business services you have chosen to build
o 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.
o Also it is encouraged that entity-centric business service candidates be
equipped with additional operation candidates that facilitate future reuse
Step 5: Refine and apply principles of service-orientation
o To make our service candidates truly worthy of an SOA, we must take a closer
look at the underlying logic of each proposed service operation candidate.
o This step gives us a chance to make adjustments and apply key service-
orientation principles.
o This is where the study we performed in the Native Web service support for
service-orientation principles section becomes useful.
o We identified the following four key principles as those not intrinsically
provided through the use of Web services:
 reusability
 autonomy
 statelessness
 Discoverability
 Of these four, only the first two are important to us at the service
modeling stage
Step 6: Identify candidate service compositions
o 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.
o This exercise accomplishes the following:
 It gives you a good idea as to how appropriate the grouping of your
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.
Step 7: Revise business service operation grouping
107
o 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
o By the end of Step 6, you will have created a business-centric view of your
services layer. This view could very well consist of both application and
business service candidates, but the focus so far has been on representing
business process logic.
o This next series of steps is optional and more suited for complex business
processes and larger service-oriented environments. It requires that you more
closely study the underlying processing requirements of all service candidates
to abstract any further technology-centric service candidates from this view
that will complete a preliminary application services layer.
o Specifically, what you need to determine 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.
 Whether the required application logic spans application boundaries. In
other words, is more than one system required to complete this action?
Step 9: Identify application service operation candidates
o Break down each application logic processing requirement into a series of
steps. Be explicit about how you label these steps so that they reference the
function they are performing. Ideally, you would not reference the business
process step for which this function is being identified.
Step 10: Create application service candidates
o Group these processing steps according to a predefined context. With
application service candidates, the primary context is a logical relationship
between operation candidates.
o 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
Step 11: Revise candidate service compositions
o 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
o 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.
2. Explain in detail the application service design process.
• 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:
108
• 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
• The service-oriented design process
– We first establish a parent process that begins with some preparatory work.
This leads to a series of iterative processes that govern the creation of different
types of service designs and, ultimately, the design of the overall solution
workflow
Step 1: Compose SOA

A fundamental quality of SOA is that each instance of a service-oriented architecture
is uniquely composable. Although most SOAs will implement a common set of shared
technologies based on key XML and first-generation Web services specifications, the
modular nature of the WS-* specification landscape allows for extensions to this core
architecture to be added as required.
• This step consists of the following three further steps
1.Choose service layers.
2.Position core SOA standards.
3.Choose SOA extensions.
109
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.
• Our primary input for each of these service design processes is the corresponding
service candidates we produced in the service modeling process during the service-
oriented analysis.
Step 5: Design service-oriented Business process
• Upon establishing an inventory of service designs, we proceed to create our
orchestration layer the glue that binds our services with business process logic. This
step results in the formal, executable definition of workflow logic, which translates
into the creation of a WS-BPEL process definition.
3. Illustrate in detail about the WS-BPEL with code snippets. (Nov/Dec 2016)
Web Services Business Process Execution Language (WS-BPEL) is

a standard or language for automating business processes. It is basically one of the
programming languages that aim to describe any process possible.
WS-BPEL language to demonstrate how process logic can be described as part of a concrete
definition (Figure 1) that can be implemented and executed via a compliant orchestration engine.
Although you will be using a process modeling tool and will not be required to author your process
definition from scratch, knowledge of WS-BPEL elements is useful and required.
WS-BPEL modeling tools make reference to these elements and constructs, and you may be
required to dig into the source code they produce to make further refinements.
1. A brief history of BPEL4WS and WS-BPEL
The Business Process Execution Language for Web Services (BPEL4WS) releases the BPEL4WS
1.0 specification, a joint effort by IBM, Microsoft, and BEA.
This document proposed an orchestration language inspired by previous variations, such as IBM's
Web Services Flow Language (WSFL) and Microsoft's XLANG specification.
Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS
specification was released.
This version received more attention and vendor support, leading to a number of commercially
available BPEL4WS-compliant orchestration engines.
Prior to this release, the BPEL4WS specification was submitted to an OASIS technical committee
so that the specification could be developed into an official, open standard.
The technical committee is in the process of finalizing the release of the next version of BPEL4WS.
The language has been renamed to the Web Services Business Process Execution Language, or
WS-BPEL.
110
2. The process element
The root element of a WS-BPEL is process definition. It is assigned a name value using the name
attribute and is used to establish the process definition-related namespaces.
Example. 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 process construct contains a series of common following child elements.
3. 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.
Partner services can be invoked by the process service.
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.
Depending on the nature of the communication, the role of the process service will vary. For
instance, a process service that is invoked by an external service may act in the role of
"TimesheetSubmissionProcess" .
When this same process service invokes a different service to have an invoice verified, it acts
within a different role, "InvoiceClient."
The partnerLink element contains the myRole and partnerRole attributes that establish the service
provider role of the process service and the partner service.
The myRole attribute is used when the process service is invoked by a partner client service,
because the process service acts as the service provider.
The partnerRole attribute identifies the partner service that the process service will be invoking.
myRole and partnerRole attributes can be used by the same partnerLink element when it is expected
that the process service will act as service requestor and service provider with the same partner
service.
For example, during asynchronous communication between the process and partner services, the
myRole setting indicates the process service's role during the callback of the partner service.
Example. The partnerLinks construct containing one partnerLink element in which the process
service is invoked by an external client partner and four partnerLink elements that identify
partner services invoked by the process service.
<partnerLinks>
<partnerLink name="client"
partnerLinkType="tns:TimesheetSubmissionType"
myRole="TimesheetSubmissionServiceProvider"/>
<partnerLink name="Invoice"
111
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>
Each of the partnerLink elements contains a partnerLinkType attribute. This refers to the
partnerLinkType construct.
4. 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. These
constructs are embedded within the WSDL documents of every partner service.
The partnerLinkType construct contains one role element for each role the service can play, as
defined by the peartnerLink myRole and partnerRole attributes.
A partnerLinkType will have either one or two child role elements.
Example. 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>
The 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 use the same process service portType elements.
In version 2.0 of the WS-BPEL specification, it is being proposed that the portType element be
changed so that it exists as an attribute of the role element.
5. The variables element

WS-BPEL process service 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 attributes: messageType, element, or type.
The messageType attribute allows for the variable to contain an entire WSDL-defined message,
whereas the element attribute refers to an XSD element construct. The type attribute can be used to
represent an XSD simpleType, such as string or integer.
112
Example. 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> 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.
4. Explain service-oriented analysis in detail.
• 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.
• The service-oriented analysis process
– Service-oriented analysis can be applied at different levels, depending on
which of the SOA delivery strategies are used to produce services.
– The previous chapter, the chosen 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?
– The service-oriented analysis process is a sub-process of the overall SOA
delivery lifecycle.
113
5.Explain SOA platform and describe the APIs in J2EE which is used to built SOA.
(Apr/May 2018)
• The Java 2 Platform Enterprise Edition (J2EE) is one of the two primary platforms
currently being used to develop enterprise solutions using Web services.
• Platform overview
– The Java 2 Platform is a development and runtime environment based on the
Java programming language. It is a standardized platform that is supported by
many vendors that provide development tools, server runtimes, and
middleware products for the creation and deployment of Java solutions.
– The Java 2 Platform is divided into three major development and runtime
platforms, each addressing a different type of solution.
• 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 been in existence for over five
years and has been used extensively to build traditional n-tier
applications with and without Web technologies.
114
• Three of the more significant specifications that pertain to SOA are listed here:
– 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 (explained later).
– 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 (explained
later). 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.
• Examples of these services include transaction management,
concurrency management, operation-level security, and object pooling.
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
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
115
• Java API for XML Processing (JAXP) This API is used to process XML document
content using a number of available parsers. Both Document Object Model (DOM)
and Simple API for XML (SAX) compliant models are supported, as well as the
ability to transform and validate XML documents using XSLT stylesheets and XSD
schemas. Example packages include:
– javax.xml.parsers A
– org.w3c.dom and org.xml.sax These packages expose the industry standard
DOM and SAX document models.
– javax.xml.transform A
• Java API for XML-based RPC (JAX-RPC) The most established and popular SOAP
processing API, supporting both RPC-literal and document-literal request-response
exchanges and one-way transmissions. Example packages that support this API
include:
– javax.xml.rpc & javax.xml.rpc.server These packages contain a series of core
functions for the JAX-RPC API
– javax.xml.rpc.handler & javax.xml. rpc.handler.soap API functions for runtime
message handlers are provided by these collections of classes. (Handlers are
discussed shortly in the Service agents section.)
– javax.xml.soap & javax.xml.rpc.soap API functions for processing SOAP
message content and bindings.
• Java API for XML Registries (JAXR) An API that offers a standard interface for
accessing business and service registries. Originally developed for ebXML directories,
JAXR now includes support for UDDI.
– 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.
• 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 Architecture for XML Binding API (JAXB) This API provides a means of
generating Java classes from XSD schemas and further abstracting XML-level
development.
• 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.
Service providers
• As previously mentioned, 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.
116
6.Give the elements of WS-Coordination specification. What are the protocols of WS
Coordination? The overall coordination mechanism consists of the activation service, the
registration service, a coordinator, and participants that implement specific protocols. It is
likely that these underlying context management services will be automatically governed
by the orchestration engine platform for which you are creating a WS-BPEL process
definition.
• In terms of the WS-Coordination language and its two protocol documents, what may
be of interest to you is the actual CoordinationContext header that is inserted into
SOAP messages. You may encounter this header if you are monitoring messages or if
you need to perform custom development associated with the coordination context.
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.
– 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
The CoordinationType element
• This element is described shortly in the WS-BusinessActivity and WS-
AtomicTransaction coordination types section.
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.
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.
7.Explain in detail WS-choreography in detail.
This specification describes a formal method of defining a Choreography using a
Choreography Definition Language. Choreographies describe the sequence and conditions
in which messages are exchanged between independent processes, parties or organizations
in order to realize some useful purpose, for example placing an order.
• Choreographies need to be defined when two or more organizations or processes need
to cooperate as no single organization or process controls or manages the complete
process. For example a Buyer cannot directly control what a Seller does and vice
versa.
• Note that this differs from a Process Execution Language that can be used when there
is a single organization or process in control that can issue commands to other
processes to carry out all the actions or activities required.
• If Choreographies are not defined and agreed between the organizations or processes
involved, then those organizations and processes will not be able to successfully
interoperate to realize their shared objectives.
• By providing a formal representation of a Choreography in an XML format, this
specification allows the definition to be shared and therefore followed by all the
organizations or processes that use it.
• This specification is in two main parts:
117
• The first part describes how to define a Choreography in an abstract way that is
independent of:
• The format and packaging of the messages being exchanged, and
• The technology used at each end to send and receive messages
• The second part describes how to bind the messages in a Choreography to
WSDL and SOAP (Ed: required but not included in this version spec).
8. Explain in detail WS-Policy Framework.
• The WS-Policy framework is comprised of the following three specifications:

– WS-Policy
– WS-PolicyAssertions
– WS-PolicyAttachments
• These collectively provide the following elements covered in this section, which
demonstrate how policies are formulated and attached to element or document-level
subjects:
– Policy element
– TextEncoding, Language, SpecVersion, and MessagePredicate assertions
– ExactlyOne element
– All element
– Usage and Preference attributes
– PolicyReference element
– PolicyURIs attribute
PolicyAttachment element
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.
The ExactlyOne element
• This construct surrounds multiple policy assertions and indicates that there is a choice
between them, but that one must be chosen.
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.
118
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.
• If multiple PolicyReference elements are used within the same element, the policy
documents are merged at runtime.
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.
The PolicyAttachment element
• Alternative 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.
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.
9. Discuss WS-Security framework in detail. (Nov/Dec 2017)
119
• The WS-Security framework is comprised of numerous specifications, many in
different stages of acceptance and maturation. In this book we've concentrated on
some of the more established ones, namely:
– 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.
The BinarySecurityToken element
– (WS-Security)
– Tokens stored as binary data, such as certificates, can be represented in an
encoded format within the BinarySecurityToken element.
– Composing Security element
– contents (WS-Security)
– The WS-Security specification positions the Security element as a standardized
container for header blocks originating from other security extensions.
– The following example illustrates this by showing how a SAML block is
located within the Security construct.
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.
10. Discuss WS-BPEL Language Basics in detail.

A brief history of BPEL4WS and WS-BPEL
• Business Process Execution Language for Web Services (BPEL4WS) was first
conceived in July, 2002, with the release of the BPEL4WS 1.0 specification, a joint
effort by IBM, Microsoft, and BEA. This document proposed an orchestration
language inspired by previous variations, such as IBM's Web Services Flow Language
(WSFL) and Microsoft's XLANG specification.
• Joined by other contributors from SAP and Siebel Systems, version 1.1 of the
BPEL4WS specification was released less than a year later, in May of 2003. This
version received more attention and vendor support, leading to a number of
commercially available BPEL4WS-compliant orchestration engines. Just prior to this
120
release, the BPEL4WS specification was submitted to an OASIS technical committee
so that the specification could be developed into an official, open standard.
• The technical committee is in the process of finalizing the release of the next version
of BPEL4WS. It has been announced that the language itself has been renamed to the
Web Services Business Process Execution Language, or WS-BPEL (and assigned the
2.0 version number).
• Prerequisites
• Concepts relating to orchestration, coordination, atomic transactions, and
business activities are covered, and are therefore not repeated here.
• The process element
• 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 partnersthe process service being one partner and another service
being the other. Depending on the nature of the communication, the role of the
process service will vary. For instance, a process service that is invoked by an
external service may act in the role of "TimesheetSubmissionProcess."
• 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.
• 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.
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 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
121
parameter and two optional arguments that can be used to specify a part
of the variable data.
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.
11. Explain the different types of security attacks and threats and also give the web security
road map.(April/May 2017) (Apr/May 2018)
I. Types of Attacks
• Physical Access Attacks
– Wiretapping
– Server Hacking
– Vandalism
• Dialog Attacks
– Eavesdropping
– Impersonation
– Message Alteration
• Penetration Attacks
– Scanning (Probing)
– Break-in
– Denial of Service
– Malware
• Viruses
• Worms
• Social Engineering
– Opening Attachments
– Password Theft
– Information Theft
II. Types of Threats:
• Interruption
– An asset of the system is destroyed of becomes unavailable or unusable
– Attack on availability
– Destruction of hardware
– Cutting of a communication line
– Disabling the file management system
• Interception
– An unauthorized party gains access to an asset
– Attack on confidentiality
– Wiretapping to capture data in a network
– Illicit copying of files or programs
• Modification
– An unauthorized party not only gains access but tampers with an asset
– Attack on integrity
– Changing values in a data file
– Altering a program so that it performs differently
122
– Modifying the content of messages being transmitted in a network
• Fabrication
– An unauthorized party inserts counterfeit objects into the system
– Attack on authenticity
– Insertion of spurious messages in a network
– Addition of records to a file
III. WS Security Roadmap

WS-SecureConversation
•
Builds on the concept of trust based on security tokens
•
Defines how to establish a secured session between services for exchanging data using the rules
•
defined in WS-Policy, WS-Trust, and WS-Privacy
Defines how to create a context for a particular conversation with a Web Service and how to
•• create keys that can be used in that context
•
WS-Federation
Describes how to manage and broker trust relationships (trust of identities, attributes, and
authentication) in a heterogeneous federated environment (among Web Services) leading Single
•
Sign-On.
•
Comprise of the following:
WS-Federation: Active Requestor Profile - defines mechanisms for requesting, exchanging, and
issuing security tokens within the context of active requestors (an application capable of issuing WS
messages).
 • WS-Federation (Language) - defines how federation works in the WS-Security stack.

•
 WS-Federation: Passive Requestor Profile (HTTP browser) - defines a system for passive mechanisms to
work seamlessly with a single or simplified sign-on to the WS-Federation system.
123
• 
WS-Authorization
 • Describes how access policies for a Web Service are specified and managed.

•
Describes howclaims may be specified within security tokens and how these claims will be interpreted at
the endpoint.
• 
WS-Policy
 • Defines the policy rules on how services interact

• 
Includes 4 specs
 • A Policy Framework(WS-Policy) - defines a grammar for expressing WS policies

 • 
A Policy Attachment (WS-Policy-Attachment) - defines how to attach these policies to WS
 • 
A set of general policy assertions (WS-Policy-Assertions)
 • 
A set of security policy assertions (WS-Security Policy)
• 
WS-Trust

 The 
trust between a service requester and a service provider is established through the exchange of
information between the two parties in an expected and understood manner

 
WS-Security already defines the basic mechanisms to securely exchange messages using security tokens

 
Builds on top of WS-Security and defines how the security tokens are issued and exchanged


Defines a set of interfaces that a secure token service may provide for the issuance, exchange, and validation
of security tokens
 
WS-Privacy
defines how privacy of information is maintained
 
WS-Security

 Enhance SOAP messaging by providing quality of protection through message integrity and message
confidentiality.

 Authentication with Security tokens – username and passwords, Kerberos tickets, X.509 certificate

 Message integrity – XML Signature with security tokens 
 
Message confidentiality – XML Encryption with security tokens

12. Explain the overview of SOA and the role of web services with .NET Interoperability and

J2EE Interoperability. (April/May 2017)
 The .NET and J2EE frameworks are providing support for Web Services:
 Microsoft .NET
Microsoft .NET is the Microsoft XML Web Services platform. It provides built-in support for
building and consuming standards-based Web Services. It enables the creation and use of XML-
 based applications, processes, and Web sites as Web Services.
Through just a single line of code and/or setting a value of an attribute, it is possible to turn an
 application into a Web Service in the .NET environment.
 By default all inter-process communication is done using the SOAP standard.
According to the .NET framework, all components can be Web Services, and Web Services are
just a kind of component".
As shown in the diagram, Microsoft .NET provides:

● A programming model to build XML Web Services and applications.
● Web Services development tools such as Visual Studio .NET to define and develop
application functionality and architecture for XML Web Services and applications.
124
● Web Services enabled servers such as BizTalk Server 2002 and SQL Server 2000.
BizTalk Server Toolkit for Microsoft .NET enables Web Services orchestration through
its integration with Visual Studio .NET.
The SQL Server 2000 Web Services Toolkit enables the usage of Visual Studio .NET to extend
the capabilities of applications built on SQL Server 2000.
● A set of pre-built user-centric XML Web Services such as Microsoft .NET My
Services.
Java 2 Platform, Enterprise Edition (J2EE)

The new APIs released by Sun, as part of J2EE 1.3, provide a top-to-bottom, end-to-end solution
for a Web Services-based architecture. J2EE 1.3 simplifies integration with new technologies for
Web Services, such as Java Messaging Service (JMS), J2EE Connector Architecture (JCA), Java
API for XML Messaging (JAXM), Java API for XML Processing (JAXP), Java API for XML
Registries (JAXR), and Java API for XML-based RPC (JAX-RPC). J2EE server products are
already providing basic Web Services support such as accessing J2EE components using the SOAP
1.1 protocol.
J2EE-based application servers, such as iPlanet, WebSphere, and WebLogic are also supporting the
automatic generation of Web Services interfaces, including the WSDL file that describes the
service, and the facilities for marshalling and un-marshalling the SOAP request to back-end EJB
components. Recently released, Sun Microsystems' Java Web Services Developer Pack (WSDP)
and Java XML Pack contains:
● JAXP (Java API for XML Processing) - to support the creation, receipt and
manipulation of XML data, including XML Schema
● JAX-RPC (Java API for XML-based Remote Procedure Calls) - to enable the creation of
Web Services using SOAP and WSDL
● JAXM (Java API for XML Messaging) to support XML messaging via SOAP
● JAXR (Java API for XML Registries) to support access to UDDI registries Lastly, as far as
Web Services security is concerned, apart from the security package that is already a part of
the Java Developers Kit 1.3, Sun has released the JSSE (Java Secure Socket Extension) API
as part of the Java 2 SDK, Standard edition 1.4.
This API supports data encryption, authentication on the server side (and optionally on the client
side), message integrity, SSL (Secure Sockets Layer), and transport layer security across any
TCP/IP connection.
Differences Between J2EE and .NET Frameworks for Web Services Support
125
126
13. Explain the various standards in the development of web services. (April/May 2017)
(Apr/May 2018)
I.Basic Web Services Standards
• XML (eXtensible Markup Language) 1.1
• SOAP 1.2 (Simple Object Access Protocol)
• WSDL (Web Services Description Language) 1.1
• UDDI (Universal, Description, Discovery, and Integration) 3.0.2
a. XML 1.1
• Developed by W3C
• Fee-free open standard
• Its primary purpose is to facilitate the sharing of structured data across different information
systems, particularly via the Internet.
• A subset of SGML (Standard Generalized Markup Language)
b. SOAP 1.2
127
 OASIS Standard
 SOAP version 1.2 is a lightweight protocol for exchange of information in a decentralized,
distributed environment.
• No security specification
• The SOAP Header provides a flexible mechanism for extending a SOAP message.
• Although the SOAP Header is the best place to add security features to messages, the SOAP
specification itself does not specify such header elements.
c. WSDL
 It is an XML-based language for describing Web Services and how to access them.
 It specifies the location of the service and the operations the services exposes.
 A WSDL document is simply a set of definitions.
d. UDDI
• The Universal Description, Discovery, and Integration specs define a way to publish and
discover information about Web services.
• The UDDI business registration is an XML file that describes a business entity and its Web
services.
UDDI security
• Not specified in detail, only general policies
• Only authorized individuals can publish or change information in the registry
• Changes or deletions can only be made by the originator of the information
• Each instance of a registry can define its own user authentication mechanism
Layers and Web Services Standards
II. Messaging Standards

• These messaging standards are intended to give a framework for exchanging information in a
decentralized, distributed environment.
• Some standards are:
– SOAP 1.2
– WS-Addressing
128
– WS-Notification
III. Description and Discovery Standards

• The focus of these standards and specifications is the definition of a set of services
supporting the discovery of businesses, the Web services they make available and the
technical interfaces which may be used to access those services.
• Some standards are:
– UDDI 3.0.2
– WSDL 1.1
• Using these security standards, application can engage secure communication designed
to work with the general web services framework.
• Some security standards are:
– SAML 2.0 (Security Assertion Markup Language)
– SPML 2.0 (Service Provisioning Markup Language)
– XACML 2.0 (eXtensible Access Control Markup Language)
– WS-Security 1.1
V. Reliable Messaging Standards
• The objective of these standards is to allow messages to be delivered reliably between
distributed applications in the presence of system or network failure.
• Some reliable messaging standards are:
– WS-ReliableMessaging 1.1
– WS-Reliability 1.1
– WS-RM Policy Assertion 1.1
•These specifications define mechanisms for transactional interoperability between Web

services domains and provide a means to compose transactional qualities of service into
Web services applications.
• Some transaction standards are:
– WS-Coordination
– WS-Transaction
– WS-Context
•These standards specify the potential order of operations from a collection of web services,
the data shared between them, which partners are involved and other issues involving how
multiple services and organizations participate.
• Some Business Process are:
– WS-BPEL 2.0 (Business Process Execution Language)
– WS-Choreography 1.0
129

Soa

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Soa

Загружено:

Авторское право:

Доступные форматы

IT6801 Service Oriented Architecture Department of IT 2018-19

Unit-I Introduction To XML

2. What is meant by a XML namespace? (Nov/Dec 2016)

3. Distinguish between expanded name space and qualified name space.

5. Define XML attributes.

16. Write short notes on DTD.

17. What does an XML document contain?

18. List some XML rules? (Nov/Dec 2016)

19. Write an example for XML syntax.

20. What is a Well-formed XML document?

22. List the properties XML document?

23. List the properties of Validating Parser?

24. List the properties of Non-Validating Parser?

26. What is XML document prolog? (Nov/Dec 2017)

ASCII - American Standard Code for Information Interchange;UTF - Unicode Transformation

The general forms of Document Type Declarations:

c. Markup and Content

&lt; < less than

LISTING. Sample Entity References

<prescription>The Rx prescription symbol is &#8478; which is the same as &#x211E;</prescription>

3. Explain the role of XML namespaces with examples. (Nov/Dec 2017)

Simple Xml Document:

External plus Internal DTD:

XML Building Blocks:

Example : Elements with Data

Element with Children (sequential)

Inner elements must also be declared

| Choice operators a|b|c

CDATA The value is character data

(en1|en2|..) The value must be one from an enumerated list

ID The value is a unique id

IDREF The value is the id of another element

IDREFS The value is a list of other ids

NMTOKEN The value is a valid XML name

NMTOKENS The value is a list of valid XML names

ENTITY The value is an entity

ENTITIES The value is a list of entities

NOTATION The value is a name of a notation

xml: The value is a predefined xml value

value The default value of the attribute

#REQUIRED The attribute is required

#IMPLIED The attribute is not required

#FIXED value The attribute value is fixed

12. Comments in XML

7. Explain all XML Building Blocks.

Element with data

Element with Children (sequential)

Inner elements must also be declared

The attribute-type can be one of the following:

CDATA The value is character data

(en1|en2|..) The value must be one from an enumerated list

ID The value is a unique id

IDREF The value is the id of another element

IDREFS The value is a list of other ids

NMTOKEN The value is a valid XML name

NMTOKENS The value is a list of valid XML names

ENTITY The value is an entity

ENTITIES The value is a list of entities

NOTATION The value is a name of a notation

xml: The value is a predefined xml value

The default-value can be one of the following:

value The default value of the attribute

#REQUIRED The attribute is required

< < less than

<prescription>The Rx prescription symbol is ℞ which is the same as ℞</prescription>

Charlie is context node, e.g.: count(child::) returns 2. Same as count().