IT5404-Internet Application Development

Section 1
Web Applications Architecture

1.1. Component-Based
Development
Component-based
development
Component-based development (CBD) or Componentbased software development (CBSD) or componentbased software engineering (CBSE) is concerned with
the assembly of pre-existing software components into
larger pieces of software.
Here in this process software components are written in
such a way that they provide functions common to many
different systems.
Borrowing ideas from hardware components, the goal of
CBSD is to allow parts (components) of a software
system to be replaced by newer, functionally equivalent,
components.
Cont;
The Development Process
Component-based software development encompasses
two processes:
1. assembling software systems from software
components and
2. developing reusable components.
Component-based software development promises to
reduce development costs by enabling rapid
development of highly flexible and easily maintainable
software systems.
Cont;
Software applications are assembled from components
from a variety of sources; the components themselves
may be written in several different programming
languages and run on several different platforms.
As enterprise software systems continue to grow in
complexity, IT is struggling to find better ways to meet
the increasing demands of business. With pressure to
create higher quality software more quickly and at less
cost, enterprise IT must find ways to streamline
development. Devising an effective software reuse
strategy enables software development teams to
construct enterprise software systems through assembly
of reusable parts, and Component Based Development
(CBD) serves as a critical enabler of realizing higher
degrees of reusability.
Cont;
With many organizations embarking on large-scale
Service Oriented Architecture (SOA) initiatives,
Component Based Development (CBD) can play a
critical role in realizing higher degrees of reuse across
enterprise services and applications.
In fact, CBD is one of the few technologies that has
successfully bridged the gap between commercial and
open source software development.
Today, the open source community thrives on
componentization as the primary means of achieving
high degrees of reusability.
Cont;
Realizing maximum value and return on investment from
your enterprise software development initiatives in
todays diverse software ecosystem demands an
effective reuse strategy and this is where CBD can play
a useful role.
Components are considered to be part of the starting
platform for service orientation throughout software
engineering, for example Web Services, and more
recently, Service-Oriented Architecture (SOA) - whereby
a component is converted into a service and
subsequently inherits further characteristics beyond that
of an ordinary component.
Components can produce events or consume events
and can be used for event driven architecture (EDA).
Cont;
An individual component is a software package, or a
module, that encapsulates a set of related functions (or
data).
All system processes are placed into separate
components so that all of the data and functions inside
each component are semantically related (just as with
the contents of classes).
Because of this principle, it is often said that components
are modular and cohesive.
Cont;
A simple example of several software components - pictured within
a hypothetical holiday reservation system. Represented in UML 2.0.
Benefits of Software Reuse

Software reuse has been the holy grail of software
development for decades.
The business value realized through successful reuse
initiatives can offer substantial rewards.
Below are some of the advantages teams can achieve
through a successful CBD reuse initiative:
Reduced time-to-market CBD emphasizes
assembly of applications from pre-built parts. Robust
components have already undergone rigid testing
cycles. Because components are modularized and
independent units, they can often be developed in
parallel. Given the proper collaboration and testing
tools, teams can work effectively even when
dispersed throughout the world.
Cont;
Cont;:
Higher quality Components are discrete fine
grained units of behaviour, and automated tests can
be written that ensure each component undergoes a
strict test lifecycle. As components are field tested
upon being consumed by an increasing number of
applications, developers gain increased trust in CBD.
Decreased cost Increased modularity of
components helps isolate software functions,
providing an efficient mechanism to upgrade a
component without impacting an entire application.
Although the short-term cost of CBD is typically
greater than developing applications in silos, as
component reuse increases, the reduced time-tomarket and higher quality offer substantial long-term
savings.
Cont;
Cont;:
Increased organizational agility The ability of IT to
respond quickly to business needs is imperative in
todays dynamic business climate. As the component
inventory of your organization grows, teams are able
to enhance application functionality using pre-built
software components. Additionally, because change
requests of the business stakeholders are isolated to
discrete units of functionality, change can be made in
isolation and released to all component consumers.
1.2. Distributed Computing
Distributed Computing
Distributed computing is a science which solves a large
problem by giving small parts of the problem to many
computers to solve and then combining the solutions for
the parts into a solution for the problem.
Distributed computing is a field of computer science that
studies distributed systems.
A distributed system consists of multiple autonomous
computers that communicate through a computer
network. The computers interact with each other in order
to achieve a common goal.
Cont;
A computer program that runs in a distributed system is
called a distributed program, and distributed
programming is the process of writing such programs.
Distributed computing also refers to the use of
distributed systems to solve computational problems. In
distributed computing, a problem is divided into many
tasks, each of which is solved by one computer
Distributed Computing, or the use of a computational
cluster, is defined as the application of resources from
multiple computers, networked in a single environment,
to a single problem at the same time - usually to a
scientific or technical problem that requires a great
number of computer processing cycles or access to
large amounts of data.
Cont;
The concept of distributed computing is simple -- pull
together and employ all available resources to speed up
computing
Cont;
Cont;
Cont;
Client-Server
Client/server describes the relationship between two
computer programs in which one program, the client,
makes a service request from another program, the
server, which fulfills the request.
Although the client/server idea can be used by programs
within a single computer, it is a more important idea in a
network.
In a network, the client/server model provides a
convenient way to interconnect programs that are
distributed efficiently across different locations.
Cont;
Computer transactions using the client/server model are
very common.
For example, to check your bank account from your
computer, a client program in your computer forwards
your request to a server program at the bank.
That program may in turn forward the request to its own
client program that sends a request to a database server
at another bank computer to retrieve your account
balance. The balance is returned back to the bank data
client, which in turn serves it back to the client in your
personal computer, which displays the information for
you.
Client-Server Applications
The client-server model distinguishes between
applications as well as devices.
Network clients make requests to a server by sending
messages, and servers respond to their clients by acting
on each request and returning results.
One server generally supports numerous clients, and
multiple servers can be networked together in a pool to
handle the increased processing load as the number of
clients grows.
Cont;
A client computer and a server computer are usually two
separate devices, each customized for their designed
purpose.
For example, a Web client works best with a large
screen display, while a Web server does not need any
display at all and can be located anywhere in the world.
However, in some cases a given device can function
both as a client and a server for the same application.
Likewise, a device that is a server for one application
can simultaneously act as a client to other servers, for
different applications.
Cont;
Some of the most popular applications on the Internet
follow the client-server model including email, FTP and
Web services.
Each of these clients features a user interface (either
graphic- or text-based) and a client application that
allows the user to connect to servers.
In the case of email and FTP, users enter a computer
name (or sometimes an IP Address) into the interface to
set up connections to the server.
Client-Server
The client/server software architecture is a versatile,
message-based and modular infrastructure that is
intended to improve usability, flexibility, interoperability,
and scalability as compared to centralized, mainframe,
time sharing computing.
Client server architecture is an architecture of a
computer network in which many clients (remote
processors) request and receive service from a
centralized server (host computer).
Client computers provide an interface to allow a
computer user to request services of the server and to
display the results the server returns.
Cont;
Servers wait for requests to arrive from clients and then
respond to them.
Ideally, a server provides a standardized transparent
interface to clients so that clients need not be aware of
the specifics of the system (i.e., the hardware and
software) that is providing the service.
Today clients are often situated at workstations or on
personal computers, while servers are located elsewhere
on the network, usually on more powerful machines.
Cont;
This computing model is especially effective when clients
and the server each have distinct tasks that they
routinely perform.
In hospital data processing, for example, a client
computer can be running an application program for
entering patient information while the server computer is
running another program that manages the database in
which the information is permanently stored.
Many clients can access the server's information
simultaneously, and, at the same time, a client computer
can perform other tasks, such as sending e-mail.
Cont;
Because both client and server computers are
considered intelligent devices, the client-server model is
completely different from the old "mainframe" model,
which utilized a centralized mainframe computer that
performed all the tasks for its associated "dumb"
terminals.
Cont;
Client/Server Networks
Client/server networks use a single, specialized
computer (the server) as the central hub.
Client/server networks connect individual desktop PCs,
laptops, printers, and/or mobile devices.
Client/server networks allow users to be more productive
because they can share files, business applications,
Internet access, and equipment.
Client/server networks decrease the risk of data loss if a
PC's hard drive crashes because all information saved
on the server can be backed up.
Cont;
Cont;
Cont;
The End.
Section 2
Introduction to Web
Programming
2.1. PHP Installation and Apache
Configuration
Apache HTTP Server

The Apache HTTP Server Project is an effort to develop
and maintain an open-source HTTP server for modern
operating systems including UNIX and Windows NT.
The goal of this project is to provide a secure, efficient
and extensible server that provides HTTP services in
sync with the current HTTP standards.
Apache has been the most popular web server on the
Internet since April 1996.
The Apache HTTP Server is a project of The Apache
Software Foundation
What IS the Apache HTTP

Server Project?
The Apache HTTP Server Project is a collaborative
software development effort aimed at creating a robust,
commercial-grade, featureful, and freely-available source
code implementation of an HTTP (Web) server.
The project is jointly managed by a group of volunteers
located around the world, using the Internet and the Web
to communicate, plan, and develop the server and its
related documentation.
This project is part of the Apache Software Foundation.
In addition, hundreds of users have contributed ideas,
code, and documentation to the project.
Using Apache HTTP Server

on Microsoft Windows
Downloading Apache for Windows
Information on the latest versions of Apache can be
found on the web site of the Apache web server at
http://httpd.apache.org/download.cgi.
Installing Apache for Windows
Run the Apache .msi file you downloaded above. The
installation will ask you for these things:
Network Domain. Enter the DNS domain in which your
server is or will be registered in. For example, if your
server's full DNS name is server.mydomain.net, you
would type mydomain.net here.
Cont;
Installing Apache for Windows cont;
Server Name. Your server's full DNS name. From the
example above, you would type server.mydomain.net
here.
Administrator's Email Address. Enter the server
administrator's or webmaster's email address here. This
address will be displayed along with error messages to
the client by default.
Cont;
Cont;
Installing Apache for Windows cont;
For whom to install Apache Select for All Users, on
Port 80, as a Service - Recommended if you'd like your
new Apache to listen at port 80 for incoming traffic. It will
run as a service (that is, Apache will run even if no one is
logged in on the server at the moment) Select only for
the Current User, on Port 8080, when started Manually if
you'd like to install Apache for your personal
experimenting or if you already have another WWW
server running on port 80.
Cont;
The installation type. Select Typical for everything
except the source code and libraries for module
development. With Custom you can specify what to
install. A full install will require about 13 megabytes of
free disk space. This does not include the size of your
web site(s).
Where to install. The default path is C:\Program
Files\Apache Software Foundation under which a
directory called Apache2.2 will be created by default.
During the installation, Apache will configure the files in
the conf subdirectory to reflect the chosen installation
directory.
Cont;
After installing Apache, you may edit the configuration files in the
conf subdirectory as required. These files will be configured during
the installation so that Apache is ready to be run from the directory it
was installed into, with the documents server from the subdirectory
htdocs.
Cont;
Windows Security Alert for the Apache HTTP server.
Cont;
Testing the Apache HTTP server installation
In order to test your Apache web server installation,
open a browser and enter http://localhost/ into the
address bar
The Test Page for Apache installation should be
displayed into your browser.
If you don't get the test page it might be that the Apache
web server was not able to start for some reason, check
the error.log file in the logs folder of the web server (see
the next section).
Cont;
The Test Page for Apache installation
Solving the problems you

