QN:-

Compare DOM and SAX?

What Is DOM
The Document Object Model (DOM) provides a way of representing an XML document
in memory so that it can be manipulated by your software. DOM is a standard application
programming interface (API) that makes it easy for programmers to access elements
and delete, add, or edit content and attributes. DOM was proposed by the World Wide
Web Consortium (W3C) in August of 1997 in the User Interface Domain. The Activity
was eventually moved to the Architecture Domain in November of 2000. Here’s a good
place to start looking for DOM-related information:

http://www.w3.org/DOM

DOM by itself is just a specification for a set of interfaces defined by W3C. In fact, the
DOM interfaces are defined independent of any particular programming language. You
can write DOM code in just about any programming language, such as Java,
ECMAScript (a standardized version of JavaScript/JScript), or C++. There are DOM
APIs for each of these languages. W3C uses the Object Management Group’s (OMG)
Interface Definition Language (IDL) to define DOM in a language-neutral way.
Language-specific bindings, or DOM interfaces, exist for these languages. The DOM
specification itself includes bindings for Java and ECMAScript, but third parties have
defined bindings for many other languages.

What DOM Is Not

From the preceding discussion, it might be clear to you what the DOM is, but it is also
important to highlight what the DOM is not. Here is a brief summary:
• DOM is not a mechanism for persisting, or storing, objects as XML documents.
Think of it the other way: DOM is an object model for representing XML documents
in your code.

DOM is not a set of data structures; rather it is an object model describing XML
documents.
• DOM does not specify what information in a document is relevant or how information
should be structured.
• DOM has nothing to do with COM, CORBA, or other technologies that include the
words object model
Why Do I Need DOM?
The main reason for using DOM is to create or modify an XML document programmatically.
You can use DOM just to read an XML document, but as you will see in the next
chapter, SAX is often a better candidate for the read-only case

Disadvantages of Using DOM

Although DOM is a W3C specification with support for a variety of programming languages,
it’s not necessarily the best solution for all problems. One of the big issues is
that DOM can be memory intensive. As mentioned earlier, when an XML document is
loaded, the entire document is read in at once. A large document will require a large
amount of memory to represent it. Other parsing methods, such as SAX, don’t read
in the entire document, so they are better in terms of memory efficiency for some
applications

DOM is not practical for small devices such as PDAs and cellular
phones. With the rapid proliferation of these devices and demand for greater functionality,
XML will very likely play a role in this market.

DOM Levels
The DOM working group works on phases (or levels) of the specification. At the time of
this writing, three levels are in the works. The DOM Level 1 and Level 2 specifications
are W3C recommendations.

Level 1 allows traversal of an XML document

as well as the manipulation of the content in that document. Level 2 extends Level
1 with additional features such as namespace support, events, ranges, and so on. Level 3
is currently a working draft. This means that it is under active development and subject
to change.

DOM Interfaces
Interface Description

Node The primary interface for the DOM. It can be an

element,
 attribute, text, and so on, and contains methods
for traversing
a DOM tree.

NodeList An ordered collection of Nodes.

NamedNodeMap An unordered collection of Nodes that can be

accessed by
name and used with attributes.

Document An Node representing an entire

document. It contains the
root Node.

DocumentFragment A Node representing a piece of a

document. It’s useful for
extracting or inserting a fragment into
a document.

Element A Node representing an XML

element.
Attr A Node representing an XML
attribute.

CharacterData A Node representing character

data.

Text A CharacterData node

representing text.

Comment A CharacterData node

representing a comment.

DOMException An exception raised upon

failure of an operation.
DOMImplementation Methods for creating
documents and determining whether
an implementation has certain
. features.

What Is SAX?
SAX is an API that can be used to parse XML documents. A parser is a program that
reads data a character at a time and returns manageable pieces of data. For example, aparser for
the English language might break up a document into paragraphs, words, and
punctuation. In the case of XML, the important pieces of data include elements, attributes,
text, and so on. This is what SAX does.
SAX provides a framework for defining event listeners, or handlers. These handlers are
written by developers interested in parsing documents with a known structure. The handlers
are registered with the SAX framework in order to receive events. Events can
include start of document, start of element, end of element, and so on. The handlers contain
a number of methods that will be called in response to these events. Once the handlers
are defined and registered, an input source can be specified and parsing can begin

What SAX Is Not

SAX by itself is just an API, and a number of implementations are available from many
of the familiar sources. The most commonly used parsers are Xerces from the Apache
XML project and Java API for XML Processing (JAXP) from Sun Microsystems.

SAX was originally developed in Java, but similar implementations are available in other
languages as well. There are implementations for Perl, Python, and C++.

Why Do I Need SAX?

If you have an XML document, at some point you will need to read it programmatically

If you are writing a tool or a standalone program to process XML, SAX is a good way to
do it.

Some SAX parsers can validate a document against a Document Type Definition (DTD).
Validating parsers can also tell you specifically where validation has failed

SAX vs. DOM

DOM is an in-memory tree structure of an XML document or document
fragment. DOM is a natural object model of an XML document, but it’s not always practical.
Large documents can take up a lot of memory. This is overkill if all you want to do
is find a small piece of data in a very large document.

SAX is, in many ways, much simpler than DOM. There is no need to model every possible
type of object that can be found in an XML document. This makes the API easy to
understand and easier to use. DOM contains many interfaces, each containing many
methods. SAX is comprised of a handful of classes and interfaces. SAX is a much lowerlevel
API when compared with DOM. For these reasons, SAX parsers tend to be smaller
than DOM implementations. In fact, many DOM implementations use SAX parsers
under the hood to read in XML documents.

SAX is an event-based API. Instead of loading an entire document into memory all at
once, SAX parsers read documents and notify a client program when elements, text,
comments, and other data of interest are found. SAX parsers send you events continuously,
telling you what was found next.

The DOM parses XML in space, whereas SAX parses XML in time. In essence, the
DOM parser hands you an entire document and allows you to traverse it any way you
like. This can take a lot of memory, so SAX can be significantly more efficient for large
documents. In fact, you can process documents larger than available system memory, but
this is not possible with DOM. SAX can also be faster, because you don’t have to wait
for the entire document to be loaded. This is especially valuable when reading data over
a network.

In some cases, you might want to build your own object model of an XML document
because DOM might not describe your specific document efficiently or in the way you
would like. You could solve the problem by loading a document using DOM and translating
the DOM object model into your own object model. However, this can be very inefficient,
so SAX is often a better solution.

Disadvantages
SAX is not a perfect solution for all problems. For instance, it can be a bit harder to visualize
compared to DOM because it is an event-driven model. SAX parsing is “single
pass,” so you can’t back up to an earlier part of the document any more than you can
back up from a serial data stream. Moreover, you have no random access at all. Handling
parent/child relationships can be more challenging as well.

Another disadvantage is that the current SAX implementations are read-only parsers.
They do not provide the ability to manipulate a document or its structure (this feature
may be added in the future). DOM is the way to go if you want to manipulate a document
in memory.
There is no formal specification for SAX. The interfaces and behavior are defined through
existing code bases. This means there is no way to validate a SAX parser or to determine
whether it works correctly. In the words of Dave Megginson, “It’s more like English
Common Law rather than the heavily codified Civil Code of ISO or W3C specifications.”
Even considering these limitations, SAX does its job well. It’s lightweight, simple, and
easy to use. If all you want to do is read XML, SAX will probably do what you need.

QN:-2
Devlop a code for creating a “dom ”
document object for searching an “xml”
element in xml document?
In this example, we will create an XML document in memory, from scratch, and
thenwrite it out to disk.

There are two classes, The first one, IteratorApp.java, contains the
application code. The second one, NameNodeFilter.java, selects nodes with a
given name.

IteratorApp.java
package com.madhu.xml;
import java.io.*;
import org.w3c.dom.*;
import org.w3c.dom.traversal.*;
import javax.xml.parsers.*;
public class IteratorApp {
protected DocumentBuilder docBuilder;
protected Document document;
protected Element root;
public IteratorApp() throws Exception {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
docBuilder = dbf.newDocumentBuilder();
DOMImplementation domImp = docBuilder.getDOMImplementation();
if (domImp.hasFeature(“Traversal”, “2.0”)) {
System.out.println(“Parser supports Traversal”);
}
}
public void parse(String fileName) throws Exception {
document = docBuilder.parse(new FileInputStream(fileName));
root = document.getDocumentElement();
System.out.println(“Root element is “ + root.getNodeName());
}
public void iterate() {
NodeIterator iter =
((DocumentTraversal)document).createNodeIterator(
root, NodeFilter.SHOW_ELEMENT,
new NameNodeFilter(“book”), true);
Node n = iter.nextNode();
while (n != null) {
System.out.println(n.getFirstChild().getNodeValue());
n = iter.nextNode();
}
}
public static void main(String args[]) throws Exception {
IteratorApp ia = new IteratorApp();
ia.parse(args[0]);
ia.iterate();
}
}

NameNodeFilter.java
package com.madhu.xml;
import org.w3c.dom.*;
import org.w3c.dom.traversal.*;
public class NameNodeFilter implements NodeFilter {
protected String name;
public NameNodeFilter(String inName) {
name = inName;
}
public short acceptNode(Node n) {
if (n.getNodeName().equals(name)) {
return FILTER_ACCEPT;

} else {
return FILTER_REJECT;
}
}
}

library.xml—Input XML Document

<?xml version=”1.0” encoding=”UTF-8”?>
<library>
<fiction>
<book>Moby Dick</book>
<book>The Last Trail</book>
</fiction>
<biography>
<book>The Last Lion, Winston Spencer Churchill</book>
</biography>
</library>

Here’s the output from:- IteratorApp:

Parser supports MutationEvents
Root element is library
Moby Dick
The Last Trail
The Last Lion, Winston Spencer Churchill
QN:-
What is xml binding, xml data binding, explain it with
suitable example?

XML DATA BINDING:-

XML data binding refers to a means of representing information in an XML document
as an object in computer memory. This allows applications to access the data in
the XML from the object rather than using the DOM or SAX to retrieve the data from
a direct representation of the XML itself.

An XML data binder accomplishes this by automatically creating a mapping between

elements of the XML schema of the document we wish to bind and members of
a class to be represented in memory.

When this process is applied to convert a XML document to an object, it is

called unmarshalling. The reverse process, to serialize an object as XML, is called
marshalling.

Since XML is inherently sequential and objects are (usually) not, XML data binding
mappings often have difficulty preserving all the information in an XML document.
Specifically, information likecomments, XML entity references, and sibling order may
fail to be preserved in the object representation created by the binding application. This
is not always the case; sufficiently complex data binders are capable of preserving
100% of the information in an XML document.

Similarly, since objects in computer memory are not inherently sequential, and may
include links to other objects (including self-referential links), XML data binding
mappings often have difficulty preserving all the information about an object when it is
marshalled to XML.
An alternative approach to automatic data binding relies instead on hand-
crafted XPath expressions that extract the data from XML. This approach has a
number of benefits. First, the data binding code only needs proximate knowledge (e.g.,
topology, tag names, etc.) of the XML tree structure, which developers can determine
by looking at the XML data; XML schemas are no longer mandatory. Furthermore,
XPath allows the application to bind the relevant data items and filter out everything
else, avoiding the unnecessary processing that would be required to completely
unmarshall the entire XML document. The drawback of this approach is the lack of
automation in implementing the object model and XPath expressions. Instead the
application developers have to create these artifacts manually.

Xml binding:-Java Architecture for XML Binding (JAXB)

allows Java developers to map Java classes to XML representations. JAXB
provides two main features: the ability to marshal Java objects into XML and the
inverse, i.e. to unmarshal XML back into Java objects. In other words, JAXB allows
storing and retrieving data in memory in any XML format, without the need to implement
a specific set of XML loading and saving routines for the program's class structure. It is
similar to xsd.exe and xmlserializers in .Net Framework.
JAXB is particularly useful when the specification is complex and changing. In such a
case, regularly changing the XML Schema definitions to keep them synchronised
with the Java definitions can be time consuming and error prone.
JAXB is one of the APIs in the
Java EE platform, and is part of the Java
Web Services Development Pack (JWSDP). It is also one of the foundations
for WSIT.

In the JAXB framework, we can parse XML documents into a suitable Java object.
Thistechnique is referred to as unmarshaling. The JAXB framework also provides
the capabilityto generate XML documents from Java objects, which is referred to
as marshaling.
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. Also, 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. For very complex XML documents, the development process is very cumbersome.
Using JAXB, an application can parse an XML document by simply unmarshaling
the data from an input stream.
JAXB is similar to DOM in that we can create XML documents programmatically
andperform validation

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 willdevelop 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 schemacontains instructions on how to bind the XML schema to
a Java class. We’ll take theJAXB 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.

EX:-
QN:-4,
“Compare and Contrast well
formed and valid document”?
Well-Formed Documents:-
An XML document is well formed if it follows all the preceding syntax rules of
XML.On the other hand, if it includes inappropriate markup or characters that
cannot beprocessed by XML parsers, the document cannot be considered well
formed. It goeswithout saying that an XML document can’t be partially well
formed. And, by definition if a document is not well formed, it is not XML. This
means that there is no such thingas an XML document that is not well formed, and
XML processors are not required toprocess these documents

Valid Documents:-
Although the property of “well-formedness” is a matter of making sure the XML
documentcomplies to syntactical rules, the property of validity is a different
ballgame. Awell-formed XML document is considered valid only if it contains a
proper DocumentType Declaration and if the document obeys the constraints of
that declaration. In most cases, the constraints of the declaration will be expressed
as a DTD or an XML Schema.Well-formed XML documents are designed for use
without any constraints, whereas valid XML documents explicitly require these
constraint mechanisms. In addition to constraining the possible elements and the
ordering of those elements in a document, valid XML documents can take
advantage of certain advanced features of XML that are not available to merely
well-formed documents due to their lack of a DTD or XML Schema. Some of
these advanced features include linking mechanisms, value and range bounding,
and data typing.

Although the creation of well-formed XML is a simple process, the use of valid
XML documents can greatly improve the quality of document processes. Valid
XML documents allow users to take advantage of content management, business-
to-business transactions, enterprise integration, and other processes that require the
exchange of constrained XML documents. After all, any document can be well
formed, but only specific documents are valid when applied against a constraining
DTD or schema.

DIFFERENCE:-
1. Well-formed XML means that the XML is correct (it has only one root
node, and all elements match an end element tag) 

Valid XML means that the XML can be validated to an XML Schema or DTD,
and that all the tags in the XML are also in the Schema or DTD, and in the
right place.

2. Valid XML is XML that succeeds validation against a DTD.

Well formed XML is XML that has all tags closed in the proper order and, if
it has a declaration, it has it first thing in the file with the proper attributes.

In other words, validity refers to semantics, well-formedness refers to

syntax.

So you can have invalid well formed XML.

3:-  well-formed XML conforms to the XML spec, and valid XML conforms
to a given schema.
4:- Another way to put it is that well-formed XML is syntactically correct (it can be
parsed), while valid XML issemantically correct (it can be matched to a known
vocabulary and grammar).

5:- An XML document cannot be valid until it is well-formed. All XML documents are
held to the same standard for well-formedness (an RFC put out by the W3). One XML
document can be valid against some schemas, and invalid against others. There are a
number of schema languages, many of which are themselves XML-based.

6:- Well-Formed XML is XML that meets the syntactic requirements of the language.
Not missing any closing tags, having all your singleton tags use <whatever /> instead
of just <whatever>, and having your closing tags in the right order.

7:- Valid XML is XML that uses a DTD and complies with all its requirements. So if you
use an attribute improperly, you violate the DTD and aren't valid.

8:- All valid XML is well-formed, but not all well-formed XML is valid.

9;- XML is well-formed if meets the requirements for all XML documents set
out by the standards - so things like having a single root node, having
nodes correctly nested, all nodes having a closing tag (or using the empty
node shorthand of a slash before the closing angle bracket), attributes
being quoted etc. Being well-formed just means it adheres to the rules of
XML and can therefore be parsed properly.

10:- XML is valid if it will validate against a DTD or schema. This

obviously differs from case to case - XML that is valid against one schema
won't be valid against another schema, even though it is still well-formed.
11:- If XML isn't well-formed it can't be properly parsed - parsers will
simply throw an exception or report an error. This is generic and it doesn't
matter what your XML contains. Only once it is parsed can it be checked
for validity. This domain or context dependent and requires a DTD or
schema to validate against. For simple XML documents, you may not have
a DTD or schema, in which case you can't know if the XML is valid - the
concept or validity simply doesn't apply in this case. Of course, this doesn't
mean you can't use it, it just means you can't tell whether or not it's valid

12:- In addition to the aforementioned DTD's, there are 2 other ways of

describing and validating XML documents are XMLSchema and RelaxNG,
both of which may be easier to use and support more features than DTD

13:- If XML is confirming to DTD rules then it's a valid XML. If a XML document is
conforming to XML rules (all tags started are closed,there is a root element etc)then it's
a well formed XM.

14:- An XML document cannot be valid until it is well-formed. All XML documents are
held to the same standard for well-formedness (an RFC put out by the W3). One XML
document can be valid against some schemas, and invalid against others. There are a
number of schema languages, many of which are themselves XML-based

15:- Another way to put it is that well-formed XML is syntactically correct (it can be
parsed), while valid XML issemantically correct (it can be matched to a known
vocabulary and grammar)

16:- As others have said, well-formed XML conforms to the XML spec, and valid XML
conforms to a given schema.
17:- Valid XML is XML that succeeds validation against a DTD.
Well formed XML is XML that has all tags closed in the proper order and, if
it has a declaration, it has it first thing in the file with the proper attributes.

In other words, validity refers to semantics, well-formedness refers to

syntax.

So you can have invalid well formed XML.

QN:-
“Compare and Contrast DTD with
Schema (with suitable example)”?
DTD:-
DTD stands for Document Type Definition. A Document Type Definition allows
the XML author to define a set of rules for an XML document to make it valid. An
XML document is considered “well formed” if that document is syntactically
correct according to the syntax rules of XML 1.0. However, that does not mean the
document is necessarily valid. In order to be considered valid, an XML document
must be validated, or verified, against a DTD. The DTD will define the elements
required by an XML document, the elements that are optional, the number of times
an element should (could) occur, and the order in which elements should be nested.
DTD markup also defines the type of data that will occur in an XML element and
the attributes that may be associated with those elements. A document, even if well
formed, is not considered valid if it does not follow the rules defined in the DTD.

When an XML document is validated against a DTD by a validating XML parser,

the XML document will be checked to ensure that all required elements are present
and that no undeclared elements have been added. The hierarchical structure of
elements defined in the DTD must be maintained. The values of all attributes will
be checked to ensure that they fall within defined guidelines. No undeclared
attributes will be allowed and no required attributes may be omitted. In short, every
last detail of the XML document from top to bottom will be defined and validated
by the DTD.
Although validation is optional, if an XML author is publishing an XML
document for which maintaining the structure is vital, the author can reference a
DTD from the XML document and use a validating XML parser during processing.
Requiring that an XML document be validated against a DTD ensures the
integrity of the data structure. XML documents may be parsed and validated before
they are ever loaded by an application. That way, XML data that is not valid can be
flagged as “invalid” before it ever gets processed by the application (thus saving a
lot of the headaches that corrupt or incomplete data can cause).

An extra advantage of using DTDs in this situation is that a single DTD could be
referenced by all the organization’s applications. The defined structure of the data
would be in a centralized resource, which means that any changes to the data
structure definition would only need to be implemented in one place. All the
applications that referenced the DTD would automatically use the new, updated
structure.

A DTD can be internal, residing within the body of a single XML document. It can
also be external, referenced by the XML document. A single XML document could
even have both a portion (or subset) of its DTD that is internal and a portion that is
external. As mentioned in the previous paragraph, a single external DTD can be
referenced by many XML documents. Because an external DTD may be
referenced by many documents, it is a good repository for global types of
definitions (definitions that apply to all documents). An internal DTD is good to
use for rules that only apply to that specific document. If a document has both
internal and external DTD subsets, the internal rules override the external rules in
cases where the same item is defined in both subsets.

EX:-
<?xml version=”1.0” encoding=”UTF-8”?>
<!ELEMENT PurchaseOrder (ShippingInformation, BillingInformation, Order)>
<!ATTLIST PurchaseOrder
Tax CDATA #IMPLIED
Total CDATA #IMPLIED
>
<!ELEMENT ShippingInformation (Name, Address, (((BillingDate,
➥PaymentMethod)) | ((DeliveryDate, Method))))>
<!ELEMENT BillingInformation (Name, Address, (((BillingDate,
➥PaymentMethod)) | ((DeliveryDate, Method))))>
<!ELEMENT Order (Product+)>
<!ATTLIST Order
SubTotal CDATA #IMPLIED
ItemsSold CDATA #IMPLIED
>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT Address (Street, City, State, Zip)>
<!ELEMENT BillingDate (#PCDATA)>
<!ELEMENT PaymentMethod (#PCDATA)>
<!ELEMENT DeliveryDate (#PCDATA)>
<!ELEMENT Method (#PCDATA)>
<!ELEMENT Product EMPTY>
<!ATTLIST Product
Name CDATA #IMPLIED
Id CDATA #IMPLIED
Price CDATA #IMPLIED
Quantity CDATA #IMPLIED
>
<!ELEMENT Street (#PCDATA)>
<!ELEMENT City (#PCDATA)>
<!ELEMENT State (#PCDATA)>
<!ELEMENT Zip (#PCDATA)>

SCHEMA:- An XML schema is a description of a type

of XML document, typically expressed in terms of constraints on the
structure and content of documents of that type, above and beyond the
basic syntactical constraints imposed by XML itself. These constraints are
generally expressed using some combination of grammatical rules
governing the order of elements, Boolean predicates that the content
must satisfy, data types governing the content of elements and attributes,
and more specialized rules such as uniqueness and referential integrity
constraints.
There are languages developed specifically to express XML schemas.
The Document Type Definition (DTD) language, which is native to
the XML specification, is a schema language that is of relatively limited
capability, but that also has other uses in XML aside from the expression of
schemas. Two more expressive XML schema languages in widespread use
are XML Schema (with a capital S) andRELAX NG.

Validation
The process of checking to see if an XML document conforms to a schema
is called validation, which is separate from XML's core concept of
syntactic well-formedness. All XML documents must be well-formed, but it
is not required that a document be valid unless the XML parser is
"validating," in which case the document is also checked for conformance
with its associated schema. DTD-validating parsers are most common, but
some support W3C XML Schema or RELAX NG as well.
Documents are only considered valid if they satisfy the requirements of the
schema with which they have been associated. These requirements
typically include such constraints as:

 Elements and attributes that must/may be included, and their

permitted structure
 The structure as specified by a regular expression syntax
 How character data is to be interpreted, e.g. as a number, a date,
a URL, a Boolean, etc.
Validation of an instance document against a schema can be regarded as a
conceptually separate operation from XML parsing. In practice, however,
many schema validators are integrated with an XML parser.
EX:- PurchaseOrder.xsd Contains the Schema Definition for
PurchaseOrder.xml

<xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<xsd:annotation>
<xsd:documentation>
Purchase Order schema for an online grocery store.
</xsd:documentation>
</xsd:annotation>
<xsd:element name=”PurchaseOrder” type=”PurchaseOrderType”/>
<xsd:complexType name=”PurchaseOrderType”>
<xsd:all>
<xsd:element name=”ShippingInformation” type=”InfoType”
➥minOccurs=”1” maxOccurs=”1”/>
<xsd:element name=”BillingInformation” type=”InfoType”
➥minOccurs=”1” maxOccurs=”1”/>
<xsd:element name=”Order” type=”OrderType”
➥minOccurs=”1” maxOccurs=”1”/>
</xsd:all>
<xsd:attribute name=”Tax”>
<xsd:simpleType>
<xsd:restriction base=”xsd:decimal”>
<xsd:fractionDigits value=”2”/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name=”Total”>
<xsd:simpleType>
<xsd:restriction base=”xsd:decimal”>
<xsd:fractionDigits value=”2”/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
<xsd:group name=”ShippingInfoGroup”>
<xsd:all>
<xsd:element name=”DeliveryDate” type=”DateType”/>
<xsd:element name=”Method” type=”DeliveryMethodType”/>
</xsd:all>
</xsd:group>
<xsd:group name=”BillingInfoGroup”>
<xsd:all>
<xsd:element name=”BillingDate” type=”DateType”/>
<xsd:element name=”PaymentMethod” type=”PaymentMethodType”/>
</xsd:all>
</xsd:group>
<xsd:complexType name=”InfoType”>
<xsd:sequence>
<xsd:element name=”Name” minOccurs=”1” maxOccurs=”1”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”/>
</xsd:simpleType>
</xsd:element>
<xsd:element name=”Address” type=”AddressType” minOccurs=”1”
➥maxOccurs=”1”/>
<xsd:choice minOccurs=”1” maxOccurs=”1”>
<xsd:group ref=”BillingInfoGroup”/>
<xsd:group ref=”ShippingInfoGroup”/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name=”DateType”>
<xsd:restriction base=”xsd:date”/>
</xsd:simpleType>
<xsd:simpleType name=”DeliveryMethodType”>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”USPS”/>
<xsd:enumeration value=”UPS”/>
<xsd:enumeration value=”FedEx”/>
<xsd:enumeration value=”DHL”/>
<xsd:enumeration value=”Other”/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name=”PaymentMethodType”>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”Check”/>
<xsd:enumeration value=”Cash”/>
<xsd:enumeration value=”Credit Card”/>
<xsd:enumeration value=”Debit Card”/>
<xsd:enumeration value=”Other”/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name=”AddressType”>
<xsd:all>
<xsd:element name=”Street” minOccurs=”1”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”/>
</xsd:simpleType>
</xsd:element>
<xsd:element name=”City” minOccurs=”1” maxOccurs=”1”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”/>
</xsd:simpleType>
</xsd:element>
<xsd:element name=”State” type=”StateType” minOccurs=”1”
➥maxOccurs=”1”/>
<xsd:element name=”Zip” type=”ZipType” minOccurs=”1”
➥maxOccurs=”1”/>
</xsd:all>
</xsd:complexType>
<xsd:simpleType name=”ZipType”>
<xsd:restriction base=”xsd:string”>
<xsd:minLength value=”5”/>
<xsd:maxLength value=”10”/>
<xsd:pattern value=”[0-9]{5}(-[0-9]{4})?”/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name=”StateType”>
<xsd:restriction base=”xsd:string”>
<xsd:length value=”2”/>
<xsd:enumeration value=”AR”/>
<xsd:enumeration value=”LA”/>
<xsd:enumeration value=”MS”/>
<xsd:enumeration value=”OK”/>
<xsd:enumeration value=”TX”/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name=”OrderType”>
<xsd:sequence>
<xsd:element name=”Product” type=”ProductType”
➥minOccurs=”1” maxOccurs=”unbounded”/>
</xsd:sequence>
<xsd:attribute name=”SubTotal”>
<xsd:simpleType>
<xsd:restriction base=”xsd:decimal”>
<xsd:fractionDigits value=”2”/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name=”ItemsSold” type=”xsd:positiveInteger”/>
</xsd:complexType>
<xsd:complexType name=”ProductType”>
<xsd:attribute name=”Name” type=”xsd:string”/>
<xsd:attribute name=”Id” type=”xsd:positiveInteger”/>
<xsd:attribute name=”Price”>
<xsd:simpleType>
<xsd:restriction base=”xsd:decimal”>
<xsd:fractionDigits value=”2”/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name=”Quantity” type=”xsd:positiveInteger”/>
</xsd:complexType>
</xsd:schema>

COMPARISON:-

XML Schema vs. DTD

DTD, or Document Type Definition, and XML Schema, which is also known as

XSD, are two ways of describing the structure and content of an XML document.
DTD is the older of the two, and as such, it has limitations that XML Schema has
tried to improve. The first difference between DTD and XML Schema, is
namespace awareness; XML Schema is, while DTD is not. Namespace
awareness removes the ambiguity that can result in having certain elements and
attributes from multiple XML vocabularies, by giving them namespaces that put
the element or attribute into context.

Part of the reason why XML Schema is namespace aware while DTD
is not, is the fact that XML Schema is written in XML, and DTD is not. Therefore,
XML Schemas can be programmatically processed just like any XML document.
XML Schema also eliminates the need to learn another language, as it is written
in XML, unlike DTD.

Another key advantage of XML Schema, is its ability to

implement strong typing. An XML Schema can define the data type of certain
elements, and even constrain it to within specific lengths or values. This ability
ensures that the data stored in the XML document is accurate. DTD lacks strong
typing capabilities, and has no way of validating the content to data types. XML
Schema has a wealth of derived and built-in data types to validate content. This
provides the advantage stated above. It also has uniform data types, but as all
processors and validators need to support these data types, it often causes older
XML parsers to fail.

A characteristic of DTD that people often consider both

as an advantage and disadvantage, is the ability to define DTDs inline, which
XML Schema lacks. This is good when working with small files, as it allows you
to contain both the content and the schema within the same document, but when
it comes to larger documents, this can be a disadvantage, as you pull content
every time you retrieve the schema. This can lead to serious overhead that can
degrade performance.

1:- DTD can have only two types of data, the CDATA and the PCDATA. But
in a schema you can use all the primitive data type that you use in the
programming language and you have the flexibility of defining your own
custom data types.
The developer building a schema can create custom data types based
on the core data types and by using different operators and modifiers.

2;- Object orientation support is there in a schema and hence encapsulation

and inheritance are there in using a schema. If you use schema then support
for web services, XSLT, and other XML based technologies are there for your
XML applications

3:- Data types like integer, string, floating point numbers and other data
like country codes and language codes can be used in a schema to give
flexibility to the validations
4:- . XML Schema is namespace aware, while DTD is not.
2. XML Schemas are written in XML, while DTDs are not.
3. XML Schema is strongly typed, while DTD is not.
4. XML Schema has a wealth of derived and built-in data types
that are not available in DTD.
5. XML Schema does not allow inline definitions, while DTD does.

5:- A DTD is:

The XML Document Type Declaration contains or points to markup
declarations that provide a grammar for a class of documents. This grammar
is known as a document type definition or DTD.

The DTD can point to an external subset containing markup declarations, or

can contain the markup declarations directly in an internal subset, or can even
do both.

A Schema is:

XML Schemas express shared vocabularies and allow machines to carry out
rules made by people. They provide a means for defining the structure,
content and semantics of XML documents.

In summary, schemas are a richer and more powerful of describing

information than what is possible with DTDs.

6:- The critical difference between DTDs and XML Schema is that XML
Schema utilize an XML-based syntax, whereas DTDs have a unique syntax
held over from SGML DTDs. Although DTDs are often criticized because of
this need to learn a new syntax, the syntax itself is quite terse. The
opposite is true for XML Schema, which are verbose, but also make use of
tags and XML so that authors of XML should find the syntax of XML
Schema less intimidating

7:- The goal of DTDs was to retain a level of compatibility with SGML for applications
that might want to convert SGML DTDs into XML DTDs. However, in keeping with one
of the goals of XML, "terseness in XML markup is of minimal importance," there is no
real concern with keeping the syntax brief.

[...]

8;- Typing
The most significant difference between DTDs and XML Schema is the
capability to create and use datatypes in Schema in conjunction with
element and attribute declarations. In fact, it's such an important difference
that one half of the XML Schema Recommendation is devoted to
datatyping and XML Schema. We cover datatypes in detail in Part III of this
book, "XML Schema Datatypes."

[...]

9:- Occurrence Constraints

Another area where DTDs and Schema differ significantly is with occurrence
constraints. If you recall from our previous examples in Chapter 2, "Schema Structure"
(or your own work with DTDs), there are three symbols that you can use to limit the
number of occurrences of an element: *, + and ?.

[...]
10;- Enumerations
So, let's say we had a element, and we wanted to be able to define a size attribute for
the shirt, which allowed users to choose a size: small, medium, or large. Our DTD would
look like this:

<!ELEMENT item (shirt)>

<!ELEMENT shirt (#PCDATA)>
<!ATTLIST shirt
    size_value (small | medium | large)>

[...]

But what if we wanted size to be an element? We can't do that with a DTD. DTDs do

not provide for enumerations in an element's text content. However, because of
datatypes with Schema, when we declared the enumeration in the preceding example,
we actually created a simpleType calledsize_values which we can now use with an
element:
<xs:element name="size" type="size_value">

11:- DTD predates XML and is therefore not valid XML itself. That's probably the
biggest reason for XSD's invention.

12:- One difference is also that in a DTD, the content model of an element is
completely determined by its name, independently of where it appears in the document.
So, say you want to have a name child element of your person element that itself has
child elements first and last. Then if you wanted to have a name child element for
a city element in the same document, that would also need to have child
elements first and last. In contrast, XML Schema allows you to declare child
element types locally, so in this case you could declare the name child elements for
both person and cityseparately, giving them their proper content models in those
contexts

13;- The other major difference is support for namespaces. Since DTDs are part of the
original XML specification (and inherited from SGML), they are not namespace-aware at
all because XML namespaces were specified later. You can use DTDs in combination
with namespaces, but it requires some contortions, like being forced to define the
prefixes in the DTD and using only those prefixes, instead of being able to use arbitrary
prefixes
QN:-
What is “rdf” Explain the functionality of
rdf with suitable example?

What is RDF?
 RDF stands for Resource Description Framework
 RDF is a framework for describing resources on the web
 RDF is designed to be read and understood by computers
 RDF is not designed for being displayed to people
 RDF is written in XML
 RDF is a part of the W3C's Semantic Web Activity
 RDF is a W3C Recommendation

RDF is Designed to be Read by Computers

RDF was designed to provide a common way to describe information so it
can be read and understood by computer applications.

RDF descriptions are not designed to be displayed on the web

RDF and "The Semantic Web"

The RDF language is a part of the W3C's Semantic Web Activity.
W3C's "Semantic Web Vision" is a future where:
  Web information has exact meaning
 Web information can be understood and processed by
computers
 Computers can integrate information from the web

RDF EXAMPLE
<?xml version="1.0"?>

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cd="http://www.recshop.fake/cd#">

<rdf:Description
rdf:about="http://www.recshop.fake/cd/Empire
Burlesque">
  <cd:artist>Bob Dylan</cd:artist>
  <cd:country>USA</cd:country>
  <cd:company>Columbia</cd:company>
  <cd:price>10.90</cd:price>
  <cd:year>1985</cd:year>
</rdf:Description>

<rdf:Description
rdf:about="http://www.recshop.fake/cd/Hide your heart">
  <cd:artist>Bonnie Tyler</cd:artist>
  <cd:country>UK</cd:country>
  <cd:company>CBS Records</cd:company>
  <cd:price>9.90</cd:price>
  <cd:year>1988</cd:year>
</rdf:Description>
.
.
.
</rdf:RDF>
The first line of the RDF document is the XML declaration. The XML
declaration is followed by the root element of RDF documents: <rdf:RDF>.

The xmlns:rdf namespace, specifies that elements with the rdf prefix are

from the namespace "http://www.w3.org/1999/02/22-rdf-syntax-ns#".

The xmlns:cd namespace, specifies that elements with the cd prefix are

from the namespace "http://www.recshop.fake/cd#".

The <rdf:Description> element contains the description of the resource

identified by the rdf:aboutattribute.

The elements: <cd:artist>, <cd:country>, <cd:company>, etc. are

properties of the resource.

Rdf def’n:- The Resource Description

“

Framework is a W3C-recommended XML application for encoding, exchanging,

and reusing structured metadata. RDF vocabularies can describe rating systems,
site maps, privacy preferences, collaborative services, licensing restrictions, and
more.”

“The Resource Description Framework (RDF,

http://www.w3.org/RDF/ ) can be understood as an XML encoding for a
particularly simple data model. An RDF document describes resources
using triples. Each triple says that a resource has a property with a value.
Resources are identified by URIs. Properties can be identified by URIs
or by element-qualified names. The value can be a string of plain text, a
chunk of XML, or another resource identified by a URI”.

The root element of an RDF document is an RDF element. Each resource

the RDF element describes is represented as a Description element whose
about attribute contains a URI pointing to the resource described. Each
child element of the Description element represents a property of the
resource. The contents of that child element are the value of that
property. All RDF elements like RDF and Description are placed in the
http://www.w3.org/1999/02/22-rdf-syntax-ns# namespace. Property
values generally come from other namespaces.
As the name implies, RDF describes resources. A resource is anything that can be
addressed with a URI. The description of a resource is composed of a number of
properties. Each property has a type and a value.

RDF Statements

An RDF document or element makes statements about resources. A statement says

that a certain resource has one or more properties. Each property has a type (that is,
a name) and a value. The value of a property may be a literal such as a string,
number, or date, or it may be another resource. A statement can be thought of as a
triple composed of three items: resource, property type, and property value. For
example, an RDF statement might say, “The book The XML Bible (ISBN: 0-7645-
3236-7) has the author Elliotte Rusty Harold.” Here the resource is “The book The
XML Bible (ISBN: 0-7645-3236-7),” and the author property of this resource has
the value “Elliotte Rusty Harold.”
QN
Discus the “rdf schema” with functionality with suitable example?

Rdf schema:-
RDF Schema (variously abbreviated as RDFS, RDF(S), RDF-S, or RDF/S) is an
extensible knowledge representation language, providing basic elements for the
description of ontologies, otherwise called Resource Description Framework (RDF)
vocabularies, intended to structure RDF resources. The first version[1] was published by
the World-Wide Web Consortium (W3C) in April 1998, and the final[2] W3C
recommendation was released in February 2004. 

Validity in RDF Schema:-

RDF schema meets its requirement for generality by being a vocabulary for
vocabularies (just as XML and SGML are languages for defining languages).
In RDF-speak, unlike general usage, a vocabulary is not just a list of words.
Rather, an RDF vocabulary may be said to define:
• Subject validity (which predicates go with which subjects)
• Object validity (which predicates go with which objects)
RDF schema can define a vocabulary that accomplishes these validity constraints
through what is called its typing system.

The RDFS Typing System

To “connect the dots” in the RDF typing system, we need to cover two concepts:
• rdf:type
• rdfs:subclassOf

rdf:type
enables class/instance statements to be made. When a resource has a type, the
resource is the object in a statement where the predicate is [rdf:type] and the subject
is the type.

Rdf : subclass
rdfs:subclassOf enables
subset/superset statements to be made. The class is the
superset; the subclass is the subset. When a resource is a subclass, the resource is
the object in a statement where the predicate is rdfs:subClassOf and the subject is an
RDF class.
The 16 RDF schema resources are divided into the following
six categories:
• Validation
• Core
• Hierarchy
• Documentation
• Schema control
• Extensibility

Validation:-
operation many information owners will want to perform on their data, just as they
want a database schema to control the quality of their RDBMS and they want an
XML DTD or XML schema to provide some level of quality
assurance for their data. Recall that there are two forms of schema validation in
RDF: object validity and subject validity. rdfs:domain handles subject validity;
rdfs:range handles object validity.

rdfs:domain
rdfs:domain is a type of rdfs:ConstraintProperty. It constrains the classes of subjects
(resources) for which the property is a valid predicate. If a property has no domain,
it can be the predicate of any subject. A property may have more than one range. If
a property has more than one rdfs:domain constraint, it may be the predicate of
subjects that are
subclasses of any one or all of the specified classes. The range and domain of the
rdfs:domain concept are specified only in a comment, so there is no pictorial
representation of rdfs:domain.

rdfs:range
rdfs:range is a type of rdfs:ConstraintProperty. It constrains the classes of objects
(resources) for which the property is a valid predicate. A property doesn’t have to
have a range. If so, the property can be used as an object in any statement.
However, when imposed, the constrains of rdfs:range are stronger than those
imposed by rdfs:domain.
First, a property can have only one range. Second, the domain (subject) of an
rdfs:range predicate must be an rdf:property, and its range (object) must be an rdfs:Class.
Core
Now that you understand the key concern of information owners—validation—
let’s move to the top of the RDF class hierarchy

rdfs:Resource
rdfs:Resource is the root of the RDF class hierarchy (refer back to Figure 23.8). All
things described by RDF expressions—all nodes and labels in the RDF graph—are
instances of rdfs:Resource. rdfs:Resource is also a class. In fact, rdfs:Resource is a type of
rdfs:Class, and rdfs:Class is a subclass of rdfs:Resource.

rdf:property
rdf:property represents the subset of RDF resources that are properties (see Table
23.1). rdf:property is a type of rdfs:Class and a subclass of rdfs:Resource. rdf:property has the
“rdf” namespace prefix, rather than the “rdfs” prefix, because the RDF model has
implicit properties, even if it lacks a schema.

rdf:type
rdf:type indicates that a resource is an instance of a specified class. That class must
be an instance of rfds:Class or a subclass of rdfs:Class. This statement is true for the
resource that is known as rdfs:Class, which is a type of itself. (The
RDF graph, again, permits loops.)
Like rdf:property, rdf:type has the “rdf” namespace prefix,
rather than the “rdfs” prefix, because the RDF model has implicit types, even if it
lacks a schema.

Class Hierarchy
The class hierarchy in RDF is set up by with rdfs:class, rdfs:subClassOf, and
rdfs:subPropertyOf (and rdf:type, which we’ve already looked at). Let’s look at these
three elements.

rdfs:Class
As you have seen, rdfs:Class is both a type of resource and a subclass of
itself.However, RDF classes are both like and unlike classes as OO programmers
may think of them. RDF classes are like OO classes in that, through transitivity,
they can specify broad-to-specific categories such as “living being to animal to
dog.” RDF classes are
unlike OO classes, first, because they have no methods—they don’t do anything.
(Markup never does.) Second, RDF classes could be called extrinsic rather
intrinsic. Instead of defining a class in terms of features intrinsic to its instances, an
RDF schema will define predicates in terms of the classes of subject or object to
which they may be
applied, extrinsically. (This allows testing for subject and object validity.)

rdfs:subClassOf
rdfs:subClassOf is
a type of rdf:property. It specifies a subset/superset relation between
classes—a relation that is transitive, Only instances of the type rdfs:Class may have
an rdfs:type property whose value is rdfs:Class.
Importantly, a class can never be declared to be a subclass of itself or any of its
own subclasses. (The RDF Schema specification cannot express this constraint
formally, though it is expressed in prose.) Therefore, although the RDF graph may
contain cycles, the class/subclass inheritance hierarchy that is a subgraph of the
RDF graph remains a tree, whose nodes are only instances of rdfs:Class. Finally,
RDF (unlike most object-oriented programming languages) permits multiple
inheritance—that is, a class may be a subclass of several classes.

rdfs:subPropertyOf
rdfs:subProperty isa type of rdf:property. It enables properties to be specialized—
aprocess similar to inheritance, except for properties instead of classes. Like the
subClassOf predicate, subPropertyOf is transitive and forms a hierarchy that is a proper
tree, like rdfs:subClassOf. Multiple specializations are also permitted

Documentation
Documentation allows human-readable text to be attached to a resource, either as a
label or a comment. Because the content of the documentation elements is only
data, not statements, it does not affect the RDF graph in any way and therefore
does not enable machine understanding of the resource.

rdfs:label
rdfs:label provides
for a human-readable representation of a URI, perhaps for
display.The domain (subject) of a label predicate must be an rdfs:resource. The range
(object) must an rdf:literal.

rdfs:comment
rdfs:comment permits
human-readable documentation to be associated with a
resource. The domain (subject) of a comment predicate must be an rdfs:resource. The
range (object) must an rdf:literal.

rdfs:seeAlso
rdfs:seeAlso is
a cross-reference that gives more information about a resource. The
nature of the information provided is not defined. The domain (subject) and range
(object) of an rdfs:seeAlso predicate must both be rdfs:resource elements

Schema Control
rdfs:isDefinedBy isa subproperty of rdfs:seeAlso. It’s URI is meant to be the address of
the RDF Schema for the subject resource. The domain (subject) and range (object)
of an rdfs:isDefinedBy predicate must both be rdfs:resource elements.

General Constraints
We now turn to the issue of constraints in general (that is, beyond the constraints
on domain and range, discussed earlier). At this point, there’s one caveat: Because
markup doesn’t do anything, RDFS doesn’t say what an application must do if a
constraint is violated. That is up to the application.

rdfs:ConstraintProperty
rdfs:ConstraintProperty is a subclass of both rdfs:ConstraintResource and rdf:property. Both
rdfs:domain and rdfs:range are instances of it.

Extensibility
rdfs:ConstraintResource is
a type of rdfs:Class and a type of rdfs:Resource. It is present in the
model so that other constraint properties besides domain and range may be
subclassed from it.
Non-Model Validation
This type of validation is called “non-model” because expressing the notion that a
literal should be checked for being a literal or that the auto-generated counter for
container children should be derived from the actual number of children is
something the RDF engine would have to do, not the data model.

rdfs:literal
rdfs:literal is
a type of rdfs:Class. An rdfs:literal can contain atomic values such as textual
strings. The XML lang attribute can be used to express the fact that a literal is in a
human language, but this information does not become a statement in the graph.

rdfs:ContainerMembershipProperty
rdfs:ContainerMemberShip is a type of rdfs:class and subclass of rdf:property. Its members
are the properties _1, _2, _3, and so on (the order in which the children of a
container appear in the container, under the ord component of the data model).

Ex:-
<?xml version="1.0"?>

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://www.animals.fake/animals#">

<rdf:Description rdf:ID="animal">
  <rdf:type
rdf:resource="http://www.w3.org/2000/01/rdf-
schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="horse">
  <rdf:type
rdf:resource="http://www.w3.org/2000/01/rdf-
schema#Class"/>
  <rdfs:subClassOf rdf:resource="#animal"/>
</rdf:Description>
</rdf:RDF>

QN:-
What is ajax , Explain how using x Queries data are
retrieve from an xml document with suitable Examples?

AJAX:-
 Is a group of interrelated web
development techniques used on the client-
side to create interactive web applications. With Ajax, web applications can
retrieve data from the server asynchronously in the background without interfering
with the display and behavior of the existing page. The use of Ajax techniques has led
citation needed]
to an increase in interactive or dynamic interfaces on web pages[ . Data is
usually retrieved using the XMLHttpRequest object. Despite the name, the use
of XML is not actually required, and the requests do not need to
[2]
be asynchronous.

Like DHTML and LAMP, Ajax is not a technology in itself, but a group of

technologies. Ajax uses a combination of HTML and CSS to mark up and style
information. The DOM is accessed withJavaScript to dynamically display, and to
allow the user to interact with, the information presented. JavaScript and the
XMLHttpRequest object provide a method for exchanging data asynchronously between
browser and server to avoid full page reloads.

Technologies
The term Ajax has come to represent a broad group of web technologies that can be
used to implement a web application that communicates with a server in the
background, without interfering with the current state of the page. In the article that
coined the term Ajax,[1] Jesse James Garrett explained that the following technologies
are incorporated:

 HTML or XHTML and CSS for presentation
 the Document Object Model (DOM) for dynamic display of and interaction with
data
 XML for the interchange of data, and XSLT for its manipulation
 the XMLHttpRequest object for asynchronous communication
 JavaScript to bring these technologies together
Since then, however, there have been a number of developments in the technologies
used in an Ajax application, and the definition of the term Ajax. In particular, it has been
noted that:

 JavaScript is not the only client-side scripting language that can be used for
implementing an Ajax application. Other languages such as VBScript are also
capable of the required functionality.[2][9]However JavaScript is the most popular
language for Ajax programming due to its inclusion in and compatibility with the
majority of modern web browsers.
 XML is not required for data interchange and therefore XSLT is not required for
the manipulation of data. JavaScript Object Notation (JSON) is often used as an
alternative format for data interchange,[10] although other formats such as
preformatted HTML or plain text can also be used.[11]
Basic Ajax involves writing ad hoc JavaScript in Web pages for the client. A simpler if
cruder alternative is to use standard JavaScript libraries that can partially update a
page, such as ASP.Net'sUpdatePanel. Tools (or web application frameworks) such
as Echo and ZK enable fine grained control of a page from the server, using only
standard JavaScript libraries.

Drawbacks

 Pages dynamically created using successive Ajax requests do not automatically

register themselves with the browser's history engine, so clicking the browser's
"back" button may not return the user to an earlier state of the Ajax-enabled page,
but may instead return them to the last full page visited before it. Workarounds
include the use of invisible IFrames to trigger changes in the browser's history and
changing the URL fragment identifier (the portion of a URL after the '#') when Ajax is
run and monitoring it for changes.[12][13]
 Dynamic web page updates also make it difficult for a user to bookmark a
particular state of the application. Solutions to this problem exist, many of which use
the URL fragment identifier (the portion of a URL after the '#') to keep track of, and
allow users to return to, the application in a given state.[12][13]
 Depending on the nature of the Ajax application, dynamic page updates may
interfere disruptively with user interactions, especially if working on an unstable
 internet connection. For instance, editing a search field may trigger a query to the
server for search completions, but the user may not know that a search completion
popup is forthcoming, and if the internet connection is slow, the popup list may show
up at an inconvenient time, when the user has already proceeded to do something
else.
 Because most web crawlers do not execute JavaScript code,[14] publicly
indexable web applications should provide an alternative means of accessing the
content that would normally be retrieved with Ajax, thereby allowing search
engines to index it.
 Any user whose browser does not support JavaScript or XMLHttpRequest, or
simply has this functionality disabled, will not be able to properly use pages which
depend on Ajax. Similarly, devices such as mobile phones, PDAs, and screen
readers may not have support for the required technologies. Screen readers that are
able to use Ajax may still not be able to properly read the dynamically generated
content.[15] The only way to let the user carry out functionality is to fall back to non-
JavaScript methods. This can be achieved by making sure links and forms can be
resolved properly and do not rely solely on Ajax.[16]
 The same origin policy prevents some Ajax techniques from being used across
domains,[7] although the W3C has a draft of the XMLHttpRequest object that would
enable this functionality.[17]Techniques exist to sidestep this limitation by using a
special Cross Domain Communications channel embedded as an iframe within a
page.[18]
 Like other web technologies, Ajax has its own set of vulnerabilities[which?] that
developers must address. Developers familiar with other web technologies may
have to learn new testing and coding methods to write secure Ajax applications.[19][20]
 Ajax-powered interfaces may dramatically increase the number of user-
generated requests to web servers and their back-ends (databases, or other). This
can lead to longer response times and/or additional hardware needs.
 The asynchronous, callback-style of programming required can lead to complex
code that is hard to maintain or debug. [21]

 Ajax cannot easily be read by screen-reading technologies, such as JAWS,

without hints built into the corresponding HTML based on WAI-ARIA standards.
Screen-reading technologies are used by individuals with an impairment that hinders
or prevents the ability to read the content on a screen.[22]
X-QUERIES:-
XQuery is a query and functional programming language that is designed to query
collections of XML data.
"The mission of the XML Query project is to provide flexible query facilities to
extract data from real and virtual documents on the World Wide Web, therefore finally
providing the needed interaction between the Web world and the database world.
Ultimately, collections of XML files will be accessed like databases".[1]
Features
XQuery provides the means to extract and manipulate data from XML documents or any
data source that can be viewed as XML, such as relational databases or office
documents.

XQuery uses XPath expression syntax to address specific parts of an XML document. It

supplements this with a SQL-like "FLWOR expression" for performing joins. A FLWOR
expression is constructed from the five clauses after which it is named: FOR, LET,
WHERE, ORDER BY, RETURN.

The language also provides syntax allowing new XML documents to be constructed.
Where the element and attribute names are known in advance, an XML-like syntax can
be used; in other cases, expressions referred to as dynamic node constructors are
available. All these constructs are defined as expressions within the language, and can
be arbitrarily nested.

The language is based on a tree-structured model of the information content of an XML

document, containing seven kinds of node: document nodes, elements, attributes, text
nodes, comments, processing instructions, and namespaces.

The type system of the language models all values as sequences (a singleton value is
considered to be a sequence of length one). The items in a sequence can either be
nodes or atomic values. Atomic values may be integers, strings, booleans, and so on:
the full list of types is based on the primitive types defined in XML Schema.

XQuery 1.0 does not include features for updating XML documents or databases; it also
lacks full text search capability. These features are both under active development for a
subsequent version of the language.

XQuery is a programming language that can express arbitrary XML to XML data
transformations with the following features:
 1. Logical/physical data independence
2. Declarative
3. High level
4. Side-effect free
5. Strongly typed

EX:-
<books-with-prices>
{
for $b in document("http://www.bn.com/bib.xml")//book,
$a in
document("http://www.amazon.com/reviews.xml")//entry
where $b/title = $a/title
return
<book-with-prices>
{ $b/title }
<price-amazon>{ $a/price/text() }</price-amazon>
<price-bn>{ $b/price/text() }</price-bn>
</book-with-prices>
}
</books-with-prices>

EX:-
<html><head/><body>
{
for $act in doc("hamlet.xml")//ACT
let $speakers := distinct-
values($act//SPEAKER)
return
<div>
<h1>{ string($act/TITLE) }</h1>
<ul>
{
 for $speaker in $speakers
return <li>{ $speaker }</li>
}
</ul>
</div>
}
</body></html>

Schema ex:-
<xsd:schema targetns="http://www.example.com/answer"
xmlns="http://www.example.com/answer"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
elementFormDefault="qualified">
<xsd:element name="ANSWER">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="BOOK"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="TITLE" type="xsd:string"/>
<xsd:element name="AUTHOR" type="xsd:string"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
X-query:-
element ANSWER { BOOK* }
element BOOK { TITLE, AUTHOR+ }
element AUTHOR { xsd:string }
element TITLE { xsd:string }

Applications
Below are a few examples of how XQuery can be used:

1. Extracting information from a database for a use in web service.

2. Generating summary reports on data stored in an XML database.
3. Searching textual documents on the Web for relevant information and compiling
the results.
4. Selecting and transforming XML data to XHTML to be published on the Web.
5. Pulling data from databases to be used for the application integration.
6. Splitting up an XML document that represents multiple transactions into multiple
XML documents.

Strengths and weaknesses

Usability studies have shown that XQuery is easier to learn than XSLT, especially for
users with previous experience of database languages such as SQL.[6] This can be
attributed to the fact that XQuery is a smaller language with fewer concepts to learn,
and to the fact that programs are more concise. It is also true that XQuery is more
orthogonal, in that any expression can be used in any syntactic context. By contrast,
XSLT is a two-language system in which XPath expressions can be nested in XSLT
instructions but not vice versa.

XSLT is currently stronger than XQuery for applications that involve making small
changes to a document (for example, deleting all the NOTE elements). Such
applications are generally handled in XSLT by use of a coding pattern that involves an
identity template that copies all nodes unchanged, modified by specific templates that
modify selected nodes. XQuery has no equivalent to this coding pattern, though in
future versions it will be possible to tackle such problems using the update facilities in
the language that are under development.[7]

Another facility lacking from XQuery is any kind of mechanism for dynamic binding or
polymorphism. The absence of this capability starts to become noticeable when writing
large applications, or when writing code that is designed to be reusable in different
environments. XSLT offers two complementary mechanisms in this area: the dynamic
matching of template rules, and the ability to override rules using xsl:import, that
make it possible to write applications with multiple customization layers.

The absence of these facilities from XQuery is a deliberate design decision: it has the
consequence that XQuery is very amenable to static analysis, which is essential to
achieve the level of optimization needed in database query languages. This also makes
it easier to detect errors in XQuery code at compile time.

The fact that XSLT 2.0 uses XML syntax makes it rather verbose in comparison to
XQuery 1.0. However, many large applications take advantage of this capability by
using XSLT to read, write, or modify stylesheets dynamically as part of a processing
pipeline. The use of XML syntax also enables the use of XML-based tools for managing
XSLT code. By contrast, XQuery syntax is more suitable for embedding in traditional
programming languages such as Java or C#. If necessary, XQuery code can also be
expressed in an XML syntax called XQueryX. The XQueryX representation of XQuery
code is rather verbose and not convenient for humans, but can easily be processed with
XML tools, for example transformed with XSLT stylesheets.[8][9]

QN:-

Explain the following

Sementic web, owl, TPmonitors, object brokers?
Sementic web:- The Semantic Web is an evolving development of
the World Wide Web in which the meaning (semantics) of information and
services on the web is defined, making it possible for the web to
"understand" and satisfy the requests of people and machines to use the
web content. ...

The Semantic Web provides a common framework that allows data to be

shared and reused across application, enterprise, and community
boundaries. It is a collaborative effort led by W3C with participation from a
large number of researchers and industrial partners. ...

A concept proposed by World Wide Web inventor Tim Berners-Lee. States

that the web can be made more useful by using methods such as content
tags to enable computers to understand what they're displaying and to
communicate effectively with each other. ...

Semantic Web is a group of methods and technologies to allow machines to

understand the meaning - or "semantics" - of information on the World Wide Web.
[1]
The term was coined by World Wide Web Consortium (W3C) director Tim
Berners-Lee.[2] He defines the Semantic Web as “a web of data that can be
processed directly and indirectly by machines.”

While the term "Semantic Web" is not formally defined it is mainly used to
describe the model and technologies[3] proposed by the W3C. These technologies
include the Resource Description Framework (RDF), a variety of data interchange
formats (e.g. RDF/XML, N3, Turtle, N-Triples), and notations such as RDF
Schema (RDFS) and the Web Ontology Language (OWL), all of which are
intended to provide a formal description of concepts, terms, and relationships
within a given knowledge domain.

The key element is that the application in context will try to determine the meaning
of the text or other data and then create connections for the user. The evolution of
Semantic Web will specifically make possible scenarios that were not otherwise,
such as allowing customers to share and utilize computerized applications
simultaneously in order to cross reference the time frame of activities with
documentation and/or data. According to the original vision, the availability of
machine-readable metadata would enable automated agents and other software to
access the Web more intelligently. The agents would be able to perform tasks
automatically and locate related information on behalf of the user.

Many of the technologies proposed by the W3C already exist and are used in
various projects. The Semantic Web as a global vision, however, has remained
largely unrealized and its critics have questioned the feasibility of the approach.

Purpose
The main purpose of the Semantic Web is driving the evolution of the current
Web by allowing users to use it to its full potential thus allowing users to
find,share, and combine information more easily. Humans are capable of using the
Web to carry out tasks such as finding the Irish word for "folder," reserving a
library book, and searching for a low price for a DVD. However, machines cannot
accomplish all of these tasks without human direction, because web pages are
designed to be read by people, not machines. The semantic web is a vision of
information that can be interpreted by machines, so machines can perform more of
the tedious work involved in finding, combining, and acting upon information on
the web.

OWL:-
The Web Ontology Language (OWL) is a family of knowledge representation
languages for authoring ontologies. The languages are characterised by formal
semantics and RDF/XML-based serializations for the Semantic Web. OWL is
endorsed by the World Wide Web Consortium (W3C)[1] and has attracted
academic, medical and commercial interest

The data described by an ontology in the OWL family is interpreted as a set of

"individuals" and a set of "property assertions" which relate these individuals to
each other. An ontology consists of a set of axioms which place constraints on sets
of individuals (called "classes") and the types of relationships permitted between
them. These axioms provide semantics by allowing systems to infer additional
information based on the data explicitly provided. A full introduction to the
expressive power of the OWL is provided in the W3C's OWL Guide.

Example

An ontology describing families might include axioms stating that a "hasMother"

property is only present between two individuals when "hasParent" is also present,
and individuals of class "HasTypeOBlood" are never related via "hasParent" to
members of the "HasTypeABBlood" class. If it is stated that the individual Harriet
is related via "hasMother" to the individual Sue, and that Harriet is a member of
the "HasTypeOBlood" class, then it can be inferred that Sue is not a member of
"HasTypeABBlood".

What is OWL?
 OWL stands for Web Ontology Language
 OWL is built on top of RDF
 OWL is for processing information on the web
 OWL was designed to be interpreted by computers
 OWL was not designed for being read by people
 OWL is written in XML
 OWL has three sublanguages
 OWL is a W3C standard

What is Ontology?
Ontology is about the exact description of things and their relationships.

For the web, ontology is about the exact description of web information and relationships
between web information.
Why OWL?
OWL is a part of the "Semantic Web Vision" - a future where:

 Web information has exact meaning

 Web information can be processed by computers
 Computers can integrate information from the web

OWL was Designed for Processing Information

OWL was designed to provide a common way to process the content of web information (instead
of displaying it).

OWL was designed to be read by computer applications (instead of humans).

OWL is Different from RDF

OWL and RDF are much of the same thing, but OWL is a stronger language with greater
machine interpretability than RDF.

OWL comes with a larger vocabulary and stronger syntax than RDF.

OWL Sublanguages
OWL has three sublanguages:

 OWL Lite
 OWL DL (includes OWL Lite)
 OWL Full (includes OWL DL)

OWL is Written in XML

By using XML, OWL information can easily be exchanged between different types of computers
using different types of operating system and application languages.

OWL is a Web Standard

OWL became a W3C (World Wide Web Consortium) Recommendation in February 2004.

A W3C Recommendation is understood by the industry and the web community as a web
standard. A W3C Recommendation is a stable specification developed by a W3C Working
Group and reviewed by the W3C Membership.

Species
[edit] OWL sublanguages

The W3C-endorsed OWL specification includes the definition of three variants of

OWL, with different levels of expressiveness. These are OWL Lite, OWL DL and
OWL Full (ordered by increasing expressiveness). Each of these sublanguages is a
syntactic extension of its simpler predecessor. The following set of relations hold.
Their inverses do not.

 Every legal OWL Lite ontology is a legal OWL DL ontology.

 Every legal OWL DL ontology is a legal OWL Full ontology.
 Every valid OWL Lite conclusion is a valid OWL DL conclusion.
 Every valid OWL DL conclusion is a valid OWL Full conclusion.

[edit] OWL Lite

OWL Lite was originally intended to support those users primarily needing a
classification hierarchy and simple constraints. For example, while it supports
cardinality constraints, it only permits cardinality values of 0 or 1. It was hoped
that it would be simpler to provide tool support for OWL Lite than its more
expressive relatives, allowing quick migration path for systems utilizing thesauri
and other taxonomies. In practice, however, most of the expressiveness constraints
placed on OWL Lite amount to little more than syntactic inconveniences: most of
the constructs available in OWL DL can be built using complex combinations of
OWL Lite features. Development of OWL Lite tools has thus proven almost as
difficult as development of tools for OWL DL, and OWL Lite is not widely used.

[edit] OWL DL

OWL DL was designed to provide the maximum expressiveness possible while

retaining computational completeness (either φ or ¬φ belong), decidability (there is
an effective procedure to determine whether φ is derivable or not), and the
availability of practical reasoning algorithms. OWL DL includes all OWL
language constructs, but they can be used only under certain restrictions (for
example, number restrictions may not be placed upon properties which are
declared to be transitive). OWL DL is so named due to its correspondence with
description logic, a field of research that has studied the logics that form the formal
foundation of OWL.

[edit] OWL Full

OWL Full is based on a different semantics from OWL Lite or OWL DL, and was
designed to preserve some compatibility with RDF Schema. For example, in OWL
Full a class can be treated simultaneously as a collection of individuals and as an
individual in its own right; this is not permitted in OWL DL. OWL Full allows an
ontology to augment the meaning of the pre-defined (RDF or OWL) vocabulary. It
is unlikely that any reasoning software will be able to support complete reasoning
for OWL Full.

[edit] OWL2 profiles

In OWL 2, there are three sublanguages of the language. OWL 2 EL is a fragment

that has polynomial time reasoning complexity; OWL 2 QL is designed to enable
easier access and query to data stored in databases; OWL 2 RL is a rule subset of
OWL 2.

[edit] Syntax
The OWL family of languages support a variety of syntaxes. It is useful to
distinguish high level syntaxes aimed at specification from exchange syntaxes
more suitable for general use.

[edit] High level

These are close to the ontology structure of languages in the OWL family.
[edit] OWL abstract syntax

This high level syntax is used to specify the OWL ontology structure and
semantics.[22]

The OWL abstract syntax presents an ontology as a sequence of annotations,

axioms and facts. Annotations carry machine and human oriented meta-data.
Information about the classes, properties and individuals that compose the
ontology is contained in axioms and facts only. Each class, property and individual
is either anonymous or identified by an URI reference. Facts state data either about
an individual or about a pair of individual identifiers (that the objects identified are
distinct or the same). Axioms specify the characteristics of classes and properties.
This style is similar to frame languages, and quite dissimilar to well known
syntaxes for description logics (DLs) and Resource Description Framework (RDF).
[22]

Sean Bechhofer, et. al. argue that though this syntax is hard to parse, it is quite
concrete. They conclude that the name abstract syntax may be somewhat
misleading.[23]

[edit] OWL2 functional syntax

This syntax closely follows the structure of an OWL2 ontology. It is used by

OWL2 to specify semantics, mappings to exchange syntaxes and profiles.[24]

[edit] Exchange syntaxes

[edit] RDF syntaxes

Syntactic mappings into RDF are specified[22][25] for languages in the OWL family.
Several RDF serialization formats have been devised. Each leads to a syntax for
languages in the OWL family through this mapping. RDF/XML is normative.[22][25]

[edit] OWL2 XML syntax

OWL2 specifies an XML serialization that closely models the structure of an

OWL2 ontology.[26]
[edit] Manchester Syntax

The Manchester Syntax is a compact, human readable syntax with a style close to
frame languages. Variations are available for OWL and OWL2. Not all OWL and
OWL2 ontologies can be expressed in this syntax

OBJECT REQUEST BROKER:-

In Common Object Request Broker Architecture (CORBA), an Object Request
Broker (ORB) is the programming that acts as a "broker" between a client request
for a service from a distributed object or component and the completion of that
request. Having ORB support in a network means that a client program can request
a service without having to understand where the server is in a distributed network
or exactly what the interface to the server program looks like. Components can
find out about each other and exchange interface information as they are running.

CORBA's ORB may be thought of as strategic middleware that is more

sophisticated conceptually and in its capabilities than earlier middleware, including
Remote Procedure Calls (RPCs), message-oriented middleware, database stored
procedures, and peer-to-peer services.

An ORB uses the CORBA Interface Repository to find out how to locate and
communicate with a requested component. When creating a component, a
programmer uses either CORBA's Interface Definition Language (IDL) to declare
its public interfaces or the compiler of the programming language translates the
language statements into appropriate IDL statements. These statements are stored
in the Interface Repository as metadata or definitions of how a component's
interface works.

In brokering a client request, an ORB may provide all of these services:

 Life cycle services, which define how to create, copy, move, and delete a component
 Persistence service, which provide the ability to store data on object database, , and
plain files
 Naming service, which allows a component to find another component by name and
also supports existing naming systems or directories, including
 DCE, , and Sun's NIS (Network Information System).

 Event service, which lets components specify events that they want to be notified of
 Concurrency control service, which allows an ORB to manage locks to data that
transactions or threads may compete for
 transaction service, which ensures that when a transaction is completed, changes are
committed, or that, if not, database changes are restored to their pre-transaction state
 Relationship service, which creates dynamic associations between components that
haven't "met" before and for keeping track of these associations
 Externalization service, which provides a way to get data to and from a component in a
"stream"
 Query service, which allows a component to query a database. This service is based on
the SQL3 specification and the Object Database Management Group's (ODMG) Object
Query Language (OQL).
 Licensing service, which allows the use of a component to be measured for purposes of
compensation for use. Charging can be done by session, by node, by instance creation,
and by site.
 Properties service, which lets a component contain a self-description that other
components can use.

In addition, an ORB also can provide security and time services. Additional
services for trading, collections, and change management are also planned. The
requests and replies that originate in ORBs are expressed through the Internet
Inter-ORB Protocol (IIOP) or other transport layer protocols.

TP-MONITOR:-

A Transaction Processing System or Transaction Processing Monitor is a set of

information which processes a data transaction in a database system that monitors
transaction programs (a special kind of program). The essence of a transaction
program is that it manages data that must be left in a consistent state. E.g. if an
electronic payment is made, the amount must be both withdrawn from one account
and added to the other; it cannot complete only one of those steps. Either both must
occur, or neither. In case of a failure preventing transaction completion, the
partially executed transaction must be 'rolled back' by the TPS. While this type of
integrity must be provided also for batch transaction processing, it is particularly
important for online processing: if e.g. an airline seat reservation system is
accessed by multiple operators, after an empty seat inquiry, the seat reservation
data must be locked until the reservation is made, otherwise another user may get
the impression a seat is still free while it is actually being booked at the time.
Without proper transaction monitoring, double bookings may occur. Other
transaction monitor functions include deadlock detection and resolution (deadlocks
may be inevitable in certain cases of cross-dependence on data), and transaction
logging (in 'journals') for 'forward recovery' in case of massive failures.

FUNCTION:-
Transaction processing is supported by programs called transaction processing
monitors (TP monitors). TP monitors perform the following three types of
functions:

 System runtime functions: TP monitors provide an execution environment

that ensures the integrity, availability, and security of data; fast response
time; and high transaction throughput.
 System administration functions: TP monitors provide administrative
support that lets users configure, monitor, and manage their transaction
systems.
 Application development functions: TP monitors provide functions for use
in custom business applications, including functions to access data, to
perform intercomputer communications, and to design and manage the
user interface.

Features
Rapid response

Fast performance with a rapid response time is critical. Businesses cannot afford to
have customers waiting for a TPS to respond, the turnaround time from the input of
the transaction to the production for the output must be a few seconds or less.
Reliability

Many organizations rely heavily on their TPS; a breakdown will disrupt operations
or even stop the business. For a TPS to be effective its failure rate must be very
low. If a TPS does fail, then quick and accurate recovery must be possible. This
makes well–designed backup and recovery procedures essential.

[edit] Inflexibility

A TPS wants every transaction to be processed in the same way regardless of the
user, the customer or the time for day. If a TPS were flexible, there would be too
many opportunities for non-standard operations, for example, a commercial airline
needs to consistently accept airline reservations from a range of travel agents,
accepting different transactions data from different travel agents would be a
problem.

[edit] Controlled processing

The processing in a TPS must support an organization's operations. For example if

an organization allocates roles and responsibilities to particular employees, then
the TPS should enforce and maintain this requirement.

ACID test properties: first definition

Atomicity

Main article: Atomicity (database systems)

A transaction’s changes to the state are atomic: either all happen or none happen.
These changes include database changes, messages, and actions on transducers.[2]

[edit] Consistency

Consistency: A transaction is a correct transformation of the state. The actions

taken as a group do not violate any of the integrity constraints associated with the
state. This requires that the transaction be a correct program![2]
[edit] Isolation

Even though transactions execute concurrently, it appears to each transaction T,

that others executed either before T or after T, but not both.[2]

[edit] Durability

Once a transaction completes successfully (commits), its changes to the state

survive failures.[2]

[edit] Concurrency

Ensures that two users cannot change the same data at the same time. That is, one
user cannot change a piece of data before another user has finished with it. For
example, if an airline ticket agent starts to reserve the last seat on a flight, then
another agent cannot tell another passenger that a seat is available.

QN:-

Compare and contrast the tightly Coupled and Loosly Coupled Web
Services
Tight coupling versus loose coupling

Most large, complex systems are built as small collections of large subsystems
instead of as large collections of small, independent subsystems. This is because of
the potential for increased performance, security, economy, or some other key
property that you can't get by decoupling the system into relatively independent,
small elements. The tight coupling characteristics of large-scale systems generally
result from optimizing the overall design and from minimizing redundancies and
inefficiencies among the system's components. This results in closer coupling
among the system's components and large numbers of critical interdependencies.

One disadvantage of tight coupling among a system's components is that failures

within the individual components tend to disable the entire system. Loosely
coupled Web services are seen as a better alternative; a Web service failure doesn't
disable the entire system, provided a failover Web service server is in place.

You can change details in loosely coupled Web services as long as those changes
don't affect the functionality of the called Web services. The tight-coupled systems
can be difficult to maintain, because changes in one system subcomponent usually
require the other subcomponent to adapt immediately.

Loosely coupled Web services require substantial redundancies unlike tight

coupling between clients and service, which minimizes redundancies. The listening
Web service and the requesting Web service might not trust each other. This means
security and trust standards must be added to get both the listener and requester to
trust each other. On the other hand, tightly calling and called coupled systems
assume that both have the knowledge of what each requires to trust one another.

Why use tight coupling for Web services?

Web services are normally message based and loosely coupled whether
the resource is scarce or not; they wait for an answer via message
queuing before they take further action, if any, based on the contents of
these messages. They have the advantage of messages being passed
instead of method invocations and provide a degree of independence
between the sending and receiving Web services.

It takes a large number of Web services to result in system overloads if

they collectively exceed the resource capacity of message-queuing
systems and if the capacity to handle peak loads wasn't considered in the
planning stage of building or reusing Web services with new
functionalities. It's time to start planning for the tight coupling of some
Web services.

Asynchronous versus synchronous

A loosely coupled Web service application can communicate

asynchronously and synchronously. Asynchronous Web services
communicate with one another as long as the applications support the
same standard message-based interface and speak a standard,
interoperable language (SOAP, for example). Answers are guaranteed
with exception-handling and error-recovery mechanisms. Synchronous
Web services require that they be compatible to communicate.

Asynchronous loosely coupled Web services spend time waiting for a

response. Synchronous loosely coupled Web services can't wait for an
answer, locking up the program until the response comes back.
Synchronous calls can be programmed, but with timeouts so that if the
call can't come back in a certain time, the calling Web service can be
unlocked to exit from the system.

One problem with asynchronous loosely coupled Web services is that

for some business functions, it can exceed its resource capacity for the
message queuing servers or system.

QN:-
EXPLAIN WEB SERVICES SECURITY,
SERVICE CONTRACT, SERVICE LEASE
AND RPC?

Web services security:-

WS-Security (Web Services Security, short WSS) is a flexible and feature-rich
extension to SOAP to apply security to web services. It is a member of the WS-*
family of web service specifications and was published by OASIS.

WS-Security describes enhancements to SOAP messaging to provide quality of

protection through message integrity, message confidentiality, and single message
authentication. These mechanisms can be used to accommodate a wide variety of
security models and encryption technologies.

The Web Services Security specification (WS-Security) provides a set of

mechanisms to help developers of Web Services secure SOAP message exchanges.
Specifically, WS-Security describes enhancements to the existing SOAP
messaging to provide quality of protection through the application of message
integrity, message confidentiality, and single message authentication to SOAP
messages. These basic mechanisms can be combined in various ways to
accommodate building a wide variety of security models using a variety of
cryptographic technologies.

WS-Security also provides a general-purpose mechanism for associating security

tokens with messages. However, no specific type of security token is required by
WS-Security. It is designed to be extensible (e.g. support multiple security token
formats) to accommodate a variety of authentication and authorization
mechanisms. For example, a requestor might provide proof of identity and a signed
claim that they have a particular business certification. A Web service, receiving
such a message could then determine what kind of trust they place in the claim.

Additionally, WS-Security describes how to encode binary security tokens and

attach them to SOAP messages. Specifically, the WS-Security profile
specifications describes how to encode Username Tokens, X.509 Tokens, SAML
Tokens , REL Tokens and Kerberos Tokens as well as how to include opaque
encrypted keys as a sample of different binary token types. With WS-Security, the
domain of these mechanisms can be extended by carrying authentication
information in Web services requests. WS-Security also includes extensibility
mechanisms that can be used to further describe the credentials that are included
with a message. WS-Security is a building block that can be used in conjunction
with other Web service protocols to address a wide variety of application security
requirements.

Message integrity is provided by leveraging XML Signature and security tokens to

ensure that messages have originated from the appropriate sender and were not
modified in transit. Similarly, message confidentiality leverages XML Encryption
and security tokens to keep portions of a SOAP message confidential.

Features
WS-Security describes three main mechanisms:
 How to sign SOAP messages to assure integrity. Signed messages provide
also non-repudiation.
 How to encrypt SOAP messages to assure confidentiality.
 How to attach security tokens.

The specification allows a variety of signature formats, encryptions

algorithms and multiple trust domains, and is open to various security
token models, such as:
 X.509 certificates
 Kerberos tickets
 UserID/Password credentials
 SAML-Assertion
 Custom defined token

The token formats and semantics are defined in the associated profile
documents.
WS-Security incorporates security features in the header of a SOAP
message, working in the application layer.

These mechanisms by themselves do not provide a complete security

solution for Web services. Instead, this specification is a building block
that can be used in conjunction with other Web service extensions and
higher-level application-specific protocols to accommodate a wide
variety of security models and security technologies. In general, WSS by
itself does not provide any guarantee of security. When implementing
and using the framework and syntax, it is up to the implementor to
ensure that the result is not vulnerable.

SERVICE CONTRACT:-

RPC:-
In computer science, a remote procedure call (RPC) is an inter-process
communication that allows a computer program to cause a subroutine or
procedure to execute in another address space (commonly on another computer
on a shared network) without the programmer explicitly coding the details for this
remote interaction. That is, the programmer writes essentially the same code
whether the subroutine is local to the executing program, or remote. When the
software in question uses object-oriented principles, RPC is called remote
invocation or remote method invocation

Message passing
An RPC is initiated by the client, which sends a request message to a known
remote server to execute a specified procedure with supplied parameters. The
remote server sends a response to the client, and the application continues its
process. There are many variations and subtleties in various implementations,
resulting in a variety of different (incompatible) RPC protocols. While the server is
processing the call, the client is blocked (it waits until the server has finished
processing before resuming execution).
An important difference between remote procedure calls and local calls is that
remote calls can fail because of unpredictable network problems. Also, callers
generally must deal with such failures without knowing whether the remote
procedure was actually invoked. Idempotent procedures (those that have no
additional effects if called more than once) are easily handled, but enough
difficulties remain that code to call remote procedures is often confined to
carefully written low-level subsystems.

[edit] Sequence of events during a RPC

1. The client calls the Client stub. The call is a local procedure call, with parameters pushed
on to the stack in the normal way.
2. The client stub packs the parameters into a message and makes a system call to send
the message. Packing the parameters is called marshalling.
3. The kernel sends the message from the client machine to the server machine.
4. The kernel passes the incoming packets to the server stub.
5. Finally, the server stub calls the server procedure. The reply traces the same in other
direction

What Is RPC

RPC is a powerful technique for constructing distributed, client-server

based applications. It is based on extending the notion of conventional,
or local procedure calling, so that the called procedure need not exist in
the same address space as the calling procedure. The two processes may
be on the same system, or they may be on different systems with a
network connecting them. By using RPC, programmers of distributed
applications avoid the details of the interface with the network. The
transport independence of RPC isolates the application from the physical
and logical elements of the data communications mechanism and allows
the application to use a variety of transports.

RPC makes the client/server model of computing more powerful and

easier to program. When combined with the ONC RPCGEN protocol
compiler (Chapter 33) clients transparently make remote calls through a
local procedure interface.

How RPC Works

An RPC is analogous to a function call. Like a function call, when an

RPC is made, the calling arguments are passed to the remote procedure
and the caller waits for a response to be returned from the remote
procedure. Figure 32.1 shows the flow of activity that takes place during
an RPC call between two networked systems. The client makes a
procedure call that sends a request to the server and waits. The thread is
blocked from processing until either a reply is received, or it times out.
When the request arrives, the server calls a dispatch routine that
performs the requested service, and sends the reply to the client. After
the RPC call is completed, the client program continues. RPC
specifically supports network applications.

Fig. 32.1 Remote Procedure Calling Mechanism A remote procedure

is uniquely identified by the triple: (program number, version number,
procedure number) The program number identifies a group of related
remote procedures, each of which has a unique procedure number. A
program may consist of one or more versions. Each version consists of a
collection of procedures which are available to be called remotely.
Version numbers enable multiple versions of an RPC protocol to be
available simultaneously. Each version contains a a number of
procedures that can be called remotely. Each procedure has a procedure
number.

RPC Application Development

Consider an example:

A client/server lookup in a personal database on a remote machine.

Assuming that we cannot access the database from the local machine
(via NFS).

We use UNIX to run a remote shell and execute the command this way.
There are some problems with this method:
 the command may be slow to execute.
 You require an login account on the remote machine.

The RPC alternative is to

 establish an server on the remote machine that can repond to queries.
 Retrieve information by calling a query which will be quicker than previous
approach.

To develop an RPC application the following steps are needed:

 Specify the protocol for client server communication
 Develop the client program
 Develop the server program
The programs will be compiled seperately. The communication protocol
is achieved by generated stubs and these stubs and rpc (and other
libraries) will need to be linked in.

Defining the Protocol

The easiest way to define and generate the protocol is to use a protocol
complier such as rpcgen which we discuss is Chapter 33.

For the protocol you must identify the name of the service procedures,
and data types of parameters and return arguments.

The protocol compiler reads a definitio and automatically generates

client and server stubs.

rpcgen uses its own language (RPC language or RPCL) which looks
very similar to preprocessor directives.

rpcgen exists as a standalone executable compiler that reads special files

denoted by a .x prefix.

So to compile a RPCL file you simply do

rpcgen rpcprog.x

This will generate possibly four files:

 rpcprog_clnt.c -- the client stub
 rpcprog_svc.c -- the server stub
 rpcprog_xdr.c -- If necessary XDR (external data representation) filters
 rpcprog.h -- the header file needed for any XDR filters.

The external data representation (XDR) is an data abstraction needed for

machine independent communication. The client and server need not be
machines of the same type