Example code - Yimg

gasownerΔιαχείριση Δεδομένων

31 Ιαν 2013 (πριν από 4 χρόνια και 11 μήνες)

188 εμφανίσεις

WAM


UNIT
-
II

Page
1

of
35


UNIT


II


Evolution of Enterprise Application Frameworks:


The main reasons for the evolution of enterprise application frameworks are listed below:


• Need to attune new technologies especially improvements on web technologies


• Need to handle complex low level details inherent in enterprise applications like

security, transaction processing and multi
-
threading.


• Evolution and popularity of widely accepted concepts like n
-
tier architectures and

component based software deve
lopment
.

An
enterprise architecture (EA)

is a rigorous description of the
structure

of an
enterprise
,
which comprises
enterprise components

(
business entities
), the externally visible properties of
those components, and the relationships (e.g. the
behavior
) between them. EA describes the
terminology, the composition of
enterprise components
, and their relationships with the external
environment, and the guiding principles for the
requirement (analysis)
,
design
, and evolution of
an enterprise.
[1]
[2]
[3]

This description is comprehensive, including enterprise goals,
business
process
, roles, organizational structures, organizational behaviors
,
business information
,
software
applications

and
computer systems
.

Practitioners of EA call themselves "
enterprise architects
." An enterprise architect is a person
responsible for

developing the enterprise architecture and is often called upon to draw
conclusions from it. By producing an enterprise architecture, architects are providing a tool for
identifying opportunities to improve the enterprise, in a manner that more effectivel
y and
efficiently pursues its purpose.

The scope of an enterprise architecture

The term "enterprise" is used because it is generally applicable in many circumstances, including



Public or Private Sector organizations



An entire business or corporation



A part

of a larger enterprise (such as a business unit)



A conglomerate of several organizations, such as a joint venture or partnership



A multiply
-
outsourced business operation

The term enterprise includes the whole complex, socio
-
technical system
[4]
[5]
, including:



people



information



technology

WAM


UNIT
-
II

Page
2

of
35




The popular and most common four domains and
their component parts look like this:

1.

Business:

1.

Strategy maps, goals, corporate policies,
Operating Model

2.

Functional decompositions (e.g.
IDEF0
,
SADT
), business capabilities and
organizational models expressed as enterprise / line of business architecture

3.

Business processes
, Workflow and Rules that articulate the assigned authorities,
responsibilities and policies

4.

Organization cycles, periods and timing

5.

Suppliers of
hardware
,
software
, and services

2.

Information:

1.

Information architecture

-

a holistic view on the flow of informa
tion in an
enterprise

2.

Data Architecture
-

describes the way data will be processed, stored , data flows
and used by the projects teams that will use it

3.

Master Data Management
, is the authoritative, reliable foundation for data used
across many applications and business processes with the goal to provide a single
view of the truth

no matter where the data is located

WAM


UNIT
-
II

Page
3

of
35


4.

Metadata

-

data that describes your enterprise
data elements

5.

Business Intelligence

Analytics & Reporting BI (Business Intelligence) is a broad
category of applications and technologies for gathering, storing, analyzing, and
p
roviding access to data to help the organization users make better business
decisions. These include the activities of decision support systems, query and
reporting, dashboards , scorecards ,statistical analysis, forecasting, and data
mining. This includes

Reporting Data Stores ( Operational Data Store (ODS),
Datamart and DataWarehouses)

6.

Data Quality helps identify, analyze, improve, and measure the data quality and
data integrity issues and improvement efforts

7.

Data models
: conceptual expressed as enterprise information architectures,
logical, and physical

8.

Data Life Cycle Management Processes to govern how to create, classify, update,
use, distribute, and archive, and obsolete data and i
nformation

9.

Enterprise Architecture Domains Subdomains

3.

Applications:

1.

Application software

inventories and diagrams, expressed as conceptual /
functional or system enterprise / line of busine
ss architectures

2.

Interfaces between applications

-

that is: events, messages

4.

Technology:

1.

Inter
-
application mediating software or 'middlew
are'.

2.

Application execution environments and operating frameworks including
applications server environments and operating systems, authentication and
authorisation environments, security systems and operating and monitoring
systems.

3.

Hardware, platforms, and hosting:
servers
, datacentres and computer rooms

4.

Lo
cal

and
wide area networks
,
Internet

connectivity diagrams

5.

Int
ranet
,
Extranet
,
Internet
,
eCommerce
,
EDI

links with parties within and outside
of the organization

6.

Operating System

7.

Infrastructure

software:
Application servers
,
DBMS

8.

Programming Languages
, etc. expressed as enterprise / l
ine of business
technology architecture.

Several enterprise application frameworks have emerged based on the above listed needs. Some
of the best known examples are:



Java2 Platform Enterprise Edition (J2EE) from Sun Microsystems,



Distributed

internet Appl
ications Architecture (DNA) from Microsoft and



Common Object Request Broker Architecture (CORBA) from Object Management
Group (OMG).

WEB SERVER:



Web

servers are computers on the Internet that host websites, serving pages to viewers
upon request. This ser
vice is referred to as web hosting. Every
web

server

has a unique
WAM


UNIT
-
II

Page
4

of
35


address so that other computers connected to the internet know where to find it on the
vast network. The Internet Protocol (IP) address looks something like this:
69.93.141.146. This address

maps to a more human friendly address, such as
http://www.wisegeek.com.



A
web server

can be referred to as either the hardware (the computer) or the software
(the computer application) that helps to deliver content that can be accessed through the
interne
t. Most people think a web server is just the hardware computer, but a web server
is also referred to as the software computer application that is installed in the hardware
computer.



The most common use of web servers are to host websites but there are oth
er uses like
data storage or for running enterprise applications. There are also different ways to
request content from a web server. The most common request is the Hypertext Transfer
Protocol (HTTP), but there are also other requests like the Internet Mes
sage Access
Protocol (IMAP) or the File Transfer Protocol (FTP)




A web server is a piece of software that enables a website to be viewed using HTTP.
HTTP (HyperText Transfer Protocol) is the key protocol for the transfer of data on the
web. You know when
you're using HTTP because the website URL begins with "http://"
(for example, "http://www.quackit.com").

What is an Application Server


An application server is a software framework, which is dedicated to the efficient execution of
programs, routine or scr
ipts for supporting the construction of various applications. This term
was originally used to describe client server applications and servers, which ran SQL services
and middleware servers, so as to be able to differentiate them from the file servers. It
was later
that the term came to be used in the context of web applications. However, it has evolved into a
more comprehensive service layer. An application server is nothing but a set of components,
which are accessible to the software developer through an

API defined by the platform itself. In
web applications, these components are often in the same machine, as the web server and the
main job is to support the construction of dynamic pages. However, with time, now the
application servers now do not just ta
rget the generation of web pages, but they also implement
WAM


UNIT
-
II

Page
5

of
35


services like clustering, fail
-
over and load balancing. Due to this the developers can focus their
energies on implementing business logic. The term application server is often used in terms of
Java

servers. In such case, the application server behaves like an extended virtual machine for
running applications and handles connections to the database at one side transparently and also
connections to the web client.


What is a Web Server
?


A web server
is a computer program, which delivers content, like web pages, using the
Hyper
Text Transfer Protocol

(HTTP), over the world wide web. The term may also stand for a
computer or a virtual machine, which runs a program. The primary objective of the web server is
to deliver web pages to the clients. Such a delivery consists of
HTML

documents or any
additional content, which may be included in the document, like images, style sheets and
JavaScript
. The communication is initiated by the client, common
ly called as
web browser

or
web crawler. By making request for a specific bit of information using HTTP and the request is
met with a response by the server and the content is sent over. In case
of a problem an error
message is sent back. The server also receives content from clients. Such a feature is often used
for submitting web forms and also for uploading files.


Application Server Vs Web Server
:


Like there is a confusion about
application software vs system software
, there is also
web servers
vs application servers

confusion. The basic difference between web server and application server
is, that the web server serves pages for viewing in a web browser, whereas an application server
gives the required methods, that can be called by the client applications. In other
words, the
HTTP requests are handled by the web servers and the business logic is served to the application
programs, through a number of protocols by the application server. In an application server, a
client can use GUI’s and web servers, whereas in web
servers the client can use HTML or
HTTP. If any functionality is to be added, an application adds the same, however, same is not the
case with web servers.


Web servers do not support or provide the concept of multi
-
threading. However, in application
serve
rs, there are features like connection pooling, isolation pooling, multi
-
threading, etc. The
most common examples of application servers are the Java Application Server, Weblogic Server,
Apache Geronimo, etc. On the other hand, the examples of web servers
are Microsoft IIS,
Apache, etc.


Web server architecture

Principles

Internet, the web, rely on client
-
server architecture. this architecture means that a server offers
web services such as web page, video, music, ..., to one or several clients. The advantage of
client
-
server architecture is that several users located in se
veral places with heterogenous
WAM


UNIT
-
II

Page
6

of
35


software and hardware could communicate and use common resources to collaborate and
cooperate.

Client
-
server architecture relies on the separation between server applications and client
applications. The server hosts heavy i
nfrastructure of application, those which generates all
services. Client hosts only browsing materials of the graphical interface generated by the server,
usually a web browser, a mail client, ...



Web server architecture relies basically on the following principle:



An operating system that manages

hardware resources (the computer) and offers services
to high level applications.



A web server application and a database server application that use op
erating system
services and offers services to high level applications.



A web application that use web server and database server to generate dynamically web
site contents.

WAM


UNIT
-
II

Page
7

of
35




Do I Need A Web Server?



If you maintain your own web site I recommend you
install a web server on your own
development machine.



That way you can configure your development environment to be closer to your live
environment.



Also, if you intend to use server
-
side technologies such as PHP or ColdFusion, you will
definitely need a w
eb server.

Web Servers
-

Advantages

There are many advantages to using a web server within your development environment. Of
course, in a production hosting environment, a web server is essential.


Here are some advantages of using a web server within your development
environment:



Your local

website behaves more like the live one. For example, you can configure
directory security, test your custom error pages etc before commiting them to the
production environment.



You can use server
-
side scripting languages such as PHP and ColdFusion.



Allows

you to standardize your coding. For example, you can use root
-
relative paths
for your image references and hyperlinks (i.e. "/directory/image.gif"). In other words,
WAM


UNIT
-
II

Page
8

of
35


your paths can represent the website structure, rather than the directory structure of
you
r computer.



Knowledge. The knowledge you gain from using your own web server will help you
understand how it works in the live environment. This will most certainly help you
when you need to communicate with your hosting provider
-

you'll be able to use
te
rminology that makes it easier for them to understand your request/issue.

Viewing HTML Files
without

a Web Server
:


Here are some examples of what the URL could look like when viewing a web page
without a web server:



file:///C:/Documents%20and%20Settings/H
omer%20Simpson/My%20Documents/index.
html



file:///C:/Inetpub/wwwroot/index.html

These examples are using the
file

protocol in order to display the files.

Viewing HTML Files
with

a Web Server



One problem with the above method is that, you're not viewing the website using the
HTTP protocol (you're using the
file

protocol instead).



Now, this isn't normally a problem if you're only using client side languages such as
HTML, CSS, and client
-
side Jav
aScript. But it is a problem if you're trying to use a
server
-
side language such as PHP, ColdFusion etc.



Also, even if you're not using a server
-
side language, it could still cause you problems
with developing a website that behaves exactly how it should o
n the web.



When you view a web page via a web server, the URL begins with "
http://
". Also, the
URL will consist of either an IP address or a domain name/host name.

Here are some examples of what the URL could look like when viewing a web page via a
web se
rver:



http://127.0.0.1



http://localhost



http://www.quackit.com



http://dev.quackit.com

When you first set up a web server, you can usually navigate to your default web site using
http://localhost

or
http://127.0.0.1
. When you add more websites, you'll need
to create your own
URLs for them (via a DNS server or Hosts file), then assign that URL to your websites via your
web server



WAM


UNIT
-
II

Page
9

of
35


Web Servers
-

Features



There's a common set
of features that you'll find on most web servers. Because web
servers are built specifically to host websites, their features are typically focussed around
setting up and maintaining a website's hosting environment.



Most web servers have features that
allow you to do the following:



Create one or more websites.



Configure log file settings, including where the log files are saved, what data to
include on the log files etc.



Configure website/directory security.
For example
, which user accounts are/aren't
allowed to view the website, which IP addresses are/aren't allowed to view the
website etc.



Create an FTP site. An FTP site allows users to transfer files to and from the site.



Create virtual directories, and map them to p
hysical directories



Configure/nominate custom error pages. This allows you to build and display user
friendly error messages on your website.
For example
, you can specify which page is
displayed when a user tries to access a page that doesn't exist (i.e. a

"404 error").

IDL:

Interface Definition Language




IDL (interface definition language) is a generic term for a language that lets a program
or object written in one language communicate with another program written in an
unknown language.




An
interface def
inition

language

works by requiring that a program's interfaces be
described in a stub or slight extension of the program that is compiled into it. The stubs in
each program are used by a broker program to allow them to communicate.



IDL (Interactive Data
Language) is a language for creating visualizations based on
scientific or other data.



An
interface description language

(or alternately,
interface definition language
), or
IDL

for short, is a
specification language

used to describe a
software component
's
interface
. IDLs describe an interface in a language
-
neutral way, enabling communication
between
software components

that do no
t share a language


for example, between
components written in
C++

and components written in
Java
.



IDLs are commonly used in
remote procedure call

software. In these cases the machines
at either end of the "link" may be using different
operating systems

and computer
languages. IDLs offer a bridge between the two different systems.



Software systems based on IDLs include
Sun
's
ONC RPC
,
The Open Group
's
Distributed
Computing Environment
,
IBM
's
System Object Model
, the
Object Management Group
's
CORBA
.

Java IDL:


IDL is a standard platform
-
independent declarative language which is used to define
interfaces that object implementations provide and client objects call. Java IDL allows any Java
object to communicate with other objects in any lan
guage by means of IDL.

WAM


UNIT
-
II

Page
10

of
35



DATABASE CONNECTIVITY:

A
database connection

is a facility in
computer science

that allows
client

software to
communicate with
database server

software, whether on the same machine or not. A conne
ction
is required to send
commands

and receive answers.

Connections are a key concept in
data
-
centric

programming. Since some DBMS engines require
considerable time to connect
connection pooling

wa
s invented to improve performance. No
command can be performed against a database without an "open and available" connection to it.

Connections are built by supplying an underlying
driver

or
provider

with a
connection string
,
which is a way of addressing a specific
database

or
server

and instance as well as user
authentication credentials (for example,
Server=
sql_box;
Database=
Common;
User
ID=
uid;
Pwd=
password;
). Once a connection has been built it can be opened and closed at will,
and properties (such as the command time
-
out length, or
transaction
, if one exists) can be
set.
The Connection String is composed of a set of key/value pairs as dictated by the data access
interface and data provider being used.

Databases, such as
PostgreSQL
, only allow one operation to be
performed at a time on each
connection. If a request for data (a
SQL

Select

statement) is sent to the database and a result set

is returned, the connection is open but not available for other operations until the client finishes
consuming the result set. Other databases, like
SQL Server 200
5

(and later), do not impose this
limitation. However, databases that provide multiple operations per connection usually incur far
more overhead than those that permit only a single operation task at a time.

Pooling

Database connections are
finite

and
expensive

and can take a disproportionately long time to
create relative to the operations performed on them. It is very inef
ficient for an application to
create and close a database connection whenever it needs to update a database.

Connection pooling

is a technique designed to alleviate this problem. A pool of database
connections can be created and then shared among the applications that need to access the
database. When an application needs database access, it requests a connection from the pool.
Wh
en it is finished, it returns the connection to the pool, where it becomes available for use by
other applications.

The connection object obtained from the connection pool is often a wrapper around the actual
database connection. The wrapper understands it
s relationship with the pool, and hides the
details of the pool from the application. For example, the wrapper object can implement a "close"
method that can be called just like the "close" method on the database connection. Unlike the
method on the databa
se connection, the method on the wrapper may not actually close the
database connection, but instead return it to the pool. The application need not be aware of the
connection pooling when it calls the methods on the wrapper object.

WAM


UNIT
-
II

Page
11

of
35


Accessing SQL Server an
d Other Databases from SFU 3.5

Microsoft Windows Services For UNIX 3.5 has no built
-
in libraries or interfaces for accessing
relational databases stored on other platforms. Nor is it possible to access a Microsoft SQL
Server database on the same system, ru
nning in the Windows subsystem.

However, there are several packages that can ease this problem. Our Database Tools area
contains recent builds of the following (along with source files and a Readme.Interix with each
source file):



iODBC

-

another popular Open Source ODBC driver manager.


To download, visit the
Tool Warehouse

page.


This page now requires a login name

and password.


If you are
not already a member of our UNIX Tools Community, you can

join here
.



unixODBC

-

a popular O
pen Source ODBC driver manager.


To download, visit the
Tool
Warehouse

page.


This also serves as the ODBC
-
ODBC bridge client from Easysoft,
allowing access to any ODBC driver in Wind
ows. See
Easysoft ODBC
-
ODBC Bridge
.



FreeTDS

-

an Open Source implementation of the Tabular Data Stream protocol used to
a
ccess SQL Server and Sybase databases, including dblib, ctlib and an ODBC driver. To
download, visit the
Tool Warehouse

page.



Perl

-

the latest stable release (5.8.3) of the most popular scripting language, complete
with the DBI database interface module, DBD::ODBC for connecting via ODBC, and
DBD::Sybase to connect to any Sybase or SQL Server using FreeTDS.


To down
load,
visit the
Tool Warehouse

page.

All of these applications and libraries are built with support for threads enabled by default.

Note:

Special thanks to our database consulting p
artner, MSB Associates, for porting these tools,
and thanks to Microsoft for providing the funding.


This is a new page within our UNIX Tools
Community so in keeping with the "community" spirit please post your comments, questions,
examples and bugs in the

new area of the UNIX Tools Forum.


If you require one
-
on
-
one
assistance, please refer to our
Services

page for our telephone and email support packages.

.
Java Database Connectivity (JDBC) API:



JDBC is a set of interfaces which allows Java applications access to any database. This
API has the same purpose as Microsoft’s ODBC.



Java Database Connectivity (JDBC) is a Java based
API

th
at is primarily used in
programming of Java applications for interfacing with various SQL supporting databases
and other data sources such as spreadsheets or flat files.



Java Database Connectivity (JDBC) is one of the Application Program Interface (
API
)
specifications that allow a user to utilize
SQL

for connecting
Java

programs to a
database.



JDBC is a call
-
level interface that allows programmers to write
Java

applications that
execute
SQL

commands on an external database. Using standard library routines, the
Java program connects to the database,
and then

uses JDBC to send queries and update
WAM


UNIT
-
II

Page
12

of
35


code to the database. The program retrieves and processes the results received from the

database in answer to the queries, and then closes the connection to the
database
.



Since Java runs on most platforms, JDBC makes it possible to write a single Java
application th
at will run on multiple platforms and interact with different databases.



JDBC was developed by JavaSoft, a subsidiary of
Sun Microsystems
.

Steps to use JDBC in a
Java Program

1)

The JDBC facilitates the connection to a database through a "Connection object" which is
initiated through a "DriverManager object".

2)

The Connection object is used to create a "Statement object" for SQL query.

3)

The Statement object is used to execute the SQL query to return the results through
"ResultSet object".

4)

Using the ResultSet object, the results of the query can be displayed by looping through
the retrieved record sets.

JDBC Components
:

JDBC is comprised of the following components:



JDBC API






provides programmatic access to relational data from the Java programming
language. Using the JDBC API, applications can execute SQL statements,
retrieve results, and propagate changes back to an
underlying data source. The
JDBC API can also interact with multiple data sources in a distributed,
heterogeneous environment.



(
Note
-
The JDBC API is included in both Java EE (Enterprise Edition) and
Java SE (Standard Edition). The JDBC API (current versio
n 4.0) is part of the
two Java packages
, namely
, java.sql and javax.sql which are available both in
Java EE as well as Java SE
.)





The JDBC API can be used for both two
-
tier as well as three
-
tier processing
models for database access.



JDBC DriverManager c
lass



defines objects which can connect Java applications to a JDBC
driver.



JDBC Test Suite



used to determine that JDBC drivers will run your program.



JDBC
-
ODBC Bridge



provides JDBC access via ODBC drivers. The ODBC binary code
must be loaded onto e
ach client machine that uses this driver.


E
XAMPLE CODE
:

PACKAGE STATEMENTS
:

package com.marks.db;

//IMPORT STATEMENTS

WAM


UNIT
-
II

Page
13

of
35


import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

import org.apache.log4j.Logger;

/**

* This Class is used to create the jdbc connection * and use the query for select, update, delete */

public class DBConnection {

//intialise the Logger for this Class

static Logger mLogger

= Logger.getLogger(DBConnection.class.getPackage().getName());

//this method is used to get Create connection from postgre sql driver

public static Connection getConnection() {

Connection connection = null;

try{

//load the pgsql driver

Class.forName
("org.postgresql.Driver");

System.out.println("Hi Achappan!! your pgsql driver Loaded Successfully");

// create the datasource

String url = "jdbc:postgresql://10.2.0.5:5432/acti"; System.out.println("Print URL " + url);

// register the driver in Driver

Manager and establish the connection from them

connection = DriverManager.getConnection(url, "postgres", "postgres");

System.out.println("Connection Established");

WAM


UNIT
-
II

Page
14

of
35


}

catch(Exception exception)

{

System.out.println(exception.getMessage()); }

return connection;

}

//it is used to close the connection

public static void closeConnection(Connection pConnection)

{

try{

if (pConnection

!= null){ pConnection.close(); pConnection = null;

}

}

catch (Exception e){

System.out.println("Error occured

while closing the exception " + e.getMessage());

} }

/**

* This function is used to Close the statement.

* @param pStatement

*/

public static void closeStatement(Statement pStatement) throws BusinessException

{ try{ if (pStatement

!= null) {

pStatem
ent.close(); pStatement = null; } }

catch (SQLException e) {

WAM


UNIT
-
II

Page
15

of
35


mLogger.error(new StringBuffer("SQLException while trying to closeStatement in DBAccess:
"));

throw new BusinessException("SQLException while trying to closeStatement in DBAccess: " +
e.getMess
age(), e.getStackTrace());

}

}

/** * This function is used to close the resultset. * @param pResultSet */

public static void closeResultSet(ResultSet pResultSet) throws BusinessException

{

try

{

if (pResultSet

!= null)

{ pResultSet.close();

pResultSet = null; }

}

catch (SQLException e) {

mLogger.error(new StringBuffer("SQLException while trying to closeResultSet in DBAccess:
"));

e.printStackTrace();

throw new BusinessException("SQLException while trying to closeResultSet in DBAccess: " +

e.getMessage(), e.getStackTrace());

} }

public static void main(String[] args) { DBConnection.getConnection(); } }

WEB APPLICATION ARCHITECTURE:

long with basic rule services incorporated in any Java application, you can create two major
types of
Web applications
:


Web Services

(business logic)

WAM


UNIT
-
II

Page
16

of
35



Presentation
-
oriented Web Applications

(business and presentation logic
)

Major components of such applications are presented on the following architectu
ral picture:



OpenRules allows you to develop complex Web applications without being an expert in various
Web development techniques. Using the commonly known Excel interface, you can define your
business logic

in a form of Excel
-
based
business rules

and make them available as fine
-
grained
Web services. Then, you may define your
presentation logic

using Excel
-
based
web forms

with
associated
interaction rules
. Being deployed as a presentation
-
oriented Web application, it will
invoke the related rule services whenever necessary. Frequently, such a service
-
oriented
approach to web application development also inv
olves a workflow engine that uses a
publish/subscribe paradigm for automatic invocation of different web services.


Along with basic rule services incorporated in any Java application, you can create two major
types of
Web applications
:


Web Services

(business logic)


Presentation
-
oriented Web Applications

(business and presentation logic
)

Major components of such applications are presented on the following architectu
ral picture:

WAM


UNIT
-
II

Page
17

of
35




OpenRules allows you to develop complex Web applications without being an expert in various
Web development techniques. Using the commonly known Excel interface, you can define your
business logic

in a form of Excel
-
based
business rules

and make them available as fine
-
grained
Web services. Then, you may define your
presentation logic

using Excel
-
based
web forms

with
associated
interaction rules
. Being deployed as a presentation
-
oriented Web application, it will
invoke the related rule services whenever necessary. Frequently, such a service
-
oriented
approach to web application development also
involves a workflow engine that uses a
publish/subscribe paradigm for automatic invocation of different web services.

Here are links to the different OpenRules components that can be available from an Application
Server with OpenRules:


Rule Learner


Rule Engine


Rule Solver


Forms Renderer


Service
-
oriented Web Applications
. A se
rvice
-
oriented Web application implements the
endpoint of a fine
-
grained Web service. If your system is based on
Service
-
oriented architecture
,
you will probably prefer to treat business rules as a speci
al type of loosely coupled web services
that support your decision making processes. We will use the term "
Rule Service
" for business
WAM


UNIT
-
II

Page
18

of
35


rules deployed as a web service. With OpenRules you define and maintain your

business rules
using a combination of Excel, Java, and Eclipse. You may test your rules as a stand
-
alone
application or execute them locally using a simple Java API. However, when you are ready to
integrate your business rules into an enterprise level app
lication, OpenRules provides a "push
-
button" mechanism for deployment of business rules as Web Services.



Presentation
-
oriented Web Applications.

A presentation
-
oriented Web application generates
dynamic Web pages containing various types of markup langua
ge (HTML, XML, and so on) in
response to requests. The most popular Web components are either Java Servlets,
JSP
, Struts or
JSF. They use Java programming language to dynamically process requests and constr
uct
responses in a form text
-
based markup such as HTML and XML. All these techniques are
oriented to experienced software developers that seriously limits business analysts participation
in design and maintenance of business interfaces.



Architecture of web
applications:

While the Web was originally designed to foster collaboration across distributed networks,
stronger requirements, such as fault
-
tolerance, scalability, and peak performance were added
later as a result of leveraging the existing communication mechanisms in

the Web to support
transaction
-
based applications.




The right
-
most elements





the file system,



the application sever



d
ata, and



external systems

are essentially the same as found in traditional client/server systems.

The left
-
most elements




WAM


UNIT
-
II

Page
19

of
35




the b
rowser,



the Web server, and a



gain the file system (in this case, a distributed one)


are elements unique to the Web space.

From the perspective of the user experience, this otherwise physically distributed back
-
end looks
like traditional mainframe comput
ing.

However, there are significant architectural differences owing to the very different mechanisms
that tie these elements together. For example, from the browser to the Web server,
communication is generally stateless, involving the request for, and th
en the delivery of, a Web
page.

Here's the first architectural challenge
:


How

do you preserve the user's session state?



There are a number of alternatives, of which cookies and communication
via IIOP (the Internet Inter
-
Orb Protocol) are the most common.



The placement of the application's business logic represents another
architectural challenge: should it live in the serv
er (the thin client model),
should it live in the client (the fat client/thin server model), or should it be
spread out overall?

In the spectrum of thin to thick client, each alternative has its own advantages and
disadvantages:



a thin client offers simp
licity of security and distribution but makes the browser look
more like a dumb terminal;



a thick client offers greater locality of reference and better interactivity but at the cost of
distribution.



Most systems today tend to push business logic to the s
erver.

NEXT ARCHITECTURAL DESIGN:

Business logic must touch the state of the business. This notion presents the next architectural
challenge. Should there be stateless communication from the logic to the data via mechanisms
such as Java Server Pages (JSP),

or should it be more stat
eful, such as through servlets.

There

are advantages and disadvantages to each approach
.



Scripting is easier to change but comes with computational overhead, and servlets
are potentially faster but more challenging to develop and

deploy.

WAM


UNIT
-
II

Page
20

of
35


Connection to the application's persistence data, which may be bound in legacy systems, also
involves many architectural challenges.



First, how does one give the illusion of objects to the user while data continue
s to
live in relational tables?



Second, how should the connection from the system's busines
s logic to its data be
manifest?


For example, a coupling via JDBC is more direct but requires that the application developer
have intimate knowledge of the data's form. Alternatively, a messaging
architecture is less direct
but is more scalable.

MESSAGING ARCHITECTURE:




A system's
DESIGN VIEW

encompasses the classes, interfaces, and collaborations that
form the vocabulary of the problem and its solution. This view primarily supports the
functional requirements of the system, meaning the services that the system should
provide to its end
-
users.



The
PROCESS VIEW

of a system encompasses the threads and processes that form the
system's concurrency and synchronization mechanisms. This view primarily addresses
the performance, scalability, and throughput of the system.



The
IMPLEMENTATION VIEW

of a s
ystem encompasses the components and files
that are used to assemble and release the physical system. This view primarily addresses
the configuration management of the system's releases. The releases are comprised of
somewhat independent components and fil
es that can be assembled in various ways to
produce a running system.

WAM


UNIT
-
II

Page
21

of
35




The
DEPLOYMENT VIEW

of a system encompasses the nodes that form the system's
hardware topology on which the system executes. This view primarily addresses the
distribution, delivery, and installation of the parts that make up the physical system.



The
USE CASE VIEW

of a syste
m encompasses the use cases that describe the behavior
of the system as seen by its end
-
users, analysts, and testers. This view exists to specify
the forces that shape the system's architecture.


Note
: that

this is where the UML fits in
: the UML is a grap
hical language for
visualizing, specifying, constructing, and documenting the artifacts of a software
-
intensive
system. Thus, it is well suited to express each of these five views

DISTRIBUTABLE WEB
APPLICATIONS:



The J2EE platform provides optional support
for distributed Web applications. A
distributed Web application runs simultaneously in multiple Web containers.



When a Web application is marked
distributable

in its deployment descriptor, the
container may (but is not required to) create multiple instances of the servlet, in multiple
JVM instances, and potentially on multiple machines.



Distributing a servlet improves scalability, because it allows Web request

load to be
spread across multiple servers. It can also improve availability by providing transparent
failover between servlet instances

Java distributed application

Java EE provides a standardized way to enable interactions between distributed applicatio
ns and
disparate information sources.It provides framework for development of distributed applications
and is one of the leading platform for the deployment of Service Oriented
Architecture(SOA)based applications using web services.

Java EE applications ca
n be divided into following application tiers.



Client
-
tier components run on the client machine.



Web
-
tier components run on the Java EE server.



Business
-
tier components run on the Java EE server.



Enterprise information system (EIS)
-
tier software runs on th
e EIS server.

WAM


UNIT
-
II

Page
22

of
35



Above architecture diagram depicts high
-
level distributed application architecture layers.

It uses a distributed multi tiered application model for enterprise applications where application
logic is divided into components according to func
tion, and the various application components
that make up a Java EE application are installed on different machines depending on the tier in
the multi tiered Java EE environment to which the application component belongs.

Since Java EE
-
based applications a
re designed to work together, the enterprise
-
wide adoption of
Java EE makes it easier to create seamless computing environments. This reduces costs for
companies already integrating their distributed systems and processes and enables more
businesses to ach
ieve the benefits of business integration.

Distributed Multitiered Applications

The Java EE platform uses a distributed multitiered application model for enterprise applications.
Application logic is divided into components according to function, and the various application
components that make up a Java EE application are installed o
n different machines depending on
the tier in the multitiered Java EE environment to which the application component belongs.

Distributed Multitiered Applications

The J2EE platform uses a multitiered distributed application model. Application logic is di
vided
into components according to function, and the various application components that make up a
J2EE application are installed on different machines depending on the tier in the multitiered
J2EE environment to which the application component belongs.
Figure 1
-
1

shows two
multitiered J2EE applications divided into the tiers described in the following list. The J2EE
application parts shown in
Figure 1
-
1

are presented in
J2EE Components
.

WAM


UNIT
-
II

Page
23

of
35




Client
-
tier components run on the cl
ient machine.



Web
-
tier components run on the J2EE server.



Business
-
tier components run on the J2EE server.



Enterprise information system (EIS)
-
tier software runs on the EIS server.

Although a J2EE application can consist of the three or four tiers shown in

Figure 1
-
1
, J2EE
multitiered applications are generally considered to be three
-
tiered applications because they are
distributed over three different locations: client
machines, the J2EE server machine, and the
database or legacy machines at the back end. Three
-
tiered applications that run in this way
extend the standard two
-
tiered client and server model by placing a multithreaded application
server between the client a
pplication and back
-
end storage.


Figure 1
-
1 Multitiered Applications


J2EE Components

J2EE applications are made up of components. A
J2EE component

is a self
-
contained functional
software unit that is assembled into a J2EE application with its related
classes and files and that
communicates with other components. The J2EE specification defines the following J2EE
components:



Application clients and applets are components that run on the client.



Java Servlet and JavaServer Pages

(JSP
) technology compon
ents are Web
components that run on the server.

WAM


UNIT
-
II

Page
24

of
35




Enterprise JavaBeans

(EJB
) components (enterprise beans) are business
components that run on the server.

J2EE components are written in the Java programming language and are compiled in the same
way as any

program in the language. The difference between J2EE components and "standard"
Java classes is that J2EE components are assembled into a J2EE application, verified to be well
formed and in compliance with the J2EE specification, and deployed to production
, where they
are run and managed by the J2EE server.

J2EE Clients

A J2EE client can be a Web client or an application client.

Web Clients

A Web client consists of two parts: dynamic Web pages containing various types of markup
language (HTML, XML, and so on), which are generated by Web components running in the
Web tier, and a Web browser, which renders the pages received from the server.

A

Web client is sometimes called a
thin client
. Thin clients usually do not do things like query
databases, execute complex business rules, or connect to legacy applications. When you use a
thin client, heavyweight operations like these are off
-
loaded to en
terprise beans executing on the
J2EE server where they can leverage the security, speed, services, and reliability of J2EE server
-
side technologies.

Applets

A Web page received from the Web tier can include an embedded applet. An applet is a small
client

application written in the Java programming language that executes in the Java virtual
machine installed in the Web browser. However, client systems will likely need the Java Plug
-
in
and possibly a security policy file in order for the applet to successfu
lly execute in the Web
browser.

Web components are the preferred API for creating a Web client program because no plug
-
ins or
security policy files are needed on the client systems. Also, Web components enable cleaner and
more modular application design b
ecause they provide a way to separate applications
programming from Web page design. Personnel involved in Web page design thus do not need to
understand Java programming language syntax to do their jobs.

Application Clients

A J2EE application client run
s on a client machine and provides a way for users to handle tasks
that require a richer user interface than can be provided by a markup language. It typically has a
graphical user interface (GUI) created from Swing or Abstract Window Toolkit (AWT) APIs,
b
ut a command
-
line interface is certainly possible.

WAM


UNIT
-
II

Page
25

of
35


Application clients directly access enterprise beans running in the business tier. However, if
application requirements warrant it, a J2EE application client can open an HTTP connection to
establish commu
nication with a servlet running in the Web tier.

JavaBeans

Component Architecture

The server and client tiers might also include components based on the JavaBeans component
architecture (JavaBeans component) to manage the data flow between an applicatio
n client or
applet and components running on the J2EE server or between server components and a
database. JavaBeans components are not considered J2EE components by the J2EE specification.

JavaBeans components have instance variables and
get

and
set

methods for accessing the data in
the instance variables. JavaBeans components used in this way are typically simple in design and
implementation, but should conform to the naming and design conventions outlined in the
JavaBeans component architecture.

J
2EE Server Communications

Figure 1
-
2

shows the various elements that can make up the client tier. The client communicates
with the business tier running on the J2EE se
rver either directly or, as in the case of a client
running in a browser, by going through JSP pages or servlets running in the Web tier.

Your J2EE application uses a thin browser
-
based client or thick application client. In deciding
which one to use, you

should be aware of the trade
-
offs between keeping functionality on the
client and close to the user (thick client) and off
-
loading as much functionality as possible to the
server (thin client). The more functionality you off
-
load to the server, the easier

it is to distribute,
deploy, and manage the application; however, keeping more functionality on the client can make
for a better perceived user experience.

WAM


UNIT
-
II

Page
26

of
35



Figure 1
-
2 Server Communications


Web Components

J2EE Web components can be either servlets or
JSP pages.
Servlets

are Java programming
language classes that dynamically process requests and construct responses.
JSP pages

are text
-
based documents that execute as servlets but allow a more natural approach to creating static
content.

Static HTML page
s and applets are bundled with Web components during application assembly,
but are not considered Web components by the J2EE specification. Server
-
side utility classes can
also be bundled with Web components and, like HTML pages, are not considered Web
com
ponents.

Like the client tier and as shown in
Figure 1
-
3
, the Web tier might include a JavaBeans
component to manage the user input and send that input to enterprise b
eans running in the
business tier for processing.

Business Components

Business code, which is logic that solves or meets the needs of a particular business domain such
as banking, retail, or finance, is handled by enterprise beans running in the business

tier.
Figure
1
-
4

shows how an enterprise bean receives data from client programs, processes it (if necessary),
and sends it to the enterprise information system tier f
or storage. An enterprise bean also
retrieves data from storage, processes it (if necessary), and sends it back to the client program.

WAM


UNIT
-
II

Page
27

of
35



Figure 1
-
3 Web Tier and J2EE Application



Figure 1
-
4 Business and EIS Tiers


There are three kinds of enterprise beans: session beans, entity beans, and message
-
driven beans.
A
session bean

represents a transient conversation with a client. When the client finishes
executing, the session bean and its data are gone. In contrast, an
entity bean

represents persistent
data stored in one row of a database table. If the client terminates or if the server shuts down, the
underlying services ensure that the entity bean data is saved.


WAM


UNIT
-
II

Page
28

of
35


Figure

1
-
1

shows two multitiered Java EE applications divided into the tiers described in the
following list. The Java EE application parts shown in
Figure

1
-
1

are presented in
Java EE
Components
.



Client
-
tier components run on the client machine.



Web
-
tier components run on the Java EE server.



Business
-
tie
r components run on the Java EE server.



Enterprise information system (EIS)
-
tier software runs on the EIS server.

Although a Java EE application can consist of the three or four tiers shown in
Figure

1
-
1
, Java
EE multitiered applications are generally considered to be three
-
tiered applications because they
are distributed over three locations: client machines, the Java EE server machine, and the
database or legacy machine
s at the back end. Three
-
tiered applications that run in this way
extend the standard two
-
tiered client and server model by placing a multithreaded application
server between the client application and back
-
end storage.



Security

While other enterprise a
pplication models require platform
-
specific security measures in each
application, the Java EE security environment enables security constraints to be defined at
deployment time. The Java EE platform makes applications portable to a wide variety of securit
y
implementations by shielding application developers from the complexity of implementing
security features.

WAM


UNIT
-
II

Page
29

of
35


The Java EE platform provides standard declarative access control rules that are defined by the
developer and interpreted when the application is d
eployed on the server. Java EE also provides
standard login mechanisms so application developers do not have to implement these
mechanisms in their applications. The same application works in a variety of different security
environments without changing th
e source code.

Java EE Components

Java EE applications are made up of components. A
Java EE component

is a self
-
contained
functional software unit that is assembled into a Java EE application with its related classes and
files and that communicates with other components.

The Java EE specification defines the following Java EE components:



Application clie
nts and applets are components that run on the client.



Java Servlet, JavaServer Faces, and JavaServer Pages (JSP) technology components are
web components that run on the server.



Enterprise JavaBeans (EJB) components (enterprise beans) are business compone
nts that
run on the server.

Java EE components are written in the Java programming language and are compiled in the same
way as any program in the language. The difference between Java EE components and
“standard” Java classes is that Java EE components
are assembled into a Java EE application, are
verified to be well formed and in compliance with the Java EE specification, and are deployed to
production, where they are run and managed by the Java EE server.

Java EE Clients

A Java EE client can be a web c
lient or an application client.

Web Clients

A
web client

consists of two parts: (1) dynamic web pages containing various types of markup
language (HTML, XML, and so on), which are generated by web components running in the web
tier, and (2) a web browser,
which renders the pages received from the server.

A web client is sometimes called a
thin client
. Thin clients usually do not query databases,
execute complex business rules, or connect to legacy applications. When you use a thin client,
such heavyweight o
perations are off
-
loaded to enterprise beans executing on the Java EE server,
where they can leverage the security, speed, services, and reliability of Java EE server
-
side
technologies.

Applets

A web page received from the web tier can include an embedded
applet. An
applet

is a small
client application written in the Java programming language that executes in the Java virtual
WAM


UNIT
-
II

Page
30

of
35


machine installed in the web browser. However, client systems will likely need the Java Plug
-
in
and possibly a security policy file f
or the applet to successfully execute in the web browser.

Web components are the preferred API for creating a web client program because no plug
-
ins or
security policy files are needed on the client systems. Also, web components enable cleaner and
more mod
ular application design because they provide a way to separate applications
programming from web page design. Personnel involved in web page design thus do not need to
understand Java programming language syntax to do their jobs.

Application Clients

An
app
lication client

runs on a client machine and provides a way for users to handle tasks that
require a richer user interface than can be provided by a markup language. It typically has a
graphical user interface (GUI) created from the Swing or the Abstract W
indow Toolkit (AWT)
API, but a command
-
line interface is certainly possible.

Application clients directly access enterprise beans running in the business tier. However, if
application requirements warrant it, an application client can open an HTTP connecti
on to
establish communication with a servlet running in the web tier. Application clients written in
languages other than Java can interact with Java EE 5 servers, enabling the Java EE 5 platform to
interoperate with legacy systems, clients, and non
-
Java l
anguages.

The JavaBeans Component Architecture

The server and client tiers might also include components based on the JavaBeans component
architecture (JavaBeans components) to manage the data flow between an application client or
applet and components run
ning on the Java EE server, or between server components and a
database. JavaBeans components are not considered Java EE components by the Java EE
specification.

JavaBeans components have properties and have
get

and
set

methods for accessing the
properties
. JavaBeans components used in this way are typically simple in design and
implementation but should conform to the naming and design conventions outlined in the
JavaBeans component architecture.

RMI (Remote Method Invocaton):

AN OVERVIEW OF RMI APPLICATIO
NS:

RMI applications often comprise two separate programs, a server and a client. A typical server
program creates some remote objects, makes references to these objects accessible, and waits for
clients to invoke methods on these objects. A typical client pro
gram obtains a remote reference
to one or more remote objects on a server and then invokes methods on them. RMI provides the
mechanism by which the server and the client communicate and pass information back and forth.
Such an application is sometimes refe
rred to as a
distributed object application
.

Distributed object applications need to do the following:

WAM


UNIT
-
II

Page
31

of
35




Locate remote objects.

Applications can use various mechanisms to obtain references to
remote objects. For example, an application can register its rem
ote objects with RMI's
simple naming facility, the RMI registry. Alternatively, an application can pass and
return remote object references as part of other remote invocations.



Communicate with remote objects.

Details of communication between remote objec
ts
are handled by RMI. To the programmer, remote communication looks similar to regular
Java method invocations.



Load class definitions for objects that are passed around.

Because RMI enables
objects to be passed back and forth, it provides mechanisms for

loading an object's class
definitions as well as for transmitting an object's data.

The following illustration depicts an RMI distributed application that uses the RMI registry to
obtain a reference to a remote object. The server calls the registry to associate (or bind) a name
with a remote object. The client looks up the remote object b
y its name in the server's registry
and then invokes a method on it. The illustration also shows that the RMI system uses an existing
web server to load class definitions, from server to client and from client to server, for objects
when needed.


Advanta
ges of Dynamic Code Loading
:



One of the central and unique features of RMI is its ability to download the definition of
an object's class if the class is not defined in the receiver's Java virtual machine.



All of the types and behavior of an object, previ
ously available only in a single Java
virtual
machine

can be transmitted to another, possibly remote, Java virtual machine.



RMI passes objects by their actual classes, so the behavior of the objects is not changed
when they are sent to another Java virtual

machine.



This capability enables new types and behaviors to be introduced into a remote Java
virtual machine, thus dynamically extending the behavior of an application.



The compute engine example in this trail uses this capability to introduce new behav
ior to
a distributed program.

Remote Interfaces, Objects, and Methods



Like any other Java application, a distributed application built by using Java RMI is made
up of interfaces and classes. The interfaces declare methods.



The classes implement the methods declared in the interfaces and, perhaps, declare
additional methods as well.

WAM


UNIT
-
II

Page
32

of
35




In a distributed application, some implementations might reside in some Java virtual
machines but not others. Objects with methods that can be i
nvoked across Java virtual
machines are called
remote objects
.


An object becomes remote by implementing a
REMOTE INTERFACE
, which has the
following characteristics:



A remote interface extends the interface
java.rmi.Remote
.



Each method of the interface d
eclares
java.rmi.RemoteException

in its
throws

clause, in
addition to any application
-
specific exceptions.



RMI treats a remote object differently from a non
-
remote object when the object is
passed from one Java virtual machine to another Java virtual mach
ine.



Rather than making a copy of the implementation object in the receiving Java virtual
machine, RMI passes a remote
stub

for a remote object.



The stub acts as the local representative, or proxy, for the remote object and basically is,
to the client, the remote reference.



The client invokes a method on the local stub, which is responsible for carrying out the
method invocation on the remote obje
ct.



A stub for a remote object implements the same set of remote interfaces that the remote
object implements.



This property enables a stub to be cast to any of the interfaces that the remote object
implements.



However,
only

those methods defined in a re
mote interface are available to be called
from the receiving Java virtual machine.

Creating Distributed Applications by Using RMI

Using RMI to develop a distributed application involves these general steps:

1.

Designing and implementing the components of yo
ur distributed application.

2.

Compiling sources.

3.

Making classes network accessible.

4.

Starting the application.

Designing and Implementing the Application Components

First, determine your application architecture, including which components are local objec
ts and
which components are remotely accessible. This step includes:



Defining the remote interfaces.



A remote interface specifies the methods that can be invoked remotely by a client.
Clients program to remote interfaces, not to the implementation class
es of those
interfaces. The design of such interfaces includes the determination of the types of
objects that will be used as the parameters and return values for these methods. If any of
these interfaces or classes do not yet exist, you need to define the
m as well.

WAM


UNIT
-
II

Page
33

of
35




Implementing the remote objects.



Remote objects must implement one or more remote interfaces. The remote
object class may include implementations of other interfaces and methods that are
available only locally. If any local classes are to be
used for parameters or return values
of any of these methods, they must be implemented as well.



Implementing the clients.



Clients that use remote objects can be implemented at any time after the remote
interfaces are defined, including after the remote objects have been deployed.

MARK UP LANGUAGE:

What Is a Markup Language?

A markup language is a combination of words and symbols which give instructions on how a
document should appear. For example, a tag may indicate that words are written in italics or bold
type. Although the most common and most widely used markup
languages

are written for
computers, the concept of a markup language is not limited to
computer

programming.

Types
:



Markup Language



Document Markup Language



Css Markup Language



Extensible Markup Language Xml



Extended Markup Language



Hyper Markup Language



Markup Language Definition

A
well
-
known example

of a markup language in widespread use today is
HyperText

Markup
Language (
HTML
), one of the document forma
ts of the
World Wide Web
. HTML is mostly an
instance of
SGML

SGML:



In the early 1980s, the idea that markup should be focused on the struc
tural aspects of a
document and leave the visual presentation of that structure to the interpreter led to the
creation of SGML. .



SGML specified a syntax for including the markup in documents, as well as one for
separately describing what tags were allowed
, and where (
DTD
) or
schema
.



Thus, SGML is properly a
meta
-
language
, and many particular markup languages are
derived from it.



SGML found wide acceptance and use in fields with very large
-
scale documentation
requirements.

WAM


UNIT
-
II

Page
34

of
35




However, i
t was generally found to be cumbersome and difficult to learn, a side effect of
attempting to do too much and be too flexible.
]
.

HTML
:



By 1991, it appeared to many that SGML would be limited to commercial and data
-
based
applications
.



It leads to create

HTML
. HTML resembles other SGML
-
based tag languages, although it
began as simpler than most and a formal DTD was not developed until later.



HTML's use of descriptive markup was a major factor in th
e success of the Web, because
of the flexibility and extensibility that it enabled



. HTML is quite likely the most used markup language in the world today.

XML
:



XML (Extensible Markup Language) is a meta markup language that is now widely used.



The main
purpose of XML was to simplify SGML by focusing on a particular problem


documents on the Internet.
[9]



XML remains a meta
-
language like SGML, allowing users to create any tags n
eeded
(hence "extensible") and then describing those tags and their permitted uses.



XML adoption was helped because every XML document can be written in such a way
that it is also an SGML document, and existing SGML users and software could switch to
XML f
airly easily.



However, XML eliminated many of the more complex and human
-
oriented features of
SGML to simplify implementation environments such as documents and publications
.



XML is now widely used for communicating
data

between applications. Like HTML, it
can be described as a 'container' language.

XHTML
:



Since January 2000 all
W3C Recommendations

for HTML have been based on XML
rather than SGML, using the abbreviation
XHTML

(
E
x
tensible
H
yper
T
ext
M
arkup
L
anguage
).



The language specification requires that XHTML Web do
cuments must be
well
-
formed

XML documents


this allows for more rigorous and robust documents while using tags
familiar from HTML.



One of the most noticeable differences between HTML and XHTML is the rule that
all
tags must be closed
:

empty HTML tags such

as
<br>

must either be
closed

with a
regular end
-
tag, or replaced by a special form:
<br

/>

(the space before the '
/
' on the end
tag is optional, but frequently used because it enables some pre
-
XML Web browsers, and
SGML parsers, to accept the tag). Anoth
er is that all
attribute

values in tags must be
quoted. Finally, all tag and attribute names must be lowercase in order to be valid;
HTML, on the other hand, was case
-
insensitive.

WAM


UNIT
-
II

Page
35

of
35


Other XML
-
Based Applications:

Many XML
-
based applications now exist, including
Resource Description Framework

(RDF),
XForms
,
DocBook
,
S
OAP

and the
Web Ontology Language

(OWL). For a partial list of these
see
List of XML markup languages
.