might face
"Why can't I ...? Why won't ... work?" What to do in
case of problems
If you are having trouble with your Apache server
software, you should take the following steps:
Check the ErrorLog!
Apache tries to be helpful when it encounters a
problem. In many cases, it will provide some details
by writing one or more messages to the server error
log. Sometimes this is enough for you to diagnose
and fix the problem yourself (such as file permissions
or the like). The default location of the error log is
/usr/local/apache2/logs/error_log, but see the
ErrorLog directive in your config files for the location
on your server.
Cont;
Cont;
If you end up in any of the support forums this is quite
likely to be the first place they will ask you retrieve
information from. Please ensure you know where to
find your errorlog. If you are unsure, the wiki page
http://wiki.apache.org/httpd/DistrosDefaultLayout can
give you some ideas where to look.
Consult the wiki
The Apache HTTP Server Wiki
(http://wiki.apache.org/httpd/) contains guides to
solving many common problems.
Cont;
Cont;
Check the Apache bug database
Most problems that get reported to The Apache
Group are recorded in the bug database
(http://httpd.apache.org/bug_report.html).
Do not submit a new bug report until you have
checked existing reports (open and closed) and
asked about your problem in a user-support forum
(see below). If you find that your issue has already
been reported, please don't add a "me, too" report.
Cont;
Cont;
Ask in a user support forum
Apache has an active community of users who are
willing to share their knowledge. Participating in this
community is usually the best and fastest way to get
answers to your questions and problems.
Users mailing list
(http://httpd.apache.org/userslist.html)
Please use the bug database for bugs!
If you've gone through those steps above that are
appropriate and have obtained no relief, then please
do let the httpd developers know about the problem
by logging a bug report.
(http://httpd.apache.org/bug_report.html)
Understanding the Apache

server folder structure
It is important to understand some part of the Apache HTTP server
folder structure, or where is what located.
Cont;
The bin folder
The bin folder contains amongst other files the server
executable: Apache.exe and a program to control the
Apache HTTP server when ran as service:
ApacheMonitor.exe.
Also contained in this folder are htpasswd.exe and
htdigest.exe for making parts of your site(s) restricted.
Cont;
The conf folder
This folder holds the configuration files used by the
Apache web server.
Of each file used by the server there is a copy which
has .default in its name, e.g. httpd.default.conf.
The access.conf and srm.conf files are empty (except
for comments) by default, and we recommend to not
use those files for configuring the server.
The httpd.conf file has already been updated by the
installation process. I list some of those modified
settings below, including a short description and the
line number (which might differ with your version).
Cont;
Cont;
Listen 80 - The port the Apache server is using. If you
have already a web server running, for example as
part of Microsoft Internet Information Services (IIS),
you might want to change the number to something
different (line 120).
ServerAdmin admin@localhost - The email address
of the server administrator, which is used on, for
example, error pages generated by the server (line
198).
ServerName localhost:80 - The hostname and port
the server uses (line 212).
Cont;
htdocs folder
This folder contains the default HTML page you see
when you visit http://localhost/ with your web browser.
Don't start adding your HTML documents and related
files to this folder, but read on.
manual folder
This folder contains the Apache HTTP server
documentation, available as http://localhost/manual/.
Note that this folder shows up under the document
root thanks to the AliasMatch directive in the
httpd.conf server configuration file (line 491).
Cont;
logs folder
This folder contains (amongst others) the access.log
and error.log files.
If anything goes wrong, for example the notorious 500
Internal Server Error, make sure that you check the
error.log file.
With virtual hosting you can give each site its own log
file (discussed below), so be sure to check the right
file(s).
Stopping and starting Apache

After changes have been made to the httpd.conf file,
Apache has to be restarted.
If you are logged in with Administrator rights the easiest
way to do this is by using the Apache monitor which is
started when you log in and available via the system
tray.
Click the right mouse (context menu) button on the red
feather icon in the system tray and select the Open
Apache Monitor menu entry.
You can restart the Apache HTTP server with a single
mouse click on the Restart button.
Cont;
Apache monitor
The End.
Section 3 Part 1
XML Fundamentals
3.1. Basic XML
Basic XML
HTML is used to create web pages
HTML documents lead to the creation of the
World Wide Web layer of visual documents that
is on the Internet
HTML is a formatting and display language for
web pages
XML stands for EXtensible Markup Language
Basic XML
XML is a markup language much like
HTML
XML was designed to carry data, not to
display data
XML tags are not predefined. You must
define your own tags
XML Document Example

<?xml version="1.0"?>
<address>
<name>nimal</name>
<no>24</no>
<street>1st lane</street>
<city>Colombo</city>
<country>sri lanka</country>
</address >
The Difference Between XML and HTML

XML is not a replacement for HTML.
XML and HTML were designed with different goals:
XML was designed to transport and store data, with
focus on what data is.
HTML was designed to display data, with focus on
how data looks.
HTML is about displaying information, while XML is
about carrying information.
Cont;
XML Does not DO Anything
Maybe it is a little hard to understand, but XML does
not DO anything. XML was created to structure,
store, and transport information.
The following example is a address of a person,
stored as XML:
Cont;
<address>
<name>nimal</name>
<no>24</no>
</address >
The address above is quite self descriptive. It has the
persons address information, it also has the name of
the person.
But still, this XML document does not DO anything. It
is just pure information wrapped in tags. Someone
must write a piece of software to send, receive or
display it.
Cont;
XML is a meta-language it is a language used to
create other markup languages.
XML provides a basic structure and set of rules
to which any markup language must adhere.
Using XML, you can create a unique markup
language to model just about any kind of
information, including web page content
XML lays the ground rules for organizing
information in a consistent manner, and that
information can be anything from web pages to
describing any entity
Cont;
XML is not entirely about web pages and can be
used to represent any kind of information on any
kind of computer. However, one of the first
applications of XML is to restore some order and
consistency to the Web.
One of the main benefits of XML is the ability to
develop XML documents once and then have
them viewable on a range of devices, such as
desktop computers, handheld computers, mobile
phones, and Internet appliances.
Cont;
A XML document would look like this:
An Address Book Eg
<?xml version="1.0" encoding="UTF-8"?>
<addressBook>
<friend firstName="nimal" lastName="gurusinghe" age="39">
<address>
24, 2nd Lane, Col 7
</address>
<gender type="male" />
<description>
This is a school time friend.
He is a good loyal genuine friend.
</description>
</friend>
Cont;
<friend firstName="ann" lastName="perera" age="29">
<address>123, Galle Rd, Dehiwala</address>
<gender type="female"></gender>
</friend>
<friend firstName="kamal" lastName="weerakkody">
<description>
This is a friend at my office.
He is a software engineer.
</description>
</friend>
</addressBook>
XML is Just Plain Text

XML is nothing special. It is just plain text.
Software that can handle plain text can also
handle XML.
However, XML-aware applications can handle
the XML tags specially. The functional meaning
of the tags depends on the nature of the
application.
Unlike a database, XML data is pure text.
For example, you can open up any XML
document in a text editor such as Windows
Notepad and view or edit the code.
XML is Just Plain Text

Because XML is pure text also makes it very
easy for applications to transfer data between
one another, across networks, and also across
different computing platforms such as Windows,
Macintosh, and Linux.
XML essentially establishes a platform-neutral

means of structuring data, which is ideal for
networked applications, including web-based
applications.
Cont;
One of the main goals of XML is to separate the
meaning of information from the presentation of it.
Although presentation plays an important role in any web
site, modern web applications have evolved to become
driven by data of very specific types, such as financial
transactions.
HTML is a very poor markup language for representing
such data.
With its support for custom markup languages, XML
makes it possible to carefully describe data and the
relationships between pieces of data.
XML is Not a Replacement for HTML

XML is a complement to HTML.
It is important to understand that XML is not a replacement
for HTML. In most web applications, XML is used to
transport data, while HTML is used to format and display
the data.
A description of XML is:
XML is a software- and hardware-independent tool
for carrying information.
XML
XML has 3 fundamental building blocks: elements,
attributes, and values.
An element is used to describe or contain a piece of

information
Elements consist of two tags: an opening tag and a

closing tag
Examples of opening tags are <address> and <friend>
Examples of closing tags are </address> and </friend>
XML
Elements always appear as an opening
tag, followed by optional data, followed by a
closing tag:
Eg:
Cont;
Tags typically contain text content or additional tags.
Eg:
<friend>
<address>
24, 2nd Lane, Col 7
</address>
</friend>
XML Attributes
From HTML you will remember this: <img src="computer.gif">
The "src" attribute provides additional information about the
<img> element.
In HTML (and in XML) attributes provide additional information
about elements:
<img src="computer.gif">
<a href="demo.asp">
Attributes often provide information that is not a part of the
data. In the example below, the file type is irrelevant to the
data, but important to the software that wants to manipulate the
element:
<file type="gif">computer.gif</file>
Empty elements
An empty element is an element that doesn't contain any
content within its opening and closing tags.
Eg:
<gender type="male"></gender>
Because empty elements don't contain any content
between their opening and closing tags, you can
abbreviate them by using a single tag known as an empty
tag.
Eg:
So why you'd want to use an element that has no
content? The reason for this is because you can still
attach attributes to empty elements.
Cont;
Attributes are small pieces of information that appear
within an element's opening tag. The value of an attribute
must appear within quotes.
Eg:
<friend firstName="nimal" />
In this example, the firstName attribute is used to identify
the first name of a friend. Attributes aren't limited to
empty elements. Following is an example of how several
attributes are used to describe a friend in detail:
Eg:
<friend firstName="nimal" lastName="gurusinghe"
age="39">
XML Elements vs. Attributes

Take a look at these examples:
<person sex="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
Cont;
In the first example sex is an attribute. In the last, sex is
an element. Both examples provide the same
information.
There are no rules about when to use attributes and

when to use elements. Attributes are handy in HTML. In
XML my advice is to avoid them. Use elements instead.
More about an Element

A nonempty element is an element that contains content
within its opening and closing tags.
This content could be either text or additional elements
When elements are contained within other elements,
they are known as nested elements.
To understand how nested elements work, consider how
a food menu is represented in XML.
Cont;
<breakfast_menu>
<food>
<name>Belgian Waffles</name>
<price>$5.95</price>
<description>two of our famous Belgian Waffles with
plenty of real maple syrup</description>
<calories>650</calories>
</food>
<food>
<name>Strawberry Belgian Waffles</name>
<description>light Belgian waffles covered with
strawberries and whipped cream</description>
</food>
Cont;
<food>
<name>Berry-Berry Belgian Waffles</name>
<description>light Belgian waffles covered with an
assortment of fresh berries and whipped
cream</description>
</food>
</breakfast_menu>
Cont;
Eg:
<apartmentbldg>
<apartment>
<room type="bedroom">
<furniture type="armoire">
<belonging type="t-shirt" color="navy"
size="xl" />
<belonging type="sock" color="white" />
<belonging type="watch" />
</furniture>
</room>
</apartment>
</apartmentbldg>
Cont;
It's important to recognize in this example that
the belonging elements are empty elements.
These elements are empty because they aren't
required to contain any additional information.
In other words, it is sufficient to describe the
belonging elements solely through attributes.
It's important to realize that nonempty elements
aren't just used for nesting purposes.
Cont;
Nonempty elements often contain text
content, which appears between the
opening and closing tags.
Following is an example of how you might
decide to expand the belonging element
so that it isn't empty:
Cont;
Eg:
<furniture type="desk">
<belonging type="letter">
Dear Michael,
I am pleased to announce that you may have won
our sweepstakes. You are one of the lucky finalists
in your area, and if you would just purchase five or
more magazine subscriptions then you may
eventually win some money. Or not.
</belonging>
</furniture>
XML Rules
1.
Tag names are case sensitive.

With XML, the tag <Letter> is different from the tag <letter>.
Opening and closing tags must be written with the same
case:
<Message>This is incorrect</message>
<message>This is correct</message>
2.
Every opening tag must have a corresponding closing tag

(unless it is as an empty tag).
XML Rules
3.
A nested tag pair cannot overlap another tag.

In HTML, you might see improperly nested elements:
<b><i>This text is bold and italic</b></i>
In XML, all elements must be properly nested within each

other:
<b><i>This text is bold and italic</i></b>
In the example above, "Properly nested" simply means that

since the <i> element is opened inside the <b> element, it
must be closed inside the <b> element.
Cont;
4.
Attribute values must appear within quotes.
5.
Every document must have a root element.
XML documents must contain one element that is the

parent of all other elements.
This element is called the root element.
Every XML document must contain a root element,

which means that exactly one element must be at the
top level of any given XML document. In the "Address
Book" example above, the addressBook element is the
root element because it contains all the other elements
in the document.
Special Symbols in XML

There are a few special symbols which you have to enter
in a different way inside a XML document. This is because
these symbols are considered as part of the XML syntax.
For an example ampersand (&) character is a character
used in XML syntax. So the following code is not allowed.
<shop name="perera & sons" />
The solution is to use special predefined symbols which
are known as entities.
Cont;
Following are the predefined entities for the special
characters:
Less than symbol (<)<

Greater than symbol (>)>
Quote symbol (")"
Apostrophe symbol (')'
Ampersand symbol (&)&
Cont;
So the corrected code is:
<shop name="perera & sons" />
Eg:
If you place a character like "<" inside an XML element, it
will generate an error because the parser interprets it as
the start of a new element.
This will generate an XML error:
<message>if salary < 1000 then</message>
To avoid this error, replace the "<" character with an
entity reference:
<message>if salary < 1000 then</message>
The XML Declaration

The XML declaration notifies an application or web
browser of the XML version that an XML document is
using. Following is the standard XML declaration for
XML 1.0:
<?xml version="1.0"?>Eg: <?xml version="1.0"
encoding="UTF-8"?>
<addressBook>
age="39">
</friend>
</addressBook>
Selecting an XML Editor

To write/create your XML documents you have to use a
XML editor.
Some of the editors which you can use are: Windows
NotePad, Windows WordPad, Altova XMLSpy and
Butterfly XML.
NotePad
Altova XMLSpy
Viewing Your XML Document

To format and view your XML document you can use
Cascading Style Sheets (CSS) and eXtensible Style
Language (XSL).
This will be discussed in the section Formatting XML
Documents.
Comments in XML
Eg:

Entities
There are two types of Entities.
1) Parsed Entities
2) Unparsed Entities
Parsed Entities
Entities must be declared before use. Example Entity
declaration:
<!ENTITY copyright Copyright ABC company>
Example of referencing the above entity:
Welcome to Sales system. &copyright;
Thank you for visiting our web site
In this example the content of the copyright entity are

replaced in the text where the reference occurs.
Cont;
Predefined Entities
The following 5 entities can be used without being declared.
Character
Entity
Less-than symbol (<)
<
Greater-than symbol (>)
>
Quote symbol (")
"
Apostrophe symbol (')
'
Ampersand symbol (&)
&
Unparsed Entities
Unparsed entities aren't processed by XML applications
and are capable of storing text or binary data.
Unparsed external entities are often binary files such as
images, which obviously cannot be parsed by an XML
processor.
Unparsed external entities are identified using the
NDATA keyword in their entity declaration; NDATA (Not
DATA) simply indicates that the entity's content is not
XML data.
Another important way to look at entities

is to consider how they are stored
Internal Entities
External Entities
Internal entities are stored within the document that

references them
External entities are stored outside of the document that
references them
Cont;
External entity declarations are different than
internal entity declarations because they must
reference an external storage location.
Files associated with external entities can be
specified in one of two ways, depending on
whether the file is located on the local file system
or is publicly available on a network:
SYSTEM The file is located on the local file system or
on a network
PUBLIC The file is a public-domain file located in a
publicly accessible place
Cont;
When specifying the location of external entities, you must
always use the SYSTEM keyword to identify a file on a
local system or network; the PUBLIC keyword is optional
and is used in addition to the SYSTEM keyword.
The file for an external entity is specified as a URI.
Following is an example of declaring a JPEG image entity
using a relative URI:
<!ENTITY skate SYSTEM "pond.jpg" NDATA JPEG>
CDATA
CDATA means character data.
CDATA is text that will NOT be parsed by a parser.
Tags inside the text will NOT be treated as markup and
entities will not be expanded.
Like unparsed entities, a XML processor will not process
what is written inside a CDATA section.
CDATA
Example of a CDATA section is:
This is a face:
<![CDATA[
*****
*@@*
* ) *
* ~~~ *
*****
]]>
Cont;
In this example, the drawing of a face is kept intact
because it isn't processed as XML data.
If it wasn't enclosed in a CDATA section, the white space
within it would be processed down to a few spaces, and
the drawing would be ruined.
CDATA sections are very useful any time you want to
preserve the exact appearance of text.
You can also place legitimate XML code in a CDATA
section to temporarily disable it and keep it from being
processed.
PCDATA
PCDATA means parsed character data.
Think of character data as the text found between the
start tag and the end tag of an XML element.
PCDATA is text that WILL be parsed by a parser. The
text will be examined by the parser for entities and
markup.
PCDATA
Tags inside the text will be treated as markup and
entities will be expanded.
However, parsed character data should not contain any
&, <, or > characters; these need to be represented by
the & < and > entities, respectively.
The End.
Section 3 Part 2a
XML Fundamentals
3.1.1. Well-formedness & Validity
Well-formedness
When the XML document is correctly
written according to the XML syntax rules
it is called a well-formed XML document.
Well-formed XML documents should follow
the five rules explained in section 3.1
Validity (Valid XML document)

When a XML document is written according to a
DTD (Document Type Definition) or a XSD (XML
Schema), it is called as a valid XML document.
DTD and XSD are discussed in section 3.1.2.
A valid XML document is always well-formed.
A well-formed XML document may not be valid
3.1.2. DTDs and Schemas

Part 1
Basics of DTDs and Schemas

When you create an XML document, you aren't really
using XML to code the document.
Instead, you are using a markup language that was
created in XML.
In other words, XML is used to create markup languages
that are then used to create XML documents.
When you create your own markup language, you are
basically establishing which elements (tags) and
attributes are used to create documents in that
language.
Cont;
Not only is it important to fully describe the different
elements and attributes, but you must also describe how
they relate to one another.
For example, if you are creating a markup language to
keep track of contacts information so that you can keep
a record of your friends details, you might use tags such
as < friend >, < address >, < gender >, <contactNo>, and
so on.
Examples of attributes for the friend element might
include firstName, lastName, and age and so on.
Cont;
How do you define the structure of a XML document?
How do you define what elements a XML document can
have?
How do you define what content an element can have?
How do you define what attributes an element can have?
How those elements and attributes are related to each
other?
Cont;
The above questions mean that there should be
a way to define those rules.
This set of rules is known as the schema for a
markup language.
A schema describes the exact elements and
attributes that are available within a given
markup language, along with which attributes
are associated with which elements and the
relationships between the elements.
Cont;
You can think of a schema as a legal contract between
the person who created the markup language and the
person who will create documents using that language.
Cont;
To create schemas we use:
Document Type Definitions (DTDs)
XML Schemas (XSDs)
Address Book XML Document

<!DOCTYPE addressBook SYSTEM "AddressBook2.dtd">
<addressBook>
age="39">
<address>
24, 2nd Lane, Col 7
</address>
<gender>male</gender>
</friend>
cont
Cont
Cont;
<friend firstName="ann" lastName="perera" age="29">

<gender>female</gender>
</friend>
<friend firstName="kamal" lastName="weerakkody"
age="25">
<address>Galle</address>
<gender>male</gender>
</friend>
</addressBook>
Document Type Definitions (DTDs)

A Simple DTD for the Address Book XML Document
<!ELEMENT addressBook (friend)+>
<!ELEMENT friend (address, gender)>
<!ATTLIST friend
CDATA #REQUIRED
CDATA #REQUIRED
CDATA #IMPLIED>
<!ELEMENT address (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
XML Schema (XSDs)

A Simple XML Schema for the Address Book XML
Document
XML Schemas are written in XML Schema Definition (XSD)
language.
XML Schemas are based on XML syntax
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="addressBook">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="friend">
cont;
Cont;
cont;
<xsd:complexType>
<xsd:sequence>
<xsd:element name="address" type="xsd:string"/>
<xsd:element name="gender" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="firstName" type="xsd:string"
use="required"/>
<xsd:attribute name="lastName" type="xsd:string"
use="required"/>
<xsd:attribute name="age" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Basics of creating a DTD

In order to use a DTD with a document, you must first
associate the DTD with the document.
This association is carried out through the document
type declaration, which must be placed at the beginning
of an XML document just after the XML declaration:
<!DOCTYPE addressBook SYSTEM
"AddressBook2.dtd">
The following types of markup declarations may be used
within a DTD:
The elements allowed in the document
The attributes that may be assigned to each element
Cont;
Cont;
Entities that are allowed in the document
Notations that are allowed for use with external
entities
When associating a DTD with a document, there are two
approaches the document type declaration can take:
It can directly include markup declarations in the
document that form the internal DTD.
It can reference external markup declarations that
form the external DTD.
Cont;
The external DTD typically describes the general
structure for a class of documents, whereas the internal
DTD is specific to a given document.
XML gives preference to the internal DTD, which means
you can use it to override declarations in the external
DTD.
Parts of a DTD
A DTD can be declared inline inside an XML document,
or as an external reference.
Internal DTD Declaration
If the DTD is declared inside the XML file, it should be
wrapped in a DOCTYPE definition with the following
syntax:
<!DOCTYPE root-element [element-declarations]>
Example XML document with an internal DTD is in next
slide:
Cont;
Example XML document with an internal DTD:
<!DOCTYPE address [
<!ELEMENT address (name,no,street,city,country)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT no (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT country (#PCDATA)>
]>
<address>
<name>nimal</name>
<no>24</no>
</address >
Cont;
The DTD above is interpreted like this:
!DOCTYPE address defines that the root element of
this document is address
!ELEMENT address defines that the address
element contains five elements:
"name,no,street,city,country
!ELEMENT name defines the name element to be of
type "#PCDATA"
Cont;
Cont;
!ELEMENT no defines the no element to be of type
"#PCDATA
!ELEMENT street defines the street element to be of
type "#PCDATA
!ELEMENT city defines the city element to be of type
"#PCDATA
!ELEMENT country defines the country element to
be of type "#PCDATA
External DTD Declaration

If the DTD is declared in an external file, it should be
wrapped in a DOCTYPE definition with the following
syntax:
<!DOCTYPE root-element SYSTEM "filename">
This is the same XML document as above, but with an
external DTD
<!DOCTYPE address SYSTEM address.dtd">
<address>
<name>nimal</name>
<no>24</no>
</address >
Cont;
And this is the file address.dtd" which contains
the DTD:

Declaring Elements
In a DTD, XML elements are declared with an element
declaration with the following syntax:
<!ELEMENT element-name category>
or
<!ELEMENT element-name (element-content)>
Cont;
Empty Elements
Empty elements are declared with the category keyword
EMPTY:
<!ELEMENT element-name EMPTY>
Example:
<!ELEMENT br EMPTY>
XML example:
<br />
Cont;
Elements with Parsed Character Data
Elements with only parsed character data are
declared with #PCDATA inside parentheses:
<!ELEMENT element-name (#PCDATA)>
Example:
Cont;
Elements with any Contents
Elements declared with the category keyword
ANY, can contain any combination of parsable
data:
<!ELEMENT element-name ANY>
Example:
<!ELEMENT address ANY>
Cont;
Elements with Children (sequences)
Elements with one or more children are declared
with the name of the children elements inside
parentheses:
<!ELEMENT element-name (child1)>
or
<!ELEMENT element-name (child1,child2,...)>
Example:
Cont;
Elements with Children (sequences) cont;
When children are declared in a sequence separated by
commas, the children must appear in the same
sequence in the document.
In a full declaration, the children must also be declared,
and the children can also have children.
Cont;
Elements with Children (sequences) cont;
The full declaration of the address" element is:
Cont;
Declaring Only One Occurrence of an Element
<!ELEMENT element-name (child-name)>
Example:
<!ELEMENT address (street)>
The example above declares that the child

element "street" must occur once, and only once
inside the "address" element.
Cont;
Declaring Minimum One Occurrence of an Element
<!ELEMENT element-name (child-name+)>
Example:
<!ELEMENT address (street+)>
The + sign in the example above declares that the child
element "street" must occur one or more times inside the
"address" element.
Cont;
Declaring Zero or More Occurrences of an
Element
<!ELEMENT element-name (child-name*)>
Example:
<!ELEMENT address (street*)>
The * sign in the example above declares that

the child element "street" can occur zero or more
times inside the "address" element.
Cont;
Declaring Zero or One Occurrences of an
Element
<!ELEMENT element-name (child-name?)>
Example:
<!ELEMENT address (street?)>
The ? sign in the example above declares that

the child element "street" can occur zero or one
time inside the "address" element.
Cont;
Declaring either/or Content
Example:
<!ELEMENT note (to,from,header,(message|body))>
The example above declares that the "note"

element must contain a "to" element, a "from"
element, a "header" element, and either a
"message" or a "body" element.
Cont;
Declaring Mixed Content
Example:
<!ELEMENT note
(#PCDATA|to|from|header|message)*>
The example above declares that the "note"

element can contain zero or more occurrences
of parsed character data, "to", "from", "header",
or "message" elements.
DTD - Attributes
Declaring Attributes
An attribute declaration has the following syntax:
<!ATTLIST element-name attribute-name attribute-type
default-value>
DTD example:
<!ATTLIST payment type CDATA "check">
XML example:
<payment type="check" />
Cont;
Some of the attribute-types which can be used are
following:
Type
Description
CDATA
The value is character data
(en1|en2|..)
ID
The value must be one from an

enumerated list
The value is a unique id
ENTITY
The value is an entity
xml:
The value is a predefined xml value
Cont;
The default-value can be one of the following:
Value
Explanation
value
The default value of the attribute
#REQUIRED
The attribute is required
#IMPLIED
The attribute is not required
#FIXED value
The attribute value is fixed
Cont;
A Default Attribute Value
DTD:
<!ELEMENT square EMPTY>
<!ATTLIST square width CDATA "0">
Valid XML:
<square width="100" />
In the example above, the "square" element is

defined to be an empty element with a "width"
attribute of type CDATA. If no width is specified,
it has a default value of 0.
Cont;
#REQUIRED
Syntax
#REQUIRED>
Example
DTD:
<!ATTLIST person number CDATA #REQUIRED>
Valid XML:
<person number="5677" />
Invalid XML:
<person />
Cont;
Use the #REQUIRED keyword if you don't have an
option for a default value, but still want to force the
attribute to be present.
Cont;
#IMPLIED
Syntax
#IMPLIED>
Example
DTD:
<!ATTLIST contact fax CDATA #IMPLIED>
Valid XML:
<contact fax="555-667788" />
Valid XML:
<contact />
Use the #IMPLIED keyword if you don't want to force the
author to include an attribute, and you don't have an
option for a default value.
Cont;
#FIXED
Syntax
#FIXED "value">
Example
DTD:
<!ATTLIST sender company CDATA #FIXED
"Microsoft">
Valid XML:
<sender company="Microsoft" />
Invalid XML:
<sender company="W3Schools" />
Use the #FIXED keyword when you want an attribute to
have a fixed value without allowing the author to change
it. If an author includes another value, the XML parser
will return an error.
Cont;
Enumerated Attribute Values
Syntax
<!ATTLIST element-name attribute-name (en1|en2|..)
default-value>Example
DTD:
<!ATTLIST payment type (check|cash) "cash">
XML example:
<payment type="check" />
or
<payment type="cash" />
Use enumerated attribute values when you want the
attribute value to be one of a fixed set of legal values.
DTD - Examples
TV Schedule DTD
<!DOCTYPE TVSCHEDULE [
<!ELEMENT TVSCHEDULE (CHANNEL+)>
<!ELEMENT CHANNEL (BANNER,DAY+)>
<!ELEMENT BANNER (#PCDATA)>
<!ELEMENT DAY (DATE,(HOLIDAY|PROGRAMSLOT+)+)>
<!ELEMENT HOLIDAY (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT PROGRAMSLOT
(TIME,TITLE,DESCRIPTION?)>
<!ELEMENT TIME (#PCDATA)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT DESCRIPTION (#PCDATA)>
<!ATTLIST TVSCHEDULE NAME CDATA #REQUIRED>
<!ATTLIST CHANNEL CHAN CDATA #REQUIRED>
<!ATTLIST PROGRAMSLOT VTR CDATA #IMPLIED>
<!ATTLIST TITLE RATING CDATA #IMPLIED>
<!ATTLIST TITLE LANGUAGE CDATA #IMPLIED>
]>
Newspaper Article DTD
Cont;
<!DOCTYPE NEWSPAPER [
<!ELEMENT NEWSPAPER (ARTICLE+)>
<!ELEMENT ARTICLE
(HEADLINE,BYLINE,LEAD,BODY,NOTES)>
<!ELEMENT HEADLINE (#PCDATA)>
<!ELEMENT BYLINE (#PCDATA)>
<!ELEMENT LEAD (#PCDATA)>
<!ELEMENT BODY (#PCDATA)>
<!ELEMENT NOTES (#PCDATA)>
<!ATTLIST ARTICLE AUTHOR CDATA #REQUIRED>
<!ATTLIST ARTICLE EDITOR CDATA #IMPLIED>
<!ATTLIST ARTICLE DATE CDATA #IMPLIED>
<!ATTLIST ARTICLE EDITION CDATA #IMPLIED>
<!ENTITY NEWSPAPER "Vervet Logic Times">
<!ENTITY PUBLISHER "Vervet Logic Press">
<!ENTITY COPYRIGHT "Copyright 1998 Vervet Logic
Press">
]>
Cont;
Product Catalog DTD
<!DOCTYPE CATALOG [
<!ENTITY AUTHOR "John Doe">
<!ENTITY COMPANY "JD Power Tools, Inc.">
<!ENTITY EMAIL "jd@jd-tools.com">
<!ELEMENT CATALOG (PRODUCT+)>
<!ELEMENT PRODUCT
(SPECIFICATIONS+,OPTIONS?,PRICE+,NOTES?)>
<!ATTLIST PRODUCT
NAME CDATA #IMPLIED
CATEGORY (HandTool|Table|Shop-Professional) "HandTool"
PARTNUM CDATA #IMPLIED
PLANT (Pittsburgh|Milwaukee|Chicago) "Chicago"
INVENTORY (InStock|Backordered|Discontinued) "InStock">
cont;
Cont;
Product Catalog DTD cont;
cont;
<!ELEMENT SPECIFICATIONS (#PCDATA)>
<!ATTLIST SPECIFICATIONS
WEIGHT CDATA #IMPLIED
POWER CDATA #IMPLIED>
<!ELEMENT OPTIONS (#PCDATA)>
<!ATTLIST OPTIONS
FINISH (Metal|Polished|Matte) "Matte"
ADAPTER (Included|Optional|NotApplicable) "Included"
CASE (HardShell|Soft|NotApplicable) "HardShell">
<!ELEMENT PRICE (#PCDATA)>
<!ATTLIST PRICE
MSRP CDATA #IMPLIED
WHOLESALE CDATA #IMPLIED
STREET CDATA #IMPLIED
SHIPPING CDATA #IMPLIED>
<!ELEMENT NOTES (#PCDATA)>
]>
Section 3 - Part 2b
XML Fundamentals
3.1.2. DTDs and Schemas
Part 2
Basics of creating XML

Schemas (XSDs)
A Simple XML Document
Look at this simple XML document called address.xml":
<address>
<name>nimal</name>
<no>24</no>
</address >
Cont;
A DTD File
The following example is a DTD file called address.dtd"
that defines the elements of the XML document above
(address.xml"):
The first line defines the address element to have five
child elements: "name,no,street,city,country ".
Line 2-6 defines the name, no, street, city, country
elements to be of type "#PCDATA".
Cont;
An XML Schema
The following example is an XML Schema file called
address.xsd" that defines the elements of the XML document
above (address.xml"):
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.abc.com"
xmlns="http://www.abc.com"
elementFormDefault="qualified">
<xs:element name=address">
<xs:complexType>
<xs:sequence>
<xs:element name=name" type="xs:string"/>
<xs:element name=no" type="xs:string"/>
<xs:element name=street" type="xs:string"/>
<xs:element name=city" type="xs:string"/>
<xs:element name=country" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Cont;
The address element is a complex type
because it contains other elements.
The other elements (name, no, street, city,
country) are simple types because they do
not contain other elements.
You will learn more about simple and
complex types in the following notes.
Cont;
A Reference to a DTD
This XML document has a reference to a DTD:
<!DOCTYPE address SYSTEM
"http://www.abc.com/dtd/address.dtd">
<address>
<name>nimal</name>
<no>24</no>
</address >
Cont;
A Reference to an XML Schema
This XML document has a reference to an XML Schema:
<address
xmlns="http://www.abc.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xsi:schemaLocation="http://www.abc.com/note.xsd">
<name>nimal</name>
<no>24</no>
</address >
The End.
Section 3 Part 3a
XML Fundamentals
3.1.3. Namespaces and RDF
WHY do we need namespaces?

There are really two fundamental needs for
namespaces:
To disambiguate between two elements that happen
to share the name
To group elements relating to a common idea
together
The XML namespaces recommendation defines a way to
distinguish between duplicate element types and
attribute names.
Cont;
An XML namespace is a collection of element type and
attribute names.
The namespace is identified by a unique name, which is
a URI reference.
Thus, any element type or attribute name in an XML
namespace can be uniquely identified by a two-part
name: the name of its XML namespace and its local
name.
This two-part naming system is the only thing
defined by the XML namespaces recommendation.
Cont;
In the data model implied by XML, an XML document
contains a tree of elements.
Each element has an element type name (sometimes
called the tag name) and a set of attributes; each
attribute consists of a name and a value.
Applications typically make use of the element type
name and attributes of an element in determining how to
process the element.
In XML 1.0 without namespaces, element type names
and attribute names are unstructured strings using a
restricted set of characters, similar to identifiers in
programming languages.
Cont;
We call these names local names.
This is problematic in a distributed environment like the
Web.
One XML document may use part elements to describe
parts of books, another may use part elements to
describe parts of cars.
An XML application has no way of knowing how to
process a part element unless it has some additional
information external to the document.
Cont;
The XML Namespaces Recommendation tries to
improve this situation by extending the data model to
allow element type names and attribute names to be
qualified with a URI.
Thus a document that describes parts of cars can use
part qualified by one URI; and a document that
describes parts of books can use part qualified by
another URI.
We will call the combination of a local name and a
qualifying URI a universal name.
The role of the URI in a universal name is purely to allow
applications to recognize the name.
Cont;
There are no guarantees about the resource identified by
the URI.
The XML Namespaces Recommendation does not
require element type names and attribute names to be
universal names; they are also allowed to be local
names.
The purpose of namespaces is to eliminate name
conflicts between elements and attributes.
Cont;
To better understand how this type of name clash might
occur in your own XML documents, consider an XML
document that contains information about a video and
music collection.
You might use a custom markup language unique to
each type of information (video and music), which means
that each language would have its own elements and
attributes.
However, you are using both languages within the
context of a single XML document, which is where the
potential for problems arises.
Cont;
If both markup languages include an element
named title that represents the title of a video or
music compilation, there is no way for an XML
application to know which language you
intended to use for the element.
The solution to this problem is to assign a
namespace to each of the markup languages,
which will then provide a clear distinction
between the elements and attributes of each
language when they are used.
Cont;
In order to fully understand namespaces, you need a
solid grasp on the concept of scope in XML documents.
The scope of an element or attribute in a document
refers to the relative location of the element or attribute
within the document.
If you visualize the elements in a document as an
upside-down tree that begins at the top with the root
element, child elements of the root element appear just
below the root element as branches.
Cont;
Each element in a "document tree" is known as a node.
Nodes are very important when it comes to processing
XML documents because they determine the relationship
between parent and child elements.
The scope of an element refers to its location within this
hierarchical tree of elements.
So, when we refer to the scope of an element or
attribute, we are talking about the node in which the
element or attribute is stored.
Cont;
Scope is important to namespaces because it's possible
to use a namespace within a given scope, which means
it affects only elements and attributes beneath a
particular node.
Contrast this with a namespace that has global scope,
which means the namespace applies to the entire
document.
Any guess as to how you might establish a global
namespace? It's easy you just associate it with the root
element, which by definition houses the remainder of the
document.
Cont;
The whole point of namespaces is that they provide a
means of establishing unique identifiers for elements and
attributes.
It is therefore imperative that each and every namespace
have a unique name.
Obviously, there would be no way to enforce this rule if
everyone was allowed to make up their own names out
of thin air, so a clever naming scheme was established
that tied namespaces to URIs (Uniform Resource
Identifiers).
Cont;
URIs usually reference physical resources on the
Internet and are guaranteed to be unique.
So, a namespace is essentially the name of a URI.
For example, if your web site is located at
http://www.abc.com, to help guarantee name uniqueness
in any XML documents that you create, you could
associate the documents with your namespace:
<mediacollection xmlns:mov="http://www.abc.com/ns/movies">
Cont;
XML namespaces are declared with an xmlns attribute,
which can associate a prefix with the namespace.
The declaration is in scope for the element containing
the attribute and all its descendants.
For example:

<A xmlns:foo="http://www.foo.org/"
xmlns="http://www.bar.org/">
<B>abcd</B>
</A>
Cont;
If an XML namespace declaration contains a prefix, you
refer to element type and attribute names in that
namespace with the prefix.
For example:

<foo:A xmlns:foo="http://www.foo.org/">
<foo:B>abcd</foo:B>
</foo:A>
Cont;
If an XML namespace declaration does not contain a
prefix, the namespace is the default XML namespace
and you refer to element type names in that namespace
without a prefix.
For example:

<A xmlns="http://www.foo.org/">
<B>abcd</B>
</A>
XML namespaces were originally designed to provide
universally unique names for elements and attributes.
Cont;
As an example of why XML namespaces are needed,
consider the following two XML documents:
<?xml version="1.0" ?>
<Address>
<Street>Wilhelminenstr. 7</Street>
<City>Darmstadt</City>
<State>Hessen</State>
<Country>Germany</Country>
<PostalCode>D-64285</PostalCode>
</Address>
and:
<Server>
<Name>OurWebServer</Name>
<Address>123.45.67.8</Address>
</Server>
Cont;
Each document uses a different XML language and each
language defines an Address element type.
Each of these Address element types is different -- that
is, each has a different content model, a different
meaning, and is interpreted by an application in a
different way.
This is not a problem as long as these element types
exist only in separate documents.
But what if we want to use them in the same document,
such as a list of departments, their addresses, and their
Web servers? How does an application know which
Address element type it is processing?
Cont;
One solution is to simply rename one of the Address
element types -- for example, we could rename the
second element type IPAddress.
However, this is not a useful long term solution.
One of the hopes of XML is that people will standardize
XML languages for various subject areas and write
modular code to process those languages.
Cont;
By reusing existing languages and code, people can
quickly define new languages and write applications that
process them.
If we rename the second Address element type to
IPAddress, we will break any code that expects the old
name.
Cont;
A better answer is to assign each language (including its
Address element type) to a different namespace.
This allows us to continue using the Address name in
each language, but to distinguish between the two
different element types.
The mechanism by which we do this is XML
namespaces.
For example, the following document uses XML
namespaces to distinguish between the two different
element types named Address.
Cont;
<Department>
<Name>DVS1</Name>
<addr:Address
xmlns:addr="http://www.abc.com/ito/addresses">
<addr:Street>Wilhelminenstr. 7</addr:Street>
<addr:City>Darmstadt</addr:City>
<addr:State>Hessen</addr:State>
<addr:Country>Germany</addr:Country>
<addr:PostalCode>D-64285</addr:PostalCode>
</addr:Address>
<serv:Server xmlns:serv="http://www.abc.com/ito/servers">
<serv:Name>OurWebServer</serv:Name>
<serv:Address>123.45.67.8</serv:Address>
</serv:Server>
</Department>
Cont;
The first Address element type name belongs to the
http://www.abc.com/ito/addresses XML namespace.
It has an expanded (two-part) name of
"http://www.abc.com/ito/addresses" plus "Address". (We
can think this as
{http://www.abc.com/ito/addresses}Address.)
The second Address element type name belongs to the
http://www.abc.com/ito/servers XML namespace and it
can be thought as having an expanded name of
{http://www.abc.com/ito/servers}Address.
Thus, each expanded name is unique, meeting the
requirement that each element type in an XML document
have a unique name.
Section 3 - Part 3b
XML Fundamentals
3.1.4. Introduction to XPath,
XPointer, XLink
XPath, XPointer, XLink

The idea here is to have hypertext links for XML.
XPath, XPointer, and XLink. XLink proper provides
linking mechanisms: facilities for asserting
multidirectional (as well as unidirectional) link
relationships between resources, for annotating links, for
out-of-line links, and extended link sets.
Xpath, used by XSLT and XPointer, supports
specification of locations in XML documents in terms of
nodes and node lists.
XPointer builds upon XPath to support specification of
locations for the "internal structures" of XML documents
such as character strings and selections.
XPath, XPointer, XLink

XLink (XML Linking Language) "specifies
constructs that may be inserted into XML
resources to describe links between objects.
It uses XML syntax to create structures that can
describe the simple unidirectional hyperlinks of
today's HTML as well as more sophisticated
multi-ended and typed links."
Cont;
XPointer (XML Pointer Language) "specifies a language
that builds upon the XML Path Language (XPath), to
support addressing into the internal structures of XML
documents.
In particular, it provides for specific reference to
elements, character strings, selections, and other parts
of XML documents, whether or not they bear an explicit
ID attribute, using traversals of a document's structure
and choice of parts based on their properties such as
element types, attribute values, character content, and
relative position, containment, and order.
Cont;
XPointer defines the meaning of the 'selector' or
'fragment identifier' portion of URIs that locate resources
of MIME media types 'text/xml' and 'application/xml'."
Cont;
XPath (XML Path Language) "is a language for
addressing parts of an XML document, designed to be
used by both XSLT and XPointer.
XPath is the result of an effort to provide a common
syntax and semantics for functionality shared between
XSL Transformations and XPointer.
The primary purpose of XPath is to address parts of an
XML document.
In support of this primary purpose, it also provides basic
facilities for manipulation of strings, numbers and
booleans.
Cont;
XPath uses a compact, non-XML syntax to facilitate use
of XPath within URIs and XML attribute values.
XPath operates on the abstract, logical structure of an
XML document, rather than its surface syntax; it models
an XML document as a tree of nodes.
XPath gets its name from its use of a path notation as in
URLs for navigating through the hierarchical structure of
an XML document."
Cont;
XLink defines a standard way of creating hyperlinks in
XML documents.
XPointer allows the hyperlinks to point to more specific
parts (fragments) in the XML document.
The XML tree model

XPath is a language to address a set of
nodes in an XML document.
To understand how XPath works, an
understanding of the tree structure of XML
documents is necessary.
This section will give a short introduction
on how an XML document is structured.
Cont;
An XML tree
A typical XML document looks like this:
<bookshelf>
<book id="1">
<title lang="en">Beautiful code</title>
<author>A. Oram</author>
<author>G. Wilson</author>
<year>2007</year>
<price currency="Euro">35.95</price>
</book>
<book id="2">
<title lang="de">
eZ Components - Das
Entwicklerhandbuch</title>
<author>T. Schlitt</author>
<author>K. Nordmann</author>
<year>2007</year>
<price currency="Euro">39.95</price>
</book>
</bookshelf>
Cont;
This document consists of several
Items
Nodes
Elements
Attributes
Atomic values
Visualized in a tree, the document looks

like this below:
Cont;
Cont;
The chart shown above visualizes the tree structure of
the XML document.
Element nodes (aka tags) are displayed in blue color,
attribute nodes are orange and atomic values are gray
colored.
The bookshelf tag is the root of the tree, the document
element. It has two child element nodes, which each
contain similar children.
Therefore the second book node is skipped.
Cont;
The displayed book node has two different kinds of child
nodes: One attribute node and 4 element nodes.
The attribute node itself has an atomic value attached as
its value.
The 4 child nodes of the book element are structured the
same way.
Cont;
Node relations
You already got to know the child relation between
nodes and the document element, the root node of each
XML document.
These terms should also be familiar to you from other
tree structures.
Beside those, tree terminology is used when talking
about XML.
parent
All child nodes of an element have this element as
their parent.
Cont;
Sibling
All nodes of the same type, that have a common
parent, node are siblings.
descendants
All children of a node and their children recursively
are collected in the group of a nodes descendants.
This are all nodes that reside below a certain node.
Cont;
ancestors
In contrast to the descendants, the ancestors are all
nodes that reside above the affected node: His parent
and his parents parents recursively.
The root node is an ancestor of every node, except of
itself.
Cont;
To illustrate this a bit more, here are some of the
relations in the example document:
The document element bookshelf has a lot of
descendants:
Two book elements, two id attributes, two title elements,
two lang attributes four author elements and many more.
Some of these are also descendants of the element with
id 1.
Cont;
Cont;
The ancestors of the author element with the value "A.
Oram" are book (the direct parent node) and bookshelf
(the parents parent).
The element title, the two author elements, the year and
price elements are siblings.
The two book elements are siblings, too. The bookshelf
element does not have any siblings, no descendants and
no parent.
The idea behind XPath

The XPath language allows you to query a well-defined
set of nodes from an XML document.
If you write an XPath expression and have it processed
by an XPath interpreter engine, you will always get a set
of XML document items as the result.
Cont;
To illustrate this, here is a short introduction example,
that might be executed on the XML document shown in
the section An XML tree:
/bookshelf/book/title
If you give this expression to a XPath processor together
with the XML document, you will received a set of title
elements, containing the title for each book element in
the bookshelf.
Cont;
The XPath syntax is inspired by the typical way to
address file system nodes (files and directories) on Unix
and Unix-like systems.
The simple expression shown above consists of three
element names, divided by slashes (/).
Each slash creates a new context. Subsequent
expression parts operate on this context. A context may
consist of a single element, multiple elements or no
elements.
What is XLink?
XLink is short for XML Linking Language
XLink is used to create hyperlinks in XML
documents
Any element in an XML document can behave
as a link
XLink supports simple links (like HTML) and
extended links (for linking multiple resources
together)
Cont;
With XLink, the links can be defined
outside the linked files
XLink is a W3C Recommendation .
What is XPointer?
XPointer is short for XML Pointer Language
XPointer allows the links to point to specific parts of an
XML document
XPointer uses XPath expressions to navigate in the XML
document
XPointer is a W3C Recommendation
XLink Syntax
In HTML, we know (and all the browsers know!) that the
<a> element defines hyperlink.
However, this is not how it work with XML.
In XML documents, you can use whatever element name
you want - therefore it is impossible for browsers to
predict what hyperlink elements will be called in XML
documents.
The solution for creating links in XML document was to
put a marker on elements that should act as hyperlinks.
Cont;
Below is a simple example of how to use XLink to create link
in an XML documents:
<homepages xmlns:xlink="http://www.w3.org/1999/xlink">
<homepage xlink:type="simple"
xlink:href="http://www.abc.com">Visit Abc</homepage>
<homepage xlink:type="simple"
xlink:href="http://www.w3.org">Visit W3C</homepage>
</homepages>
Cont;
To get access to the XLink attribute and features we
must declare the XLink namespace at the top of the
document.
The XLink namespace is the :
"http://www.w3.org/1999/xlink".
The xlink:type and the xlink:href attributes in the
<homepage> element define that the type and href
attributes come from the xlink namespace.
The xlink:type="simple" create a simple, two-ended link
(means "click from here to go there"). We will look at
multi-ended links later.
XPointer Syntax
In HTML, we can create hyperlinks that either point to an
HTML page or to a bookmark inside an HTML page
(using #).
Sometimes it is more useful to point to more specific
contents.
For example, let's say that we want to link to the third
item in the particular list, or to the second sentence of
the fifth paragraph.
This is the easy one with XPointer.
Cont;
If the hyperlink points to an XML documents, we
can add an XPointer part after the URL in the
xlink:href attribute, to navigate (with an XPath
expression) to a specific place in the documents.
For example, in the example below we use
XPointer to point to the fifth item in the list with a
unique id of "rock":
href="http://www.abc.com/cdlist.xml#id('rock').child(5,i
tem)"
XLink Example
<?xml version="1.0" encoding="ISO-8859-1"?>
<bookstore xmlns:xlink="http://www.w3.org/1999/xlink">
<book title="Harry Potter">
<description
xlink:type="simple"
xlink:href="http://book.com/images/HPotter.gif"
xlink:show="new">
As his fifth year at Hogwarts School of Witchcraft and
Wizardry approaches, 15-year-old Harry Potter is.......
</description>
</book>
<book title="XQuery Kick Start">
<description
xlink:type="simple"
xlink:href="http://book.com/images/XQuery.gif"
xlink:show="new">
XQuery Kick Start delivers a concise introduction
to the XQuery standard.......
</description>
</book>
</bookstore>
Cont;
In the above example the XLink namespace is declared
at the top of the document
(xmlns:xlink="http://www.w3.org/1999/xlink").
This means that the documents has access to the XLink
attributes and features.
The xlink:type="simple" create a simple "HTML-like" link.
Cont;
You can also specify more complex links , but for now,
we will only use simple links.
The xlink:href attribute specify the URL to link to, and the
xlink:show attribute specifies where to open the link.
xlink:show="new" means that the link (in this case, an
image) should open in a new window.
XPointer
Example
In this example, we will show you tht how to use XPointer in
conjunction with XLink to point to a specific part of another
document.
The Target XML Document

<dogbreeds>
<dog breed="Rottweiler" id="Rottweiler">
<picture url="http://dog.com/rottweiler.gif" />
<history>
The Rottweiler's ancestors were probably Roman
drover dogs.....
</history>
<temperament>
Confident, bold, alert and imposing, the Rottweiler
is a popular choice for its ability to protect....
</temperament>
</dog>
cont
Cont;
Cont
<dog breed="FCRetriever" id="FCRetriever">
<picture url="http://dog.com/fcretriever.gif" />
<history>
One of the earliest uses of retrieving dogs was to
help fishermen retrieve fish from the water....
</history>
<temperament>
The flat-coated retriever is a sweet, exuberant,
lively dog that loves to play and retrieve...
</temperament>
</dog>
</dogbreeds>
Note that the XML document above uses id as attributes on
each element we may want to link to!
Cont;
The Linking XML Document
Instead of linking to the entire document (as with XLink),
XPointer allows you to link to specific part of the
document.
To link to a specific part of a page, add a number sign
(#) and an XPointer expression after the URL in the
xlink:href attribute.
The expression: #xpointer(id("Rottweiler")) refer to the
element in the target document, with the id value of
"Rottweiler".
Cont;
The Linking XML Document cont;
So the xlink:href attribute would looks like this:
xlink:href="http://dog.com/dogbreeds.xml#xpointer(i
d('Rottweiler'))"
However, XPointer allows a shorthand form when linking
to an element with the id.
You can also use the value of the id directly, like this:
xlink:href="http://dog.com/dogbreeds.xml#Rottweiler
"
Cont;
The following XML document refer to information of the dog breed for
each of my dogs :-), all through XLink and XPointer references:
The Linking XML Document
<mydogs xmlns:xlink="http://www.w3.org/1999/xlink">
<mydog xlink:type="simple"
xlink:href="http://dog.com/dogbreeds.xml#Rottweiler">
<description xlink:type="simple"
xlink:href="http://myweb.com/mydogs/anton.gif">
Anton is my favorite dog. He has won a lot of.....
</description>
</mydog>
<mydog xlink:type="simple"
xlink:href="http://dog.com/dogbreeds.xml#FCRetriever">
<description xlink:type="simple"
xlink:href="http://myweb.com/mydogs/pluto.gif">
Pluto is the sweetest dog on earth......
</description>
</mydog>
</mydogs>
Section 3 - Part 3c
XML Fundamentals
3.4. XQuery
XQuery
The End.
Section 4 Part 1
Processing XML Documents
4.1. Handling SAX with PHP
What is parsing and how do I

do it in XML?
Parsing is the act of splitting up information into its
component parts.
In computing, a parser is a program (or a piece of code
or API that you can reference inside your own programs)
which analyses files to identify the component parts.
All applications that read input have a parser of some
kind, otherwise they'd never be able to figure out what
the information means.
Cont.
As the component parts of the program are identified, a
validating parser can compare them with the pattern laid
down by a DTD or a Schema, to check that they
conform.
XML applications are just the same: they contain a
parser which reads XML and identifies the function of
each the pieces of the document, and it then makes that
information available in memory to the rest of the
program.
While reading an XML file, a parser checks the syntax
(pointy brackets, matching quotes, etc) for wellformedness, and reports any violations (reportable
errors).
Cont.
Validation is another stage beyond parsing
As the component parts of the program are identified, a
validating parser can compare them with the pattern laid
down by a DTD or a Schema, to check that they
conform.
In the process, default values and datatypes (if specified)
can be added to the in-memory result of the validation
that the validating parser gives to the application.
Cont.
Let us look at a example.
<person corpid="abc123"
birth="1960-02-31"
gender="female">
<name>
<forename>Judy</forename>
<surname>O'Grady</surname>
</name>
</person>
Cont.
The example above parses as:

Element person identified with Attribute corpid
containing abc123 and Attribute birth containing
1960-02-31 and Attribute gender containing female
containing ...
Element name containing ...
Element forename containing text Judy followed by
...
Cont.
Cont;
Element surname containing text O'Grady
(and lots of other stuff too).
Cont.
As well as built-in parsers, there are also stand-alone
parser-validators, which read an XML file and tell you if
they find an error (like missing angle-brackets or quotes,
or misplaced markup).
This is essential for testing files in isolation before doing
something else with them, especially if they have been
created by hand without an XML editor, or by an API
which may be too deeply embedded elsewhere to allow
easy testing.
Up to now we have discussed PHP and XML separately.
Now let us look into the need of combining the two as
well
Cont.
Some of the applications that arise as a result of this
combination are
Data processing.
PHP's XML functions make it possible to parse
XML data and carry out commands based on the
type of data encountered.
With some clever coding, this can be used to
easily convert XML-encoded data into browsercompliant HTML output.You also can use PHP's
XML functions to create a database from an XML
document, or vice versa.
Cont.
Cont;
Data transformation.
PHP's XSLT extension brings the full power of
XSLT processing to the language, making it
possible to apply XSLT stylesheets to XML data.
With support for a wide range of XSLT processing
instructions, transforming data from one format to
another becomes very simple.
Cont.
Cont;
Platform-independent information exchange.
PHP's WDDX functions make it possible to easily
transfer information (including typed data like
arrays) from one system to another using platformneutral data structures.
This capability is particularly useful for content
publishers who need to disburse information to
requesting clients on a periodic basis, yet have no
control over the platform and operating
environment of those clientsfor example, news
syndication services or stock market tickers.
Cont.
Cont;
Platform-independent information exchange cont...
Because WDDX structures are platform-neutral,
the PHP/WDDX combination encourages
interoperability by making it possible to exchange
data between programming languages in a simple
and elegant manner.
Cont.
Remote process execution.
Support for XML-RPC implies that PHP scripts can
trigger processes on remote servers by sending
them messages encoded in XML.
This makes it possible to access different web
services directly from your PHP script using
standard client-server protocols and create new
types of web applications based on these services.
Cont.
Remote process execution cont...
These processes/scripts might be written in other
languages (such as Java, Python, Perl, and so on),
again demonstrating how the XML/PHP
combination can encourage greater interoperability
between platforms and languages.
Cont.
Clearly, PHP and XML are each powerful and flexible
tools
Given the current state of the web, however, with
browser support still evolving and many ancillary
technologies yet to mature, you will need to use them
together to gain the true measure of their capabilities
As you gain experience, though, you'll find yourself
wondering if there shouldn't be more to this in XML than
just tags and theory
Cont.
Well, you're right to wonder, and you're right in thinking
that there's more here than meets the eye.
Marking up data in XML is only the first step; the true
value of the language becomes visible only when you try
to do something useful with all that marked-up data.
Because XML makes it possible for applications to easily
recognize and operate on disparate pieces of data, it
allows developers to do some complex things in very
simple wayswhich, when you get down to it, is what
good programming is all about.
Cont.
In applications it is needed to parsing and
formatting marked-up documents for
greater readability and better presentation.
Here this could be done using the Simple
API for XML (SAX), implemented via PHP,
or by Document Object Model (DOM)
implemented via PHP.
Cont.
There are two basic approaches to parsing an XML
document:
The event-based approach.
Under this approach, an XML parser reads an XML
document one chunk at a time, processing each
tag as it finds it in the document.
Each time the parser encounters an XML construct
(an element start tag, a CDATA block, or a PI), it
generates an event that can be intercepted and
processed by the application layer.
A Simple API for XML (SAX) parser uses this
event-based approach to parsing an XML
document.
Cont.
There are two basic approaches to parsing an XML
document:
The tree-based approach (DOM).
Here, an XML parser reads the entire document
into memory at one time, and creates a
hierarchical tree representation of it in memory.
The parser also exposes a number of traversal
methods, which developers can use to navigate
between, and process, individual tree nodes.
A Document Object Model (DOM) parser uses this
tree-based approach to parsing an XML document.
Cont.
An event-based parser such XML Parser is preferable
for large files, because tree-based parsers must fully
load the file into memory in order to parse the XML.
Event-based parsers do not need to load the entire file
into memory to begin parsing.
PHP contains SAX and DOM parser libraries
PHP provides two main APIs for processing XML: the
SAX and DOM interfaces.
Cont.
Each has its own advantages and disadvantages in
particular situations.
The DOM is the preferred method to use when the XML
document must be modified in place or when you need
to keep the document around in memory to do more
advanced processing of the XML data, but is more
complicated to use than the SAX method.
The SAX API is better when you only need to run
through the XML file once and process each XML tag
individually, but does not provide a way to edit the
contents of the document.
If u only needed to run through the document once and
output the results, SAX is the way to go.
How SAX Works.

The SAX model of XML processing works by
sequentially running through the entire XML file from
beginning to end and calling event handler functions for
each type of element that is encountered in the XML file.
Your code tells the SAX parser what types of XML
elements it is interested in, such as tags, character data,
entities, etc., and then defines functions that will be
called when the parser encounters that type of element
in the XML file.
You then register these functions with the XML parser,
and give it some XML to parse.
Cont;
While simple, some of the major
downsides of this method should be
readily apparent.
First, you can't re-visit a part of the XML
file that has already been processed. If
you need to go back again, you have to
start the processing all over from the
beginning.
Cont.
Second, you can't modify the XML document that is
being processed.
Third, the SAX parser doesn't keep track of context for
you.
For example, you can't ask the parser whether the tag
you're about to process is inside of another tag,
or whether some other tag has already been
processed
Cont.
That information is long gone by the time your handler
gets called, so if you need to keep track of things like
that, you have to do it yourself.
Still, the SAX method is highly efficient when all you
need to do is examine the contents of the XML file and
things like order of processing aren't very important.
Cont.
Cont.
Cont.
Cont.
Handling SAX with PHP

PHP uses the Expat XML parser as its SAX library.
Expat XML parser is created by James Clark, the expat
library is a fast, robust SAX implementation that provides
XML parsing capabilities.
Expat is an event-based parser, it views an XML
document as a series of events.
When an event occurs, it calls a specified function to
handle it.
Cont;
Expat is a non-validating parser, and ignores any DTDs
linked to a document.
However, if the document is not well formed it will end
with an error message.
Because it is an event-based, non validating parser,
Expat is fast and well suited for web applications.
Cont;
The XML parser functions lets you create XML parsers
and define handlers for XML events.
The Expat parser is an event-based parser.
Event-based parsers focus on the content of the XML
documents, not their structure.
Because of this, event-based parsers can access data
faster than tree-based parsers.
Cont;
Look at the following XML fraction:
<address>Colombo</address>
An event-based parser reports the XML above as a
series of three events:
Start element: address
Start CDATA section, value: Colombo
Close element: address
The XML example above contains well-formed XML
Cont;
However, the example is not valid XML, because there is
no Document Type Definition (DTD) associated with it.
However, this makes no difference when using the Expat
parser. Expat is a non-validating parser, and ignores any
DTDs.
As an event-based, non-validating XML parser, Expat is
fast and small, and a perfect match for PHP web
applications.
Note: XML documents must be well-formed or Expat will
generate an error.
Cont;
Installation of the parser
The XML functions are part of the PHP core. There is
no installation needed to use these functions.
An Example
The XML file below address.xml will be used in our
example:
<Address>
<no>24</no>
<street>2nd Lane</ street >
<town>Dehiwala</ town >
<country>Sri Lanka</ country >
</ Address >
Using the XML Parser

We want to initialize the XML parser in PHP, define
some handlers for different XML events, and then parse
the XML file.
Example 1
<?php
//Initialize the XML parser
$parser=xml_parser_create();
//Function to use at the start of an element
function start($parser,$element_name,$element_attrs)
{
switch($element_name)
{
case "ADDRESS":
echo "-- Address --<br />";
break;
case "NO":
echo "No: ";
break;
case "STREET":
echo "Street: ";
break;
case "TOWN":
echo "Town: ";
break;
case "COUNTRY":
echo "Country: ";
}
Cont;
}
//Function to use at the end of an element
function stop($parser,$element_name)
{
echo "<br />";
}
Cont;
//Function to use when finding character data
function char($parser,$data)
{
echo $data;
}
//Specify element handler
xml_set_element_handler($parser,"start","stop");
//Specify data handler
xml_set_character_data_handler($parser,"char");
Cont;
//Open XML file
$fp=fopen("address.xml","r");
//Read data
while ($data=fread($fp,4096))
{
xml_parse($parser,$data,feof($fp)) or
die (sprintf("XML Error: %s at line %d",
xml_error_string(xml_get_error_code($parser)),
xml_get_current_line_number($parser)));
}
Cont;
//Free the XML parser
xml_parser_free($parser);
?>
The output of the code above will be:
-- Address -No: 24
Street: 2nd Lane
Town: Dehiwala
Country: Sri Lanka
Cont;
Lets see how the above example works:
1. Initialize the XML parser with the xml_parser_create()
function
2. Create functions to use with the different event
handlers
3. Add the xml_set_element_handler() function to
specify which function will be executed when the
parser encounters the opening and closing tags
Cont;
4. Add the xml_set_character_data_handler() function
to specify which function will execute when the
parser encounters character data
5. Parse the file " address.xml" with the xml_parse()
function
6. In case of an error, add xml_error_string() function
to convert an XML error to a textual description
Cont;
7. Call the xml_parser_free() function to
release the memory allocated with the
xml_parser_create() function
Some of the PHP SAX XML

Parser Functions
xml_error_string()
Gets an error string from the XML parser
xml_parse()
Parses an XML document
xml_parser_create()
Create an XML parser
xml_parser_free()
Free an XML parser
Cont;
xml_set_character_data_handler()
Set handler function for character data
xml_set_default_handler()
Set default handler function
xml_set_element_handler()
Set handler function for start and end element
of elements
Cont;
Example 2 Simple XML Document (kamal.xml)
<my_paragraph>My son <student
id="A001">kamal</student> obtained good results for
<subject semester="two">maths</subject> and got
eligible to enter to the next year.</my_paragraph>
Now, if a SAX parser processed this document, it would
generate an event trail that would look something like
this:
[tag opened] my_paragraph
[cdata] My son
[tag opened] student
[attribute name] id
[attribute value] A001
Cont;
[cdata] kamal
[tag closed] student
[cdata] obtained good results for
[tag opened] subject
[attribute name] semester
[attribute value] two
[cdata] maths
[tag closed] subject
[cdata] and got eligible to enter to the next year.
[tag closed] my_paragraph
Cont;
Under the SAX approach, the parser has a very clear
and defined role.
Its function is merely to parse the XML data that's being
fed to it and to call appropriate functions (also referred to
as "handlers" or "callback functions") at the application
layer to handle the different types of constructs it
encounters.
It's up to the developer to write the code necessary to
handle each event, depending on the application
requirements; the SAX parser itself is completely
insulated from the internals of each handler function.
The End.
Section 4 Part 2
Processing XML Documents
4.2. Handling DOM with PHP
What is the Document Object

Model (DOM)?
The foundation of Extensible Markup Language, or XML,
is the DOM.
XML documents have a hierarchy of informational units
called nodes; DOM is a way of describing those nodes
and the relationships between them.
Document Object Model: DOM is a platform- and
language-neutral interface, that provides a standard
model of how the objects in an XML object are put
together, and a standard interface for accessing and
manipulating these objects and their inter-relationships.
Cont;
The DOM is an interface that exposes an XML document
as a tree structure comprised of nodes.
The DOM allows you to programmatically navigate the
tree and add, change and delete any of its elements.
The W3C Document Object Model (DOM) is a platform
and language neutral interface that allow programs and
scripts to dynamically access and update the
content,style and structure of a document."
Cont;
The W3C DOM provides a standard set of objects for
representing HTML and XML documents, and a standard
interface for accessing and manipulating them.
The DOM is separated into different parts (Core,XML
and HTML) and also have different levels (DOM Level
1/2/3):
Core DOM - define a standard set of objects for any
structured documents
XML DOM - defines a standard set of objects for XML
documents only.
HTML DOM - define a standard set of objects for
HTML documents only
Cont;
What is the XML DOM?
The XML DOM is the Document Object Model for
XML only.
The XML DOM is language- and platformindependent
The XML DOM define a standard set of objects for
XML
The XML DOM define a standard way to access XML
documents
Cont;
Cont;
The XML DOM define a standard way to manipulate
XML documents
The XML DOM is W3C standard
Cont;
The DOM view XML documents as a tree-structure. All
elements; their containing text and their attributes, can
be accessed through the DOM tree.
Their contents can be deleted or modified, and new
elements can be created.
The elements, their text, and their attributes are all
known as nodes.
The DOM treats the XML document as tree-structure.
Each attribute,element and text in the XML document
represents a node in the tree.
Cont;
Cont;
Cont;
The terms "parent" and "child" are used to describe the
relationships between node.
Some nodes may have child node, while other nodes do
not have children (leaf nodes).
Because the XML data is structured in a tree form, it can
be traversed without knowing the exact structure of tree
and without knowing the type of data contained within
The DOM is a programming API for documents. It is
based on an object structure that closely resembles the
structure of the documents it models.
Cont;
For instance, consider this table, taken from an HTML
document:
<TABLE>
<TBODY>
<TR>
<TD>Shady Grove</TD>
<TD>Aeolian</TD>
</TR>
<TR>
<TD>Over the River, Charlie</TD>
<TD>Dorian</TD>
</TR>
</TBODY>
</TABLE>
Cont;
A graphical representation of the DOM of
the example table is:
Cont;
Before beginning work with the DOM, it pays to have an
idea of what it actually represents.
A DOM Document is a collection of nodes, or pieces of
information, organized in a hierarchy.
This hierarchy allows a developer to navigate around the
tree looking for specific information.
Analyzing the structure normally requires the entire
document to be loaded and the hierarchy to be built
before any work is done.
Cont;
Because it is based on a hierarchy of information, the
DOM is said to be tree-based, or object-based.
For exceptionally large documents, parsing and loading
the entire document can be slow and resource-intensive,
so other means are better for dealing with the data.
These event-based models, such as the Simple API for
XML (SAX), work on a stream of data, processing it as it
goes by.
Cont;
An event-based API eliminates the need to build the data
tree in memory, but doesn't allow a developer to actually
change the data in the original document.
The DOM, on the other hand, also provides an API that
allows a developer to add, edit, move, or remove nodes
at any point on the tree in order to create an application.
A DOM
Working with the DOM involves several concepts that all
fit together.
Cont;
A parser is a software application that is designed to
analyze a document -- in this case an XML file -- and do
something specific with the information.
In an event-based API like SAX, the parser sends events
to a listener of some sort.
In a tree-based API like DOM, the parser builds a data
tree in memory.
Looking at the DOM as an API

Starting with the DOM Level 1, the DOM API contains
interfaces that represent all of the different types of
information that can be found in an XML document, such
as elements and text.
It also includes the methods and properties necessary to
work with these objects.
Level 1 included support for XML 1.0 and HTML, with
each HTML element represented as an interface.
It included methods for adding, editing, moving, and
reading the information contained in nodes, and so on.
Cont;
It did not, however, include support for XML
Namespaces, which provide the ability to segment
information within a document.
Namespace support was added to the DOM Level 2.
Level 2 extends Level 1, allowing developers to detect
and use the namespace information that might be
applicable for a node.
Level 2 also adds several new modules supporting
Cascading Style Sheets, events, and enhanced tree
manipulations.
Cont;
DOM Level 3, currently in Last Call, includes better
support for creating a Document object (previous
versions left this up to the implementation, which made it
difficult to create generic applications), enhanced
Namespace support, and new modules to deal with
loading and saving documents, validation, and XPath,
the means for selecting nodes used in XSL
Transformations and other XML technologies.
The modularization of the DOM means that as a
developer, you must know whether the features you wish
to use are supported by the DOM implementation with
which you are working.
DOM Nodes
According to the DOM, everything in an XML document
is a node.
The DOM says:
The entire document is a document node
Every XML element is an element node
The text in the XML elements are text nodes
Every attribute is an attribute node
Comments are comment nodes
Orders.xml
DOM Example

<!DOCTYPE ORDERS SYSTEM "orders.dtd">
<orders>
<order>
<customerid limit="1000"> 12341
</customerid>
<status>pending</status>
<item instock="Y" itemid="SA15">
<name>
Silver Show Saddle, 16 inch
</name>
<price>825.00</price>
<qty>1</qty>
</item>
Orders.xml cont;
Cont;
<item instock="N" itemid="C49">
<name>
Premium Cinch
</name>
<qty>1</qty>
</item>
</order>
Orders.xml cont;
Cont;
<order>
<customerid limit="150">251222
</customerid>
<item instock="Y" itemid="WB78">
<name>
Winter Blanket (78 inch)
</name>
<price>20</price>
<qty>10</qty>
</item>
</order>
</orders>
Cont;
In the DOM, working with XML information means first
breaking it down into nodes.
The root node in the XML above is named <orders>.
All other nodes in the document are contained within
<orders>.
The root node <orders> holds two <order> nodes.
Cont;
The first <order> node holds four nodes: <customerid>,
<status>, <item>, and <item>. The nodes <customerid>
and <status> contains one text node each, "12341",
"pending".
Cont;
Text is Always Stored in Text Nodes
A common error in DOM processing is to expect an
element node to contain text.
However, the text of an element node is stored in a text
node.
In this example: <status>pending</status>, the
element node <status>, holds a text node with the value
"pending".
"pending" is not the value of the <status> element!
Cont;
Lest take a look at another example
books.xml
<bookstore>
<book category="cooking">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
</book>
<book category="children">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
</book>
Cont;
books.xml cont;
<book category="web">
<title lang="en">XQuery Kick Start</title>
<author>James McGovern</author>
<author>Per Bothner</author>
<author>Kurt Cagle</author>
<author>James Linn</author>
<author>Vaidyanathan Nagarajan</author>
<year>2003</year>
</book>
<book category="web" cover="paperback">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
</book>
</bookstore>
XML DOM Node Tree

The XML DOM views an XML document as a node-tree.
All the nodes in the tree have a relationship to each
other.
The XML DOM views an XML document as a treestructure.
The tree structure is called a node-tree.
All nodes can be accessed through the tree.
XML DOM Node Tree

Their contents can be modified or deleted, and new
elements can be created.
The node tree shows the set of nodes, and the
connections between them.
The tree starts at the root node and branches out to the
text nodes at the lowest level of the tree:
Cont;
Node Parents, Children, and

Siblings
The nodes in the node tree have a hierarchical
relationship to each other.
The terms parent, child, and sibling are used to describe
the relationships.
Parent nodes have children. Children on the same level
are called siblings (brothers or sisters).
In a node tree, the top node is called the root
Every node, except the root, has exactly one parent
node
Cont;
Cont;
A node can have any number of children
A leaf is a node with no children
Siblings are nodes with the same parent
Cont;
The following image illustrates a part of the node tree
and the relationship between the nodes:
Cont;
Because the XML data is structured in a tree form, it can
be traversed without knowing the exact structure of the
tree and without knowing the type of data contained
within.
First Child - Last Child

Look at the following XML fragment:
<orders>
<order>
<customerid limit="1000">12341</customerid>
<item instock="Y" itemid="SA15">
<name>Silver Show Saddle, 16 inch</name>
<qty>1</qty>
</item>
</order>
</orders>
Cont;
In the XML above, the <customerid> element is the first
child of the <order> element, and the <item> element is
the last child of the <order> element.
Furthermore, the <order> element is the parent node of
the <customerid>, <status> and <item> elements.
The End.
Section 5
Web Services
5.1. Web Services Architecture
and Technology Stack
Web Services Architecture

and Technology Stack
Web services is a technology that allows applications to
communicate with each other in a platform- and
programming language-independent manner.
A Web service is a software interface that describes a
collection of operations that can be accessed over the
network through standardized XML messaging.
It uses protocols based on the XML language to describe
an operation to execute or data to exchange with
another Web service XML stands for EXtensible Markup
Language
Cont;
A group of Web services interacting together in this
manner defines a particular Web service application in a
Service-Oriented Architecture (SOA).
The software industry is finally coming to terms with the
fact that integrating software applications across multiple
operating systems, programming languages, and
hardware platforms is not something that can be solved
by any one particular proprietary environment.
Traditionally, the problem has been one of tight-coupling,
where one application that calls a remote network is tied
strongly to it by the function call it makes and the
parameters it requests.
Cont;
In most systems before Web services, this is a fixed
interface with little flexibility or adaptability to changing
environments or needs
Web services uses XML that can describe any and all
data in a truly platform-independent manner for
exchange across systems, thus moving towards looselycoupled applications.
Furthermore, Web services can function on a more
abstract level that can reevaluate, modify or handle data
types dynamically on demand.
Cont;
So, on a technical level, Web services can handle data
much easier and allow software to communicate more
freely.
On a higher conceptual level, we can look at Web
services as units of work, each handling a specific
functional task.
One step above this, the tasks can be combined into
business-oriented tasks to handle particular business
operational tasks, and this in turn allows non-technical
people to think of applications that can handle business
issues together in a workflow of Web services
applications.
Cont;
Thus, once the Web services are designed and built by
technical people, business process architects can
aggregate them into solving business level problems.
To borrow a car engine analogy, a business process
architect can think of putting together a whole car engine
with the car frame, body, transmission, and other
systems, rather than look at the many pieces within each
engine.
Furthermore, the dynamic platform means that the
engine can work together with the transmission or parts
from other car manufacturers.
Cont;
What rises from this last aspect is that Web services are
helping to bridge the gap between business people and
technologists in an organization.
Web services make it easier for business people to
understand technical operations.
Business people can describe events and activities and
technologists can associate them with appropriate
services.
With universally defined interfaces and well designed
tasks, it also becomes easier to reuse these tasks and
thus, the applications they represent.
Cont;
Reusability of application software means a better return
on investment on software because it can produce more
from the same resources.
It allows business people to consider using an existing
application in a new way or offering it to a partner in a
new way, thus potentially increasing the business
transactions between partners.
Therefore, the primary issues that Web services tries to
tackle are the issues of data and application integration,
and that of transforming technical functions into
business-oriented computing tasks.
Cont;
These two facets allow businesses to communicate on a
process or application level with their partners, while
leaving dynamic room to adapt to new situations or work
with different partners on demand.
What can U do with Web

services?
While Web services allows all these dynamic features to
combine multiple services into applications, you still have
to build the services first.
Programming languages in Computer science is
continually evolving.
We began decades ago with the idea of a function
whereby you provide it some parameters, it executes
some operation on those parameters, and it returns a
value based on its calculations.
Cont;
Eventually, this first concept evolved into the object
where each object had not just a number of functions it
can perform but also its own private data variables,
rather than relying on external system-wide data
variables that previously made it more complex to
develop applications.
As applications began communicating with each other,
the concept of defined universal interfaces for objects
became important, allowing objects on other platforms to
communicate even if they were written in other
programming languages and ran on other operating
systems.
Cont;
At the most recent step, Web services has moved
towards the concept of XML-defined interfaces and
communications, finally uniting any kind of application
with another, as well as providing the freedom to change
and evolve over time, as long as they are designed to
the appropriate interface.
The versatility of XML is what makes Web services
different from previous generation component
technologies.
It allows the separation of grammatical structure (syntax)
and the grammatical meaning (semantics), and how that
is processed and understood by each service and the
environment it exists in.
Cont;
So now, objects can be defined as services,
communicating with other services in XML-defined
grammar, whereby each service then translates and
analyzes the message according to its local
implementation and environment.
Thus a networked application can truly be composed of
multiple entities of various makes and designs as long as
they conform to the rules defined by their service
oriented architecture.
Cont;
Thus, with this in mind, Web services allow you to:
Interact between services on any platform, written in
any language
Conceptualize application functions into task, leading
to task-oriented
development and workflows. This allows a higher
abstraction of software that can be employed by less
software-technical users that work on business level
analytics.
Cont;
Allow for loose-coupling, which means that
interactions between service applications may not
break each time there is a change in how one or more
services are designed or implemented.
Adapt existing applications to changing business
conditions and customer needs.
Provide existing or legacy software applications with
service interfaces without changing the original
applications, allowing them to fully operate in the
service environment.
Cont;
Introduce other administrative or operations
management functions such as reliability,
accountability, security, etc., independent of the
original function, thus increasing its versatility and
usefulness in the business computing environment.
Web Services
The term Web services describes a standardized way of
integrating Web-based applications using the XML,
SOAP, WSDL and UDDI open standards over an
Internet protocol backbone.
XML is used to tag the data, SOAP is used to transfer
the data, WSDL is used for describing the services
available and UDDI is used for listing what services are
available.
Used primarily as a means for businesses to
communicate with each other and with clients, Web
services allow organizations to communicate data
without intimate knowledge of each other's IT systems
behind the firewall
Cont;
Unlike traditional client/server models, such as a Web
server/Web page system, Web services do not provide
the user with a GUI.
Web services instead share business logic, data and
processes through a programmatic interface across a
network.
The applications interface, not the users
Developers can then add the Web service to a GUI
(such as a Web page or an executable program) to offer
specific functionality to users.
Cont;
Web services allow different applications from different
sources to communicate with each other without timeconsuming custom coding, and because all
communication is in XML, Web services are not tied to
any one operating system or programming language.
For example, Java can talk with Perl, Windows
applications can talk with UNIX applications.
Web services do not require the use of browsers or
HTML.
Web services are sometimes called application services
Cont;
Over the last couple of years, Web services have
expanded to become more popular with application
developers
Web services technology represents an important way
for businesses to communicate with each other and with
clients as well.
Unlike traditional client/server models, such as a Web
server or Web page system, Web services do not
provide the user with a GUI.
Cont;
Instead, Web services share business logic, data and
processes through a programmatic interface across a
network.
The applications interface with each other, not with the
users.
Developers can then add the Web service to a GUI
(such as a Web page or an executable program) to offer
specific functionality to users.
Cont;
Web services' distributed computing model allows

application-to-application communication
For example, one purchase-and-ordering application

could communicate to an inventory application that
specific items need to be reordered.
Because of this level of application integration, Web
services have grown in popularity and are beginning to
improve business processes. In fact, some even call
Web services the next evolution of the Web.
Web Services Technology

Web services are built on several technologies that work
in conjunction with emerging standards to ensure
security and manageability, and to make certain that
Web services can be combined to work independent of a
vendor.
The term Web service describes a standardized way of
integrating Web-based applications using the XML,
SOAP, WSDL and UDDI open standards over an
Internet protocol backbone.
Cont;
XML
Short for Extensible Markup Language, a
specification developed by the W3C.
XML is a pared-down version of SGML, designed
especially for Web documents. It allows designers to
create their own customized tags, enabling the
definition, transmission, validation, and interpretation
of data between applications and between
organizations.
Cont;
SOAP
Short for Simple Object Access Protocol, a lightweight
XML-based messaging protocol used to encode the
information in Web service request and response
messages before sending them over a network.
SOAP messages are independent of any operating
system or protocol and may be transported using a
variety of Internet protocols, including SMTP, MIME,
and HTTP.
Cont;
WSDL
Short for Web Services Description Language, an
XML-formatted language used to describe a Web
service's capabilities as collections of communication
endpoints capable of exchanging messages.
WSDL is an integral part of UDDI, an XML-based
worldwide business registry.
WSDL is the language that UDDI uses.
WSDL was developed jointly by Microsoft and IBM.
Cont;
UDDI
Short for Universal Description, Discovery and
Integration.
It is a Web-based distributed directory that
enables businesses to list themselves on the
Internet and discover each other, similar to a
traditional phone book's yellow and white
pages.
Cont;
XML is used to tag the data, SOAP is used to
transfer the data, WSDL is used for describing
the services available and UDDI is used for
listing what services are available.
Used primarily as a means for businesses to
communicate with each other and with clients,
Web services allow organizations to
communicate data without intimate knowledge of
each other's IT systems behind the firewall.
Security
Security has become a hot topic for Web services.
Because it is based on program-to-program interactions
as opposed to human-to-program interaction, it is
important for Web service security to address topics
such as access control, authentication, data integrity and
privacy.
Today the most common security scheme is SSL
(Secure Sockets Layer), but when it comes to Web
services there are limitations with SSL.
Cont;
The Web service technology has been moving towards
different XML-based security schemes for Web services.
Some of the XML-based securities include the following:
XML digital signature
The XML Signature specification is a joint effort of
W3C and IETF. XML Signatures provide integrity,
message authentication and/or signer
authentication services for data of any type,
whether located within the XML that includes the
signature or elsewhere.
Cont;
cont;
XML Encryption
W3C's XML Encryption specification addresses the
issue of data confidentiality using encryption
techniques.
Encrypted data is wrapped inside XML tags
defined by the XML Encryption specification.
Cont;
cont;
WS-Security (Web Services Security)
Security Assertion Markup Language (SAML) from
OASIS provides a means for partner applications
to share user authentication and authorization
information.
This is essentially the single sign-on (SSO) feature
being offered by all major vendors in their ecommerce products.
In the absence of any standard protocol on sharing
authentication information, vendors normally use
cookies in HTTP communication to implement
SSO.
Cont;
cont;
WS-Security (Web Services Security) cont
With the advent of SAML, this same data can be
wrapped inside XML in a standard way, so that
cookies are not needed and interoperable SSO
can be achieved.
Who Is Using Web Services?

Perhaps the best example of the growth of Web services
is eBay. The online auction site developers has been
aggressively developing its Web services platform by
extending application programming interfaces that
essentially turn its Web site into a platform.
The auction site's developer section gives soup-to-nuts
information about deploying its eBay API.
"With the eBay API, you communicate directly with the
eBay database in XML format.
By using the API, your application can provide a custom
interface, functionality and specialized operations not
otherwise afforded by the eBay interface."
Cont;
Since 1999, eBay has offered APIs and now offers more
than 100 Web services calls available to developers to
build applications that can connect to those services.
They include pricing information, buy-it-now features,
and payment options through its PayPal subsidiary.
The growth and use of APIs across the Web illustrate
how rapidly Web services are spreading, even as
technical issues such as security and authentication are
worked out by standards bodies.
Cont;
Online retailing giant Amazon.com is another example.
Companies such as Microsoft and Sun Microsystems
have been helping developers build and deploy Web
Services and clients for close to four years now.
Sun's J2EE platform, for example, is where developers
build on the building blocks in order to access
Amazon.com's selling platform.
Web Services
A Web Service (also Webservice) is defined by the W3C
as "a software system designed to support interoperable
machine-to-machine interaction over a network.
It has an interface described in a machine-processable
format (specifically WSDL).
Other systems interact with the Web service in a manner
prescribed by its description using SOAP-messages,
typically conveyed using HTTP with an XML serialization
in conjunction with other Web-related standards.
Cont;
Web services are frequently just Internet Application
Programming Interfaces (API) that can be accessed over
a network, such as the Internet, and executed on a
remote system hosting the requested services.
Cont;
Other approaches with nearly the same functionality as
web services are:
Object Management Group's (OMG) Common Object
Request Broker Architecture (CORBA)
Microsoft's Distributed Component Object Model
(DCOM)
Sun Microsystems's Java/Remote Method Invocation
(RMI).
Cont;
In common usage the term refers to clients and servers
that communicate over the Hypertext Transfer Protocol
(HTTP) protocol used on the Web.
Such services tend to fall into one of two camps:
Big Web Services
RESTful Web Services.
Such services are also referred to as web APIs.
Cont;
"Big Web Services" use Extensible Markup Language
(XML) messages that follow the Simple Object Access
Protocol (SOAP) standard and have been popular with
traditional enterprise.
In such systems, there is often a machine-readable
description of the operations offered by the service
written in the Web Services Description Language
(WSDL).
Cont;
The latter is not a requirement of a SOAP
endpoint, but it is a prerequisite for automated
client-side code generation in many Java and
.NET SOAP frameworks (frameworks such as
Spring, Apache Axis2 and Apache CXF being
notable exceptions).
Some industry organizations, such as the WS-I,
mandate both SOAP and WSDL in their
definition of a Web service.
Cont;
More recently, REpresentational State Transfer
(RESTful) Web services have been regaining popularity,
particularly with Internet companies.
By using the PUT, GET and DELETE HTTP methods,
alongside POST, these are often better integrated with
HTTP and web browsers than SOAP-based services.
They do not require XML messages or WSDL serviceAPI definitions.
Cont;
A highly dynamic and loosely coupled environment
increases not only the probability of deviation situations
that occur during the execution of composite services,
but also the complexity in exception handling.
Due to the distributed nature of SOA, loosely coupled
feature of web services, the monitoring and exception
handling issues about web services in SOA context is
still an open research issue.
Cont;
When running composite web services, each sub service
can be considered autonomous. The user has no control
over these services.
Also the web services themselves are not reliable; the
service provider may remove, change or update their
services without giving notice to users.
The reliability and fault tolerance is not well supported;
faults may happen during the execution.
Exception handling in the context of web services is still
an open research issue.
Cont;
Styles of use
Web services are a set of tools that can be used in a
number of ways.
The three most common styles of use are
RPC
SOA
REST
Styles of use
Remote procedure calls
RPC Web services present a distributed function (or
method) call interface that is familiar to many
developers.
Typically, the basic unit of RPC Web services is the
WSDL operation.
The first Web services tools were focused on RPC, and
as a result this style is widely deployed and supported.
Cont;
However, it is sometimes criticized for not being loosely
coupled, because it was often implemented by mapping
services directly to language-specific functions or
method calls.
Many vendors felt this approach to be a dead end, and
pushed for RPC to be disallowed in the WS-I Basic
Profile.
Architectural elements involved in the XML-RPC
Cont;
Service-oriented architecture
Web services can also be used to implement an
architecture according to Service-oriented architecture
(SOA) concepts, where the basic unit of communication
is a message, rather than an operation.
This is often referred to as "message-oriented" services.
SOA Web services are supported by most major
software vendors and industry analysts.
Cont;
Service-oriented architecture cont;
Unlike RPC Web services, loose coupling is more likely,
because the focus is on the "contract" that WSDL
provides, rather than the underlying implementation
details.
Middleware Analysts use Enterprise Service Buses
which combine message-oriented processing and Web
Services to create an Event-driven SOA. One example
of an open-source ESB is Mule.
Cont;
Representational state transfer
Finally, Representational State Transfer (REST)
attempts to describe architectures which use HTTP or
similar protocols by constraining the interface to a set of
well-known, standard operations (like GET, POST, PUT,
DELETE for HTTP).
Here, the focus is on interacting with state-ful resources,
rather than messages or operations.
Cont;
Representational state transfer cont;
An architecture based on REST (one that is 'RESTful')
can use WSDL to describe SOAP messaging over
HTTP, which defines the operations, can be
implemented as an abstraction purely on top of SOAP
(e.g., WS-Transfer), or can be created without using
SOAP at all.
WSDL version 2.0 offers support for binding to all the
HTTP request methods (not only GET and POST as in
version 1.1) so it enables a better implementation of
RESTful Web services.
However, support for this specification is still poor in
software development kits, which often offer tools only
for WSDL 1.1.
Aligning IT with your business,

increasing business agility
Service-Oriented Architecture (SOA) is an IT
architectural style that supports the transformation of
your business into a set of linked services, or repeatable
business tasks, that can be accessed when needed over
a network.
This may be a local network, it may be the Internet, or it
may be geographically and technologically diverse,
combining services in New York, London, and Hong
Kong as though they were all installed on your local
desktop.
Cont;
These services can coalesce to accomplish a specific
business task, enabling your business to quickly adapt
to changing conditions and requirements
When SOA implementation is guided by strategic
business goals, you ensure the positive transformation
of your business and can realize the chief benefits on an
SOA, as follows:
Alignment of IT with the business
Maximal reuse of IT assets
Cont;
Together, these help assure that investment in
expensive IT projects result in lasting value to the
business.
So, how do you tap into SOA, and how does it affect
your business? IBM has identified five entry points for
ensuring that every SOA-based solution undertaken
delivers real business value.
Each entry point is coupled with a scenario, or defined
approach, that implements the technologies and thus the
business values defined in each entry point.
SOA entry points

The five entry points defined by IBM -- based upon real
customer experiences -- can help you and your business
benefit by implementing predefined SOA solutions.
These entry points are driven by both business needs
(people, process, and information entry points) and IT
needs (connectivity and reuse entry points).
Here are general descriptions of the five entry points:
People: This entry point to SOA focuses on the user
experience to help generate innovation and greater
collaboration, which enables consistent human and
process interaction, thus improving business
productivity. Using SOA you can, for example, create
service-based portlets to increase this collaboration.
Cont;
Cont;
Process:
The process entry point helps companies know
what is happening in their business, allowing them
to improve existing business models.
Using SOA you can transform your business
processes into reusable and flexible services,
allowing you to improve and optimize these new
processes.
Cont;
Cont;
Information:
Using this entry point to SOA you can leverage
information in your company in a consistent and
visible way. By providing this consistent and
trusted information throughout all areas of your
business, you empower all areas of your company
to innovate, thus allowing you to compete more
effectively.
Using SOA you have better control over your
information, and by aligning information with your
business processes you can discover interesting
new relationships.
Cont;
Cont;
Connectivity:
Take advantage of the connectivity entry point in
order to effectively connect your infrastructure,
integrating all of the people, processes, and
information in your company.
By having flexible SOA connections between
services, and throughout your environment, you
can take an existing business process and deliver
it without much effort through a different business
channel.
You can even connect to external partners outside
your firewall in a secure way.
Cont;
Reuse: Reusing services with SOA allows you to tap
into the services that already exist in your company.
By building from your existing resources you can
streamline your business processes, ensure
consistency throughout your company, and cut
development time. All of this saves you time and
money. You also reduce any duplication of
functionality in your services and get to take
advantage of using the proven core applications the
people in your company are familiar with.
Cont;
What are Web services'

component technologies?
Web services involves a family of related
protocols to describe, deliver, and interact with
services.
This family can be further subdivided into
groupings based on common functions and
uses.
The first group handles the issues of messaging,
interface description, addressing and delivery.
Cont;
The most well-known is the messaging protocol known
as Simple Object Access Protocol (SOAP).
This protocol encodes messages so they can be
delivered over the network using a transport protocol
such as HTTP, IIOP, SMTP, or others.
The Web Services Description Language (WSDL) is
represented as a series of XML statements that
constitute the definition for the interfaces of each
service.
Cont;
Another specification currently in progress is WSAddressing that defines how to uniquely address and
identify Web services in a distributed architecture.
Another popular specification is the Web Services
Invocation Framework, where you can define WSDL
interfaces for any type of component even those that do
not use the same messaging protocols.
The next group of protocols and specifications define
how services advertise themselves and can find each
other on the network.
Cont;
For services to locate each other, the Universal
Description, Discovery and Integration (UDDI) protocol
defines a registry and associated protocols for locating
and accessing services.
The Web Services Inspection Language is an alternative
mechanism to UDDI that works without the use of a
registry.
Cont;
The Security protocols for Web services begin with the
WS-Security specification that defines a token based
architecture for secure communications.
Built on this base, there are six major component
specifications:
WS-Policy and its related specifications that define
the policy rules on how services interact.
WS-Trust that defines the trust model for secure
exchange.
Cont;
Cont;
WS-Privacy that defines how privacy of information is
maintained.
WS-Secure Conversation that defines how to
establish a secured session between services for
exchanging data using the rules defined in WSPolicy, WS-Trust, and WS-Privacy.
WS-Federation that defines the rules of distributed
identity and how its managed.
WS-Authorization that handles the processing for
authorization to access and exchange data.
Cont;
Beyond the Security model are the application specific
specifications including the Business Process Execution
Language for Web Services (BPEL4WS) defines
workflow operations, and WS-Transaction and WSCoordination that work together to handle distributed
transactional processing.
Currently in the works is a specification for Web
Services Distributed Management for software
administrative management of all services and the
service-oriented architecture.
Finally there are specifications for user interfaces (WSInteractiveApplications) and remote access of Web
services (WS-RemotePortals).
Cont;
The specifications and protocols for Web services are
still being defined at the time of writing and only begin to
explain how services should interact with each other.
However, they cannot cover every single scenario and
combination possible.
Thus, the Web Services Interoperability Group (WS-I)
consisting of members from practically all major and
minor vendors involved in Web services development,
has taken on the task of developing case studies,
sample applications, implementation scenarios, and test
tools to ensure that these standards and specifications
will truly work with each other irrespective of vendor
product implementations.
Cont;
WS-I has defined their first Basic Profile 1.0 for
Web services as well as released their
Scenarios, Sample Applications and Test Tools
to evaluate and compare results of various
implementations according to the Scenarios.
In addition to the WS-I a significant amount of
the standards work is being developed by the
Organization for the Advancement of Structured
Information Standards (OASIS), the World Wide
Web Consortium (W3C), and the Internet
Engineering Task Force (IETF).
How does Web services relate to

other technologies?
Web services is primarily an integration technology.
However, it is independent of form in itself.
The component technologies for Web services are
commonly defined and interact in XML, as mentioned
earlier.
However, since XML itself is language independent, so
is Web services.
Cont;
Thus Web services can be developed in a number of
programming languages including Java, Python, Perl,
C#, Basic, and others.
The origins of Web services lie in trying to find a better
way for the architecture of Internet and Web applications
to better communicate and interact with each other.
Thus, most Web services today are based on programs
that run on application server environments like
WebSphere, Apache, and others.
Cont;
They are not required to but some of the best Web
services tools are designed for such environments.
By providing simpler, universal interfaces, Web services
is also helping to improve how the pervasive computing
model works for mobile and portable environments.
Software for mobile computing is quickly adopting the
Web services model of communicating while also
helping to improve the interface issues of visual Web
services.
Cont;
Grid computing has adopted Web services as part of the
Open Grid Services Architecture, a new model for this
type of distributed computing that uses Web services to
communicate how the grid operates.
Even Autonomic computing which is an interesting new
way to how computers can maintain and manage
themselves has some applications for Web services.
How can I use Web services in

an application?
There are several ways to think about Web services
when building applications.
At the most basic level it is an advanced
communications protocol family allowing applications to
talk to each other.
This level has progressed quite significantly over the
past few years with many tools that allow software
developers to write interacting Web services and build
complex applications.
Cont;
This level is often characterized by direct one-on-one
interactions between services or relatively few services
interacting with each other.
However, just using Web services as a communications
protocol belies its true power, that of the service-oriented
architecture (SOA).
The SOA describes an entire system of services
dynamically looking around for each other, getting
together to perform some application, and recombining
in many ways.
Cont;
This model encourages the reuse of technology and
software that evolves the way applications are designed,
developed and put to use.
It brings the world of distributed computing to a closer

reality.
At this level software developers need to think of the
SOA model and design their distributed application
across the model.
This level is characterized by the use of technologies to
allow distributed communications of services such as the
use of an Enterprise Service Bus (ESB), which is a
common distribution network for services to work with.
Cont;
Finally, the highest level is to look at this SOA model
and the many component services as building blocks,
that can be assembled in whole sections into full
applications instead of the traditional method of writing
line after line of code.
By examining the connecting interfaces, we can build
whole applications without ever really writing code.
For that matter direct code may even get in the way
since the services may be written in numerous different
languages and platforms.
Cont;
The blocks can be put together into a workflow of
operations that define how the application performs, and
other tools can be used to monitor the effectives of the
workflow at each service or group of services.
At this level, developers can put away the use of regular
programming languages and work in a Model-Driven
Architecture that helps them to build applications more
accurately to a design.
This design then runs on top of a distributed system like
an ESB.
What are Web services?

If you hadn't been hearing lots and lots of information
about Services-oriented architecture (SOA) and Web
services, you wouldn't be here, so the question is, why is
this such a big deal?
The answer is that it's a big deal because it's a paradigm
shift in the way applications communicate with each
other.
SOAs have been around for a long, long, time.
Originally they mostly consisted of middleware
applications in which a single type of middleware owns,
at the very least, both ends of the wire.
Cont;
Web services, on the other hand, consist of a group of
standards intended to make it possible for diverse
systems to communicate, without requiring a particular
type of middleware, programming language or even
operating system.
Cont;
Traditional applications
In the beginning, there were computers. And it was
good. Computers performed seemingly miraculous
tasks, automating many of the things that people did by
hand, starting with complex calculations, and moving to
financials, and many other tasks.
But traditional applications are "silos". The human
resources application couldn't really talk to the financials
application, which couldn't really talk to the distribution
application.
Cont;
Traditional applications cont;
All of these applications had their own home, on their
own computer, and while they were useful, there wasn't
a good way to share data between them.
You had the option to write batch processes to move
data from one system to another, but that was no
substitute for real-time integration.
Distributed computing
Cont;
The next step in our evolutionary chain is distributed

computing.
Distributed computing enabled different applications to
talk to each other, even if they weren't on the same
computer.
Technologies such as CORBA, MTS, and Enterprise
Java Beans (EJB), provided a system that included a
registry of sorts so that applications could find
components with which they wished to interact, and then
call these components as though they were located on
the local machine.
Cont;
Cont;
These systems were supported by middleware, or more
specifically, message-oriented middleware, which
provided both of these requirements.
Applications could now be built in such a way that they
could access resources on other systems, even if they
were in different geographic locations.
there was still a problem. While applications were free to
communicate anywhere within the system, it was still a
closed system.
Cont;
Cont;
At the very least, your client application had to use the
same technology as the server application. Also, the
systems were not designed, as a rule, for access from
outside of the individual organization that had created
them.
Cont;
Web services
The next, almost inevitable link in this evolutionary chain
is Web services.
Based on XML, and, in most cases, HTTP, "Web
services" still means many things to many people, but in
this case, we're going to talk about Web services as the
exchange of SOAP-based messages between systems.
Cont;
Web services cont;
These messages are composed of XML, which is a textbased open standard, accessible by anyone from any
application (any application that's been designed to
accept it).
This expands the world for your application to include
anyone who can reach it over your network. (If that sets
off security bells for you, that's OK, you'll learn how to
deal with that in part four of this series.)
Cont;
Cont;
A SOAP-based Web service involves the sending of an XML
message such as shown below:
A SOAP-based web service
<SOAPenv:Envelope
xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAPenv:Body>
<req:getNumberOfArticles xmlns:req="http://dailymoon.com/CMS/">
<req:category>classifieds</req:category>
</req:getNumberOfArticles>
</SOAPenv:Body>
</SOAPenv:Envelope>
Cont;
Cont;
These messages move from one system to another,
usually via HTTP.
The receiving system interprets the message, does what
it's supposed to do, and sends back a response in the
form of another SOAP message.
It is a simple system, and as such, there are many
aspects of enterprise-level computing that are not
covered by it.
Cont;
Cont;
Fortunately, many of these aspects have been taken into
consideration, and have their own specifications to
determine how this transaction should take place to
incorporate many of the security and other aspects of
traditional message-oriented middleware.
Cont;
Other kinds of Web services
SOAP is not the only way to do Web services.
There are other XML-based means for sending
messages between systems, some of which are
applicable to an enterprise environment, and some of
which are not.
For example, Amazon was one of the first Web-based
companies to provide Web services access to its system
to the public.
Cont;
Other kinds of Web services cont;
Amazon includes a SOAP-based service, but it also
provides a service based on Representational State
Transfer (REST).
REST is a type of Web service in which the user simply
accesses a URL, and the response is a straight XML
document such as the one shown below:
Cont;
Cont;
A REST response
<currentArticles>
<category>classifieds</category>
<subcategory>forsale</subcategory>
<article id="888204">
<articleHeadline></articleHeadline>
<articleText>
30 ft ladder, only used once. Willing to letgo for half
it's worth. Has slight dent near the middle. Harder
than a human head. $150 OBO.
</articleText>
</article>
cont;
Cont;
A REST response cont;
Cont;
cont;
<article id="888242">
<articleText>
Vintage 1963 T-Bird. Less than 300 miles. Driven
by my daughter until I took it away. Serious
inquires only.555-3264 after 7 PM.
</articleText>
</article>
</currentArticles>
Cont;
Cont;
There is no particular format to these messages.
It is just whatever the data happens to be.
Another type of Web service involves the use of a
standard such as XML-RPC.
In this case, commands are sent to a system via XML
such as shown following:
Cont;
XML-RPC
Cont;
<methodCall>
<methodName>CMS.getNumberOfArticles</methodName>
<params>
<param>
<value>
<string>classifieds</string>
</value>
</param>
<param>
<value>
<string>forsale</string>
</value>
</param>
</params>
</methodCall>
Cont;
Cont;
The response follows a similar format.
As you're learning to use SOAP, in the back of your
mind you may be thinking that REST and XML-RPC are
much simpler than a SOAP-based system.
And you're right. In some ways, they are.
However, we are not talking about a simple application
to display the weather on your web site.
Cont;
Cont;
We're talking about enterprise-level applications here,

and enterprise-level applications need enterprise-level
attributes such as security, interoperability, and so on.
These capabilities are covered by additional
specifications that have sprung up around SOAP-based
Web services, which makes SOAP a better choice for
enterprise-level applications in the long run.
Let's look at some of these specifications.
Basic Web services

specifications
Web services specifications typically fall into two
categories:
basic Web service specs,
and expanded Web service specs.
The basic specifications are:
SOAP:
The foundation of all SOAP-based Web services,
the SOAP specification details the format of the
actual messages.
Cont;
Cont:
SOAP cont:
It also details the way applications should treat
certain aspects of the message, such as elements
in the "header", which enable you to create
applications in which a message is passed
between multiple intermediaries before reaching
its final destination.
Cont;
WDSL:
Web Services Description Language is a
specification that details a standard way to
describe a SOAP-based Web service, including
the form the messages should take, and where
they should be sent.
It also details the response to such a message.
WSDL, when combined with the appropriate tools,
enables you to create a call to a web service
programmatically without ever actually knowing
what the Web service is looking for; the
application can extract those details from the
WSDL file and provide you with programmatic
interfaces to use.
UDDI:
Cont;
Universal Description, Discovery and Integration is

a standard that has undergone somewhat of a
change since its initial inception.
The idea was to provide a way for companies to
register their services in a global registry, and
search that global registry for services they may
be interested in using.
However, because many companies are
understandably reticent about opening their
systems to outsiders, this goal hasn't quite
materialized.
UDDI cont:
Cont;
However, UDDI has taken hold as an internal

registry of services and service information; part
three of this series details its use.
Those are the basics. There are also literally dozens of
extended standards to make SOAP-based services
more useful.
Cont;
Extended Web services specifications
Of the dozens all of WS-*specifications floating around,
several distinguish themselves as being particularly
useful to the enterprise. They are:
WS-Security:
This specification handles encryption and digital
signatures, enabling you to create an application
in which messages can't be eavesdropped, and in
which non repudiation as possible.
Cont;
WS-Policy:
This specification expands on WS-Security,
enabling you to more specifically detail how and
by whom a service can be used.
WS-I:
Although Web services are supposed to be
designed for interoperability, in actuality there is
enough flexibility in the specifications that
interpretations between different implementations
can cause problems.
WS-I provides a set of standards and practices to
prevent the sorts of problems, as well as
standardized tests to check for problems.
Cont;
Cont;
WS-BPEL:
a single service is nice, but in most cases it is hardly an
application.
At the very least, enterprise-level computing requires you to
compose multiple services into an overall system, and WSBPEL provides a way to specify interactions such as
branching and concurrent processing that are necessary for
creating such systems.
Part seven of this series covers WS-BPEL.
Cont;
XML provides a way to separate content into different

"namespaces", so it can be treated differently by an application.
For example, a SOAP message might look like the following:

An example SOAP message
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAPenvelope">
<env:Header>
</env:Header>
<env:Body>
<cms:getNumberOfArticles xmlns:cms="http://www.dailymoon.com/cms">
<cms:category>classifieds</cms:category>
<cms:subcategory>forsale</cms:subcategory>
</cms:getNumberOfArticles>
</env:Body>
</env:Envelope>
The End.
Section 5 Part 2
Web Services
5.4. Messaging with SOAP
What are Web Services?

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

The basic Web services platform is XML + HTTP.
XML provides a language which can be used between
different platforms and programming languages and still
express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Cont;
Web services platform elements:
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and
Integration)
WSDL (Web Services Description Language)
Web Services have three basic platform elements:
SOAP, WSDL and UDDI.
Cont;
Cont;
Cont;
What is SOAP?
SOAP is an XML-based protocol to let applications
exchange information over HTTP.
Or more simple: SOAP is a protocol for accessing a
Web Service.
SOAP stands for Simple Object Access Protocol
SOAP is a communication protocol
SOAP is a format for sending messages
SOAP is designed to communicate via Internet
Cont;
SOAP is platform independent
SOAP is language independent
SOAP is based on XML
SOAP is simple and extensible
SOAP allows you to get around firewalls
SOAP is a W3C standard
What is WSDL?
WSDL is an XML-based language for locating and
describing Web services.
WSDL stands for Web Services Description Language
WSDL is based on XML
WSDL is used to describe Web services
WSDL is used to locate Web services
WSDL is a W3C standard
What is UDDI?
UDDI is a directory service where companies can
register and search for Web services.
UDDI stands for Universal Description, Discovery and
Integration
UDDI is a directory for storing information about web
services
UDDI is a directory of web service interfaces
described by WSDL
UDDI communicates via SOAP
UDDI is built into the Microsoft .NET platform
Why SOAP?
It is important for application development to allow
Internet communication between programs.
Today's applications communicate using Remote
Procedure Calls (RPC) between objects like DCOM and
CORBA, but HTTP was not designed for this.
RPC represents a compatibility and security problem;
firewalls and proxy servers will normally block this kind
of traffic.
Cont;
A better way to communicate between applications is
over HTTP, because HTTP is supported by all Internet
browsers and servers. SOAP was created to accomplish
this.
SOAP provides a way to communicate between
applications running on different operating systems, with
different technologies and programming languages.
Cont;
SOAP Building Blocks

A SOAP message is an ordinary XML document
containing the following elements.
Envelope: ( Mandatory )
Defines the start and the end of the message.
Header: ( Optional )
Contains any optional attributes of the message used
in processing the message, either at an intermediary
point or at the ultimate end point.
Body: ( Mandatory )
Contains the XML data comprising the message
being sent.
SOAP Building Blocks

Fault: ( Optional )
An optional Fault element that provides information
about errors that occurred while processing the
message
All the elements above are declared in the default
namespace for the SOAP envelope:
http://www.w3.org/2001/12/soap-envelope
and the default namespace for SOAP encoding and data
types is:
http://www.w3.org/2001/12/soap-encoding
Syntax Rules
Here are some important syntax rules:
A SOAP message MUST be encoded using XML
A SOAP message MUST use the SOAP Envelope
namespace
A SOAP message MUST use the SOAP Encoding
namespace
Cont;
Cont;
A SOAP message must NOT contain a DTD
reference
A SOAP message must NOT contain XML
Processing Instructions
A SOAP Message Structure

<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
An example SOAP message

<env:Header>
</env:Header>
<env:Body>
<cms:getNumberOfArticles
xmlns:cms="http://www.dailymoon.com/cms">
<cms:category>classifieds</cms:category>
</cms:getNumberOfArticles>
</env:Body>
</env:Envelope>
Cont;
Don't worry about the actual structure of the message,
but notice that there are two different "prefixes", each of
which corresponds to a particular namespace.
In this case, we are distinguishing the SOAP "envelope"
from the actual payload.
The SOAP Envelope Element

The mandatory SOAP Envelope element is the root
element of a SOAP message.
This element defines the XML document as a SOAP
message.
The SOAP envelope indicates the start and the end of
the message so that the receiver knows when an entire
message has been received.
The SOAP envelope solves the problem of knowing
when you're done receiving a message and are ready to
process it.

The SOAP envelope is therefore basic ally a packaging
mechanism
The mandatory SOAP Envelope element is the root
element of a SOAP message.
This element defines the XML document as a SOAP
message.
The SOAP envelope indicates the start and the end of
the message so that the receiver knows when an entire
message has been received.

SOAP envelope solves the problem of knowing when
you're done receiving a message and are ready to
process it.
The SOAP envelope is therefore basic ally a packaging
mechanism
Cont;
SOAP Envelope element can be explained as:
Every SOAP message has a root Envelope element.
Envelope element is mandatory part of SOAP
Message.
Every Envelope element must contain exactly one
Body element.
If an Envelope contains a Header element, it must
contain no more than one, and it must appear as the
first child of the Envelope, before the Body.
Cont;
Cont;
The envelope changes when SOAP versions change.
The SOAP envelope is specified using the ENV
namespace prefix and the Envelope element.
The optional SOAP encoding is also specified using a
namespace name and the optional encodingStyle
element, which could also point to an encoding style
other than the SOAP one.
Cont;
Cont;
A v1.1-compliant SOAP processor will

generate a fault when receiving a message
containing the v1.2 envelope namespace.
A v1.2- compliant SOAP processor generates a
VersionMismatch fault if it receives a message that
does not include the v1.2 envelope namespace.
Cont;
The basic unit of a Web service message is the actual SOAP

envelope.
This is an XML document that includes all of the information

necessary to process the message below:
An example SOAP envelope

<env:Header>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
Cont;
In this case, you have a simple Envelope, with the

namespace specified as SOAP version 1.2.
It includes two sub elements, a Header and a Body. Let's look

at what each of those pieces do little later.
Example
<soap:Envelope
soap:encodingStyle="http://www.w3.org/2001/12/soapencoding">
...
Message information goes here
...
</soap:Envelope>
Cont;
Following example illustrates the use of a SOAP
message within an HTTP POST operation, which sends
the message to the server.
It shows the namespaces for the envelope schema
definition and for the schema definition of the encoding
rules.
The OrderEntry reference in the HTTP header is the
name of the program to be invoked at the abc.com Web
site.
Cont;
Example
POST /OrderEntry HTTP/1.1
Host: www.abc.com
Content-Type: application/soap; charset="utf-8
Content-Length: nnnn
<SOAP-ENV:Envelopexmlns:SOAPENV="http://www.w3.org/2001/12/soap-envelope"SOAPENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
...
</SOAP-ENV:Envelope>
NOTE: The HTTP binding specifies the location of the service.
Cont;
The xmlns:soap Namespace
Notice the xmlns:soap namespace in the example
above.
It should always have the value of:
"http://www.w3.org/2001/12/soap-envelope".
The namespace defines the Envelope as a SOAP
Envelope.
If a different namespace is used, the application
generates an error and discards the message.
Cont;
The encodingStyle Attribute
The encodingStyle attribute is used to define the data
types used in the document.
This attribute may appear on any SOAP element, and
applies to the element's contents and all child elements.
A SOAP message has no default encoding.
Syntax
soap:encodingStyle="URI"
Cont;
Example
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soapenvelope"
soap:encodingStyle="http://www.w3.org/2001/12
/soap-encoding">
...
...
</soap:Envelope>
The SOAP Header Element

The optional Header element offers a flexible framework
for specifying additional application-level requirements.
For example, the Header element can be used to specify
a digital signature for password-protected services;
likewise, it can be used to specify an account number for
pay-per-use SOAP services.
SOAP Header element can be explained as:
Header elements are optional part of SOAP
messages.
Cont;
Cont;
Cont;
Header elements can occur multiple times.
Headers are intended to add new features and
functionality
The SOAP header contains header entries defined in
a namespace.
The header is encoded as the first immediate child
element of the SOAP envelope.
Cont;
When more than one header is defined, all immediate
child elements of the SOAP header are interpreted as
SOAP header blocks.
Cont;
SOAP Header element can have following two
attributes:
Actor attribute:
The SOAP protocol defines a message path as a
list of SOAP service nodes.
Each of these intermediate nodes can perform
some processing and then forward the message
to the next node in the chain.
By setting the Actor attribute, the client can specify
the recipient of the SOAP header.
Cont;
Cont;
MustUnderstand attribute
Indicates whether a Header element is optional or
mandatory.
If set to true ie. 1 the recipient must understand
and process the Header attribute according to its
defined semantics, or return a fault.
The Header in a SOAP message is meant to provide
information about the message itself, as opposed to
information meant for the application.
For example, the Header might include routing
information, as it does in this example shown in below:
Cont;
Routing information in the Header

<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
<wsa:ReplyTo xmlns:wsa=
"http://schemas.xmlSOAP.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlSOAP.org/ws/2004/08/addressi
ng/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:From>
<wsa:Address>http://localhost:8080/axis2/services/MyService
</wsa:Address>
</wsa:From>
<wsa:MessageID>
ECE5B3F187F29D28BC11433905662036
</wsa:MessageID>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
Cont;
In this case you see a WS-Addressing element, which
includes information on where the message is going and
to where replies should go.
The Header and can include all kinds of information
about the message itself.
In fact, the SOAP specification spends a great deal of
time on elements that can go in the Header, and how
they should be treated by "SOAP intermediaries".
Cont;
In other words, the SOAP specification makes no
assumption that the message is going straight from one
point to another, from client to server.
It allows for the idea that a SOAP message might
actually be processed by several intermediaries, on its
way to its final destination, and the specification is very
clear on how those intermediaries should treat
information they find in the Header.
That discussion is beyond the scope of this tutorial,
however. So for now, just understand that the Header
can provide you much more functionality if you need it.
The SOAP Header element contains header information.
Cont;
The optional SOAP Header element contains
application-specific information (like
authentication, payment, etc) about the SOAP
message.
If the Header element is present, it must be the
first child element of the Envelope element.
Note: All immediate child elements of the
Header element must be namespace-qualified.
Cont;
Following example shows how to use a Header in the SOAP

message.
<SOAP-ENV:Envelopexmlns:SOAPENV="http://www.w3.org/2001/12/soap-envelope"SOAPENV:encodingStyle="http://www.w3.org/2001/12/soapencoding">
<SOAP-ENV:Header>
<t:Transactionxmlns:t="http://www.tutorialspoint.com/tran
saction/"SOAP-ENV:mustUnderstand="true">
5
</t:Transaction>
</SOAP-ENV:Header>
......
Cont;
The mustUnderstand Attribute
The SOAP mustUnderstand attribute can be used to
indicate whether a header entry is mandatory or optional
for the recipient to process.
If you add mustUnderstand="1" to a child element of the
Header element it indicates that the receiver processing
the Header must recognize the element.
If the receiver does not recognize the element it will fail
when processing the Header.
Syntax
soap:mustUnderstand="0|1"
Cont;
Example
<soap:Envelope
<soap:Header>
<m:Trans
xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>
The actor Attribute
Cont;
A SOAP message may travel from a sender to a

receiver by passing different endpoints along the
message path.
However, not all parts of a SOAP message may be
intended for the ultimate endpoint, instead, it may be
intended for one or more of the endpoints on the
message path.
The SOAP actor attribute is used to address the Header
element to a specific endpoint.
Syntax
soap:actor="URI"
Example
Cont;
<soap:Envelope
<soap:Header>
<m:Trans
xmlns:m="http://www.abc.com/transaction/
soap:actor="http://www.abc.com/appml/">
234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>
Now let's look at the actual payload (i.e. SOAP Body).
SOAP Body Element

The SOAP Body element contains the actual SOAP
message.
The required SOAP Body element contains the actual
SOAP message intended for the ultimate endpoint of the
message.
Immediate child elements of the SOAP Body element
may be namespace-qualified.
The SOAP body is a mandatory element which contains
the application-defined XML data being exchanged in
the SOAP message.
Cont;
The body must be contained within the envelope and
must follow any headers that might be defined for the
message.
The body is defined as a child element of the envelope,
and the semantics for the body are defined in the
associated SOAP schema.
Cont;
The body contains mandatory information intended for
the ultimate receiver of the message. For example:
Example
<SOAP-ENV:Envelope........
<SOAP-ENV:Body>
<m:GetQuotation
xmlns:m="http://www.tp.com/Quotation">
<m:Item>Computers</m:Item>
</m:GetQuotation>
</SOAP-ENV:Body>
Cont;
The example above requests the quotation of computer
sets.
Note that the m:GetQuotation and the Item elements
above are application-specific elements.
They are not a part of the SOAP standard.
below is the response of above query:
Cont;
Below is the response of above query:

Example
<SOAP-ENV:Envelope........
<SOAP-ENV:Body>
<m:GetQuotationResponse
xmlns:m="http://www.tp.com/Quotation">
<m:Quotation>This is
Qutation</m:Quotation>
</m:GetQuotationResponse>
</SOAP-ENV:Body>
Cont;
Normally, the application also defines a schema to
contain semantics associated with the request and
response elements.
The Quotation service might be implemented using an
EJB running in an application server; if so, the SOAP
processor would be responsible for mapping the body
information as parameters into and out of the EJB
implementation of the GetQuotationResponse service.
The SOAP processor could also be mapping the body
information to a .NET object, a CORBA object, a
COBOL program, and so on.
Cont;
A SOAP response could look something like this:
<soap:Envelope
<soap:Body>
<m:GetPriceResponse
xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
Cont;
When you're sending a SOAP message, you're doing it
with a reason in mind.
You are trying to tell the receiver to do something, or
you're trying to impart information to the server.
This information is called the "payload".
The payload goes in the Body of the Envelope.
Cont;
It also has its own namespace, in this case
corresponding to the content management system.
The choice of namespace, in this case, is completely
arbitrary.
It just needs to be different from the SOAP namespace
(See Listing below).
Cont;
A payload example :
<env:Header>
...
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.dailymoon.com/cms">
<cms:category>classifieds</category>
<cms:articleHeadline></cms:articleHeadline>
<cms:articleText>
Vintage 1963 T-Bird. Less than 300
miles. Driven by my daughter until I took it away. Serious inquires
only. 555-3264 after 7 PM.
</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
Cont;
In this case, you have a simple payload that includes
instructions for adding an article to the content
management system for the Daily Moon.
The choice of how to structure the payload involves the
style and encoding.
The SOAP Fault Element

When an error occurs during processing, the response
to a SOAP message is a SOAP fault element in the body
of the message, and the fault is returned to the sender of
the SOAP message.
The SOAP fault mechanism returns specific information
about the error, including a predefined code, a
description, the address of the SOAP processor that
generated
A SOAP Message can carry only one fault block
Fault element is an optional part of SOAP Message
Cont;
For the HTTP binding, a successful response is
linked to the 200 to 299 range of status codes;
SOAP fault is linked to the 500 to 599 range of status
codes.
The SOAP Fault element hold errors and status
information for a SOAP message.
The optional SOAP Fault element is used to indicate
error messages.
Cont;
If a Fault element is present, it must appear as a child
element of the Body element. A Fault element can only
appear once in a SOAP message.
The SOAP Fault element has the following sub
elements:
Sub Element Description
<faultCode>
A text code used to indicate a class of errors.

See the next Table for a listing of
predefined fault codes.
<faultString> A text message explaning the error
Cont;
<faultActor> A text string indicating who caused the fault.
This is useful if the SOAP message travels
through several nodes in the SOAP message
path, and the client needs to know which node
caused the error. A node that does not act as
the ultimate destination must include a
faultActor element.
<detail>
An element used to carry application-specific
error messages. The detail element can
contain child elements, called detail entries.
Cont;
SOAP Fault Codes
The faultCode values defined below must be used in
the faultcode element when describing faults
Error
SOAPENV:Version
Mismatch
SOAPENV:MustUn
derstand
Description
Found an invalid namespace for the SOAP
Envelope element
An immediate child element of the Header
element, with the mustUnderstand attribute set
to "1", was not understood
Cont;
Error
Description
SOAPENV:Client
SOAPENV:Server
The message was incorrectly formed or

contained incorrect information
There was a problem with the server so the
message could not proceed
Cont;
SOAP Fault Example
The following code is a sample Fault.
The client has requested a method named
ValidateCreditCard , but the service does not support
such a method.
This represents a client request error, and the server
returns the following SOAP response:
Cont;
SOAP Fault Example cont;

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode xsi:type="xsd:string">SOAP-ENV:Client
</faultcode>
<faultstring xsi:type="xsd:string">
Failed to locate method (ValidateCreditCard) in
class
(examplesCreditCard) at /usr/local/ActivePerl-5.6/lib/
site_perl/5.6.0/SOAP/Lite.pm line 1555.
</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
Style and encoding / SOAP

Encoding
As you create your application, you will need to decide on the

structure of the actual payload you're sending back and forth.
To that end, let's take a moment to discuss programming style and

encoding.
Lets look at two different programming styles for SOAP messages.

The first is the RPC style, based on the concept of using SOAP
messages to create Remote Procedure Calls. In this style, the
idea is that you're sending a command to the server, such as
"add an article", and you're including the parameters for that
command, such as the article to add and the category to which it
should be added, as child elements of the overall method, as in
Listing below next slide.
The second style is known as the document/literal style, which
involves simply adding the appropriate data to the message, as
that shown in Listing after the RPC style.
Cont;
RPC style
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/SOAPenvelope">
<env:Header>
Cont;
The alternative to the RPC style involves simply having your data as
the content of the SOAP body, and including the information as to
what procedure or function it pertains to in the routing of the
message by the application server (see Listing below).
Data as content in SOAP body
<env:Header>
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category>classifieds</category>
<cms:articleHeadline></cms:articleHeadline>
<cms:articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious inquires only.
555-3264 after 7 PM.
</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
Cont;
One variation on the RPC style is RPC/encoded, as opposed to

RPC/literal, as we see above. In that case, the message includes type
information, such as that shown in Listing below.
RPC/encoded example
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category xsi:type="xsd:string">classifieds</category>
<cms:subcategory xsi:type="xsd:string">forsale</cms:subcategory>
<cms:articleHeadline xsi:type="xsd:string" />
<cms:articleText xsi:type="xsd:string">
Vintage 1963 T-Bird. Less than 300 miles. Driven by my daughter
untilI took it away. Serious inquires only. 555-3264 after 7 PM.
</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
Cont;
The second style is known as the document/literal style, which

involves simply adding the appropriate data to the message, as that
shown in Listing below.
Document/literal style example

<env:Header>
</env:Header>
<env:Body>
<category>classifieds</category>
<subcategory>forsale</subcategory>
<articleText>
Vintage 1963 T-Bird. Less than 300 miles. Driven by my
daughter until I took it away. Serious inquires only. 555-3264 after
7 PM.
</articleText>
</env:Body>
</env:Envelope>
Cont;
In this case, the message itself doesn't include
information on the process to which the data is
to be submitted; that is handled by the routing
software.
For example, all calls to a particular URL or
endpoint might point to a particular operation.
Also, you could technically use the
document/encoded style, but nobody does, so
for now, ignore it.
Cont;
Different trade-offs are involved with each of
these styles, and again, part two of this series
will go into them in further detail.
It is important to know, however, that there is a
third style, "document wrapped," which isn't
formally specified anywhere but has gained
popularity for various interoperability reasons.
Cont;
In this case, the content of the payload is wrapped in a
single element, but that element may may not be named
after the procedure or function to which the data
belongs.
To the human eye, these messages are virtually
identical to RPC/literal messages.
SOAP includes a built-in set of rules for encoding data
types.This enables the SOAP message to indicate
specific data types, such as integers, floats, doubles, or
arrays.
SOAP data types are divided into two broad
categories: scalar types and compound types.
Cont;
Cont;
Scalar types contain exactly one value, such as a last
name, price, or product description.
Compound types contain multiple values, such as a
purchase order or a list of stock quotes.
Compound types are further subdivided into arrays
and structs.
The encoding style for a SOAP message is set via
the SOAP-ENV:encodingStyle attribute.
Cont;
Cont;
To use SOAP 1.1 encoding, use the value
http://schemas.xmlsoap.org/soap/encoding/
To use SOAP 1.2 encoding, use the value
http://www.w3.org/2001/12/soap-encoding
Latest SOAP specification adopts all the built-in types
defined by XML Schema. Still SOAP maintains its
own convention for defining constructs not
standardized by XML Schema, such as arrays and
references.
Cont;
Scalar Types
For scalar types, SOAP adopts all the built-in simple
types specified by the XML Schema specification.
This includes strings, floats, doubles, and integers.
Following table lists the main simple types, excerpted
from the XML Schema Part 0: Primer
http://www.w3.org/TR/2000/WD-xmlschema-020000407/
Cont;
Simple Types Built-In to XML Schema
Simple Type
string
boolean
float
double
decimal
binary
Example(s)
Confirm this is electric
true, false, 1, 0
-INF, -1E4, -0, 0, 12.78E-2,
12, INF, NaN
-INF, -1E4, -0, 0, 12.78E-2,
12, INF, NaN
-1.23, 0, 123.4, 1000.00
100010
Cont;
Cont;
integer
-126789, -1, 0, 1, 126789
nonPositiveInteger
-126789, -1, 0
negativeInteger
-126789, -1
long
-1, 12678967543233
int
-1, 126789675
short
-1, 12678
byte
-1, 126
nonNegativeInteger
0, 1, 126789
Cont;
Cont;
unsignedLong
0, 12678967543233
unsignedInt
0, 1267896754
unsignedShort
0, 12678
unsignedByte
0, 126
positiveInteger
1, 126789
date
1999-05-31, ---05
time
13:20:00.000, 13:20:00.00005:00
Cont;
For example, here is a SOAP response with a double data

type:
<?xml version='1.0' encoding='UTF-8'?*>

<SOAP-ENV:Envelope xmlns:SOAPENV="http://www.w3.org/2001/12/soap-envelope"
<SOAP-ENV:Body>
<ns1:getPriceResponse
xmlns:ns1="urn:examples:priceservice" SOAPENV:encodingStyle="http://www.w3.org/2001/12/soapencoding">
<return xsi:type="xsd:double">54.99</return>
</ns1:getPriceResponse>
</SOAP-ENV:Body>
Cont;
Compound Types
SOAP arrays have a very specific set of rules, which
require that you specify both the element type and array
size.
SOAP also supports multidimensional arrays, but not all
SOAP implementations support multidimensional
functionality.
To create an array, you must specify it as an xsi:type of
Array.
Cont;
Cont;
For example, the following attribute specifies an array of
10 double values:
arrayType="xsd:double[10]
In contrast, the following attribute specifies a twodimensional array of strings:
arrayType="xsd:string[5,5]"
Cont;
Here is a sample SOAP response with an array of double values:

<SOAP-ENV:Body>
<ns1:getPriceListResponse
xmlns:ns1="urn:examples:pricelistservice" SOAPENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<return xmlns:ns2="http://www.w3.org/2001/09/soapencoding" xsi:type="ns2:Array" ns2:arrayType="xsd:double[2]">
<item xsi:type="xsd:double">54.99</item>
<item xsi:type="xsd:double">19.99</item>
</return>
</ns1:getPriceListResponse>
</SOAP-ENV:Body>
Cont;
Compound Types cont;
Structs contain multiple values, but each element is
specified with a unique accessor element.
For example, consider an item within a product catalog.
In this case, the struct might contain a product SKU,

product name, description, and price.
Below is how such a struct would be represented in a

SOAP message:
Cont;
cont;
<SOAP-ENV:Body>
<ns1:getProductResponse
xmlns:ns1="urn:examples:productservice" SOAPENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<return xmlns:ns2="urn:examples" xsi:type="ns2:product">
<name xsi:type="xsd:string">Red Hat Linux</name>
<price xsi:type="xsd:double">54.99</price>
<description xsi:type="xsd:string">
Red Hat Linux
Operating System </description>
<SKU xsi:type="xsd:string">A358185</SKU>
</return>
</ns1:getProductResponse>
</SOAP-ENV:Body>
Cont;
cont;
NOTE: Take care of proper indentation while you write
your SOAP code.
Each element in a struct is specified with a unique
accessor name.
For example, the message above includes four accessor
elements: name , price , description , and SKU.
Each element can have its own data type; for example,
name is specified as a string , whereas price is specified
as a double.
The End.

IT5404-Internet Application Development

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IT5404-Internet Application Development

Încărcat de

Drepturi de autor:

Formate disponibile

Section 1

Web Applications Architecture

Benefits of Software Reuse

1.2. Distributed Computing

Apache HTTP Server

What IS the Apache HTTP

Using Apache HTTP Server

Solving the problems you

Understanding the Apache

Stopping and starting Apache

XML Document Example

The Difference Between XML and HTML

XML is Just Plain Text

XML is Just Plain Text

XML essentially establishes a platform-neutral

XML is Not a Replacement for HTML

An element is used to describe or contain a piece of

Elements consist of two tags: an opening tag and a

XML Elements vs. Attributes

There are no rules about when to use attributes and

More about an Element

Tag names are case sensitive.

Every opening tag must have a corresponding closing tag

A nested tag pair cannot overlap another tag.

In XML, all elements must be properly nested within each

In the example above, "Properly nested" simply means that

Attribute values must appear within quotes.

Every document must have a root element.

XML documents must contain one element that is the

This element is called the root element.

Every XML document must contain a root element,

Special Symbols in XML

Less than symbol (<)&lt;

The XML Declaration

Selecting an XML Editor

Viewing Your XML Document

In this example the content of the copyright entity are

Less-than symbol (<)

Greater-than symbol (>)

Quote symbol (")

Apostrophe symbol (')

Ampersand symbol (&)

Another important way to look at entities

Internal entities are stored within the document that

Validity (Valid XML document)

3.1.2. DTDs and Schemas

Basics of DTDs and Schemas

Address Book XML Document

<friend firstName="ann" lastName="perera" age="29">

Document Type Definitions (DTDs)

XML Schema (XSDs)

Basics of creating a DTD

External DTD Declaration

<!ELEMENT address (name,no,street,city,country)>

The example above declares that the child

The * sign in the example above declares that

The ? sign in the example above declares that

The example above declares that the "note"

The example above declares that the "note"

The value is character data

The value must be one from an

The value is an entity

The value is a predefined xml value

The default value of the attribute

Less than symbol (<)<