Unit 4 - Final

Copyright :IT ENGG PORTAL www.itportal.
in

1
Software Architecture Styles
One interesting theory of problem-solving in the programming domain states that programmers solve such
problems using programming plans, program fragments that correspond to stereotypical actions, and rules that
describe programming conventions. For example, to compute the sum of a series of numbers, a programmer
uses the running total loop plan. In this plan, some counter is initialized to zero and incremented with the next
value of a series in the body of the loop. Experts tend to recall program fragments that correspond to plan
structures before they recall other elements of the program. This nicely maps onto the idea that knowledge is
stored in human memory in meaningful units or 'chunks'.
An expert programmer has at his disposal a much larger number of knowledge chunks than a novice
programmer. This concerns both programming knowledge and knowledge about the application domain. Both
during the search for a solution and during program comprehension, the programmer tries to link up with
knowledge arleady present. As a corollary, part of our education as programmer or software engineer should
consist of acquiring a set of useful knowledge chunks.
At the level of algorithms and abstract data types, such a body of knowledge has been accumulated over the
years, and has been codified in text books and libraries of reusable components. As a result, abstractions, such
as Quicksort, embodied in procedures and abstract data types, such as Stack and Binary Tree, have become
part of our vocabulary and are routinely used in our daily work.
The concepts embodied in these abstractions are useful during the design, implementation and maintenance of
software for the following reasons:
They can be used in a variety of setting and can be given unique names. The names are used in
communicating the concepts and serve as labels when retrieving and storing them in human memory.
The label Quicksort rings the same bell for all people working in our field.
We have notations and mechanisms to support their use and reuse, such as procedure calls and the
module concept.
We have organized related concepts into semantic networks that can be searched for an item that fits the
problem at hand. For example, we know the time and space tradeoffs between Quicksort and
Bubblesort, or between standard binary search tree and an AVL tree, and we know the grounds on
which to make a choice.
Design patterns are collections of a few modules, or classes, which are often used in combination, and which
together provide a useful abstraction. A design pattern is a recurring solution to a standard problem. The
prototypical example of a pattern is the MVC or Model-View-Controller pattern known from Smalltalk. We
may view design patterns as micro-architectures.
Two further notions often used in this context are application framework and idiom. An application
framework is a semi-finished system which needs to be instantiated to obtain a complete system. It describes the
architecture of a family of similar systems. It is thus tied to a particular application domain. The best known
examples are frameworks for building user interfaces. An idiom is a low-level pattern, specific to some
programming language. For example, the Counted Pointer idiom can be used to handle references to objects
dynamically created in C++. It keeps a reference counter which is incremented or decremented when references
to an object are added or removed. Memory occupied by an object is freed if no references to that object remain,
i.e. when the counter becomes zero. Frameworks and idioms thus offer solutions that are more concrete and
language specific than the architectural styles or design patterns.
The work in the area of software architecture and design patterns has been strongly influenced by the ideas of
the architect Christopher Alexander, as formulated in his books The Timeless Way of Building and A Pattern
Language. The term pattern derives from Alexander's work, and the format used to describe software
architectural styles and design patterns is shaped after the format Alexander used to describe his patterns, like
Copyright :IT ENGG PORTAL www.itportal.in

2
alcove, office connection, or public outdoor room. In software engineering, we often draw a parallel with other
engineering disciplines, in particular civil engineering. This comparison is made to highlight both similarities,
such as the virtues of a phased approach, and differences, such as the observation that software is logical rather
than phsyical, which hampers the control of progress. The comparison with the field of architecture is often
made to illustrate the role of different views, as expressed in the different types of blueprint produced. Each of
these blueprints emphasizes a particular aspect.
The classical field of architecture provides some further interesting insights for software architecture. These
insights concern:
The notion of architectural style.
The relationship between style and engineering.
the relationship between style and materials.
Architecture is a formal arrangement of architectural elements. An architectural style abstracts from the
specifics of an architecture. The decomposition library system might, for instance, result in architecture
consisting of one main program and four subroutines, sharing three data stores. If we abstract from these
specifics, we obtain its architectural style, in which we concentrate on the types of its elements and their
interconnections.
Viewed in this way, an architectural style describes a certain codification of elements and their arrangements.
Conversely, an architectural style constrains both the elements and their interrelationships. For example, the
Tudor style describes how a certain type of house looks and also prescribes how its design should look. In a
similar vein we may characterize a software architectural style such as, say, the pipes-and-filter style.
Different engineering principles apply to different architectural styles. This often goes hand in hand with the
types of material used. Cottage-style houses and high-rise apartments differ in the materials used and the
engineering principles applied. A software design based on the abstract types (=material) emphasizes separation
of concerns by encapsulating secrets (=engineering principle). A design based on pipes and filters emphasizes
bundling of functionality in independent processes.
When selecting a certain style with its corresponding engineering principles and materials, we are guided by the
problem to be solved as well as the larger context in which the problem occurs. We cannot build a skyscraper
from wooden posts. Environmental regulations may prohibit us from erecting high-rise buildings in rural areas.
And, the narrow frontages of many houses on the Amsterdam canals are partly due to the fact that local taxes
were based on the number of street-facing windows. Similar problem-specific and context-specific elements
guide us in the selection of a software architectural style.
These similarites between classical architecture and software architecture provide us with clues as to what
constitutes a software architectural style and what its description should look like.
In his book A Pattern Language, the architect Christopher Alexander presents 253 patterns, ranging in scale
from how a city should look down to rules for the construction of a porch. Perhaps his most famous pattern is
about the height of buildings:
"There is abundant evidence to show that high buildings make people crazy. High buildings have no genuine
advantage, except in speculative gains to banks and land owners. They are not cheaper, they do not help create
open space, they make life difficult for children, they are expensive to maintain, they wreck the open spaces
near them, and they damage the light and air and view. But quite apart from this, empirical evidence shows that
they can actually damage people's minds and feelings.
In any urban area, no matter how dense, keep the majority of buildings four stories or less. It is possible that
certain buildings should exceed this limit, but they should never be buildings for human habitation."
An Alexandrian pattern is not a cookbook, black box recipe for architects, any more than a dictionary is a
toolkit for a novelist. Rather, a pattern is a flexible generic scheme providing a solutiong to a problem in a given

3
context. In a narrative form, its application looks like this:
IF you find yourself in <context>, for example <examples>, with <problem>,
THEN for some <reasons>, apply <pattern> to construct a solution leading to a <new context> and <other
patterns>.
The above Four Story Limit pattern may for example be applied in a context where one has to design a suburb.
The citation gives some of the reasons for applying this pattern. If it is followed, it will give rise to the
application of other patterns, such as those for planning parking lots, the layout of roads, or the design of
individiual houses.
A number of well-known software architectural styles are often in a framework that resembles a popular way of
describing design patterns. Both the characterization and the framework are framed after Alexander's way of
describing patterns. We will use this framework to describe a number of well-known and classic architectural
styles. The framework has the following entries:
Problem A description of the type of problem this style addresses. Certain characteristics of the
requirements will guide the designer in his choice of a particular style. For example, if the problem
consists of a series of independent transformations, a pipes-and-filter type of architecture suggests itself.
Context A designer will be constrained in the use of a style by certain characteristics of the
environment. Or, to put it the other way around, a style imposes certain requirements on the
environment. For example, the pipes-and-filter style usually relies on operating system support for data
transfer between filters.
Solution A description of the solution chosen. The major elements of a software architecture are
components and connectors. Components are the building blocks of a software architecture. They
usually embody a computational element of some sort (like a procedure), but a component can also be a
data store (such as a database). The connectors describe how components interact. Some typical types of
component and connector are given in Tables 6 & 7.
Table 6 - Component Types
Type Description
Computational
The component performs a computation of some sort. Usually, the input and output to
the component may have a local state, but this state disappears after the component
has done its job. Example components of this type are mathematical functions and
filters.
Memory
A memory component maintains a collection of persistent, structured data, to be
shared by a number of other components. Examples are a database, a file system, or a
symbol table.
Manager
A manager component contains a state and a number fo associated operations. When
invoked, these operations use or update the state, and this state is retained between
successive invocations of the manager's ooperations. Abstract data types and servers
are example componetns of the manager type.
Controller
A controller governs the time sequence of other events. A top-level control module
and a scheduler are examples of a controller type.

4

Table 7 - Connector Types
Type Description
Procedure
Call
With this type of connector, there is a single thread of control between the caller and the
called component. Control is transferred to the component being called, and this
component remains in control until its work has ended. Only then is control transferred
back to the calling component. The traditional procedure call and the remote procedure
call are examples of this type of connector.
Data Flow
With a data flow connector, processes interact through a stream of data, as in pipes. The
components themselves are independent. Once input data to a component is available, it
may continue its work.
Implicit
Invocation
With implicit invocation, a computation is invoked when a certain event occurs, rather
than by explicit interaction, as in a procedure call. Components raising events do not
know which component is going to react and invoked components do not know which
component raised the event to which they are reacting.
Message
Passing
Message passing occurs when we have independent processes that interact through
explicit, discrete transfer of data, as in TCP/IP. Message passing can be synchronous, in
which case the sending/receiving process is blocked until the message has been
completely sent/received, or asynchronous, in which case the processes continue their
work independently.
Shared data
When using shared data connectors, components operate concurrently on the same data
space, as in blackboard systems or multiuser databases. Usually, some blocking scheme
prevents concurrent writes to the same data.
Instantiation
With Instantiation, one component (the instantiator) provides space for the state
required by another component (the instantiated), as in abstract data types.
The order of execution of components is governed by the control structure. The control structure captures how
control is transformed during execution.
The choice of components and connectors is not independent. Usually, a style is characterized by a combination
of certain types of component and connector, as well as a certain control structure. The system model captures
the intuition behind such a combination.
Architectural styles give a rather general description. Variants are specializations which differ from the general
style.
Examples are references to real examples of a style. Architectural styles do not stem from theoretical
investigations, but result from identifying and characterizing best practice.


5
Tables 8 through 13 contain descriptions of six well-known architectural styles:
1. A Main Program with Subroutines
2. An abstract data type
3. Implicit Invocation
4. Pipes and Filters
5. Repository
6. Layered
Main Program with Subroutines Architectural Style
In the main program with subroutines architectural style, the main tasks of the system, are allocated to different
components, which are called, in the appropriate order, from a control component. The decomposition is
strongly geared towards an ordering of the various actions to be performed with respect to time. The top-level
component controls this ordering.

Table 8 - Style: Main Program with Subroutines
Problem
The system can be described as a hierarchy of procedure definitions. This style is a natural
outcome of a functional decomposition of a system. The top level module acts as the main
program. Its main task is to invoke the other modules in the correct order. As a
consequence, there is usually a single thread of control.
Context
This style naturally fits in with programming languages that allow for nested definitions of
procedures and modules.
Solution
System Module Procedures and modules are defined in a hierarchy. Higher level modules
call lower-level modules. The hierarchy may be strict, in which case modules at level n can
only call modules at level n-1, or it may be weak, in which case modules at level n may
call modules at level n-i, with i1. Procedures are grouped into modules following such
criteria as coupling and cohesion.
Components Groups of procedures, which may have their own local data, and global data
which may be viewed as residing in the main program.
Connectors Procedure call and shared access to data.
Control Structure There is a single, centralized thread of control, the main program pulls
the strings.
Variants
This style is usually applied to systems running on one CPU. Abstractly, the model is
preserved in systems running on multiple CPUs and using the Remote Procedure Call
mechanism to invoke the processes.

Abstract Data Type Architectural Style
Components in the main program with subroutines type of decomposition often use shared data storage.
Decisions about data representations, then, are a mutual property of the components that use the data. We may
also try to make those decisions locally rather than globally. In that case, the user does not get direct access to
the data structures, but is offered an interface. The data can only be accessed through appropriate procedure or

6
method calls. This is the essence of the Abstract Data Type Architectural Style.
Table 9 - Architectural Style: Abstract Data Type
Problem
A central issue is to identify and protect related bodies of information. The style is
especially suited for cases where the data representation is likely to change during the
lifetime of the system. When the design matches the structure of the data in the problem
domain, the resulting components encapsulate problem-domain entities and their
operations.
Context
Many design methods, most notably the object-oriented ones, provide heuristics to identify
real-world objects. These objects are then encapsulated in components of the system.
Object-oriented programming languages provide the class concept, which allows us to
relate similar objects and reuse code through the inheritance mechanism.
Solution
System Model Each component maintains its own local data. Components hide a secret -
their representation of data.
Components The components of this style are managers, such as servers, objects and
abstract data type.
Connectors Operations are invoked through procedure calls - messages.
Control Structure Their is usually a single thread of control. Control is decentralized,
however, a component may invoke any components whose services it requires.
Variants
Methods or languages that are not object-oriented only allow us to hide data
representations in modules. Object-oriented methods or languages differ as regards to their
facilities for relating similar objects (single or multiple inheritance) and their binding of
messages to operations (at compile time or run time).

Implicit Invocation Architectural Style
A major advantage of abstract data types over shared data is that changes in data representation and algorithms
can be accomplished relatively easily. Changes in functionality, however, may be much harder to realize. This
is because method invocations are explicit, hard-coded in the implementation. An alternative is to use the

Implicit Invocation Style.


7
Table 10 - Architectural Style: Implicit Invocation
Problem
We have a loosely coupled collection of components each of which carries out some task
and may enable other operations. The major characteristics of this style is that it does not
bind recipients of signals to their originators. It is especially useful for applications that
need to be able to be reconfigured, by changing a service provider or by enabling and
disabling operations.
Context
This style usually requires an event handler that registers components' interests and notifies
others. Because of the intrinsically decentralized nature of systems designed this way,
correctness arguments are difficult. For the same reason, building a mental model of such
systems during program comprehension is difficult, too.
Solution
System Model Processes are independent and reactive. Processes are not invoked
explicitly, but implicitly through the raising of an event.
Components Components are processes that signal events without knowing which
component is going to react them. Conversely, processes react to events raised somewhere
in the system.
Connectors Connectors are connected through the automatic invocation of processes that
have registered interest in certain events.
Control Structure Control is decentralized. Individual components are not aware of the
recipients of signals.
Variants
There are two major categories of systems exploiting implicit invocation. the first category
comprises so-called tool-integration frameworks as exemplified by many software
development support environments. They consist of a number of 'toolies' running as
separate processes. Events are handled by a separate dispatcher process which uses some
underlying operating system support such as UNIX sockets. The second category consists
of languages with specialized notations and support for implicit invocation, such as when
updated features of some object-oriented languages.

In implicit invocation, a component is not invoked explicitly. Instead, an event is generated. Other components
in the system may express their interest in this event by associating a method with it; this method is
automatically invoked each time the event is raised. Functional changes can be realized easily by changing the
list of events that components are interested in.
Pipes And Filters Architectural Style
Some applications consist of a series of components in which component i produces output which is read and
processed by component i+1, in the same order in which it si written by component i. In such cases, we need not
explicitly create these intermediate data structures. Rather, we may use the pipe-and-filter method of operation
that is well known from UNIX, and directly feed the output of one transformation into the next one. The
components are called filters and the FIFO connectors are called pipes.


8
Table 11 - Architectural Style: Pipes and Filters
Problem
A series of independent sequential transformations on ordered data. Usually, the
transformations are incremental. Often, the structure of the datastreams is very simple: a
sequence of ASCII characters. If the data has a rich structure, this will imply quite some
overhead for the parsing and unparsing of the data.
Context
This style requires that the system can be decomposed into a series of computations,
filters, that incrementally transform one or more input streams. It usually relies on
operating system operations to transfer the data from one process to another (pipes). Error
handling is difficult to deal with uniformly in a collection of filters.
Solution
System Model The resulting systems are characterized by continuous data flow between
components, where the components naturally transform datastreams.
Components The components are filters that perform local processing; i.e. they read part
of their input data, transform the data, and produce part of their output. They have little
internal state.
Connectors Datastreams (usually plain ASCII, as in UNIX).
Control Structures Data flow between components. Each component usually has its own
thread of control.
Variants
Pure filters have little internal state and process their input locally. In the degenerate case,
they consume all of their input before producing any output. In that case, the result boils
down to a batch-processing type of stream.

An important characteristic of this scheme is that any structure imposed on the data to be passed between
adjacent filters has to be explicitly encoded in the datastream that connects these filters. This encoding scheme
involves decisions which must be known to both filters. The data has to be unparsed by one filter while the next
filter must parse its input in order to rebuild that structure. The Achille's heel of the pipes-and-filters scheme is
error handling. if one filter detects an error, it is cumbersome to pass the resulting error message through
intermediate filters all the way to the final output. Filters must also be able to resynchronize after an error has
been detected and filters further downstream must be able to tolerate incomplete input.
Repository Architectural Style
The repository style fits situations where the main issue is to manage a richly structured body of information. In
the library example in the section on Requirements Engineering, the data concerns such things as the stock of
available books and the collection of members of the library. The data is persistent and it is important that it
always reflects the true state of affairs. A natural approach to this problem is to devise database schemas for the
various types of data in the application and store the data in one or more databases. The functionality of the
system is incorporated in a number of, relatively independent, computational elements. The result is a repository
architectural style.


9
Table 12 - Architectural Style: Repository
Problem
The central issue is maintaing a richly structured body of information. The information
must typically be manipulated in many different ways. The data is long-lived and its
integrity is important.
Context
This style often requires considerable support, in the form of a run-time system augmented
with a database. Data definitions may have to be processed to generate support to maintain
the correct structure of the data.
Solution
System Model: The major characteristics of this model is its centralized, richly structured
body of information. The computational elements acting upon the repository are often
independent.
Components: There is one memory component and many computational processes.
Connectors: Computational units interact with the memory components by direct access
or procedure call.
Control Structure The control structure varies. In traditional database systems, for
example, control depends on the input to the database functions. In a modern compiler,
control is fixed: processes are sequential and incremental. In blackboard systems, control
depends on the state of the computation.
Variants
Traditional database systems are characterized by their transaction-oriented nature. The
computational processes are independent and triggered by incoming requests. Modern
compilers, and software development support environments, are systems that increment the
information contained in the repository. Blackboard systems have their origin in AI. They
have been used for complex applications such as speech recognition, in which different
computational elements each solve part of the problem and update the information on the
blackboard.

Modern compilers are often structured in a similar way. Such a compiler maintains a central representation of
the program to be translated. A rudimentary version of that representation results from the first, lexical, phase: a
sequence of tokens rather than a sequence of character glyphs. Subsequent phases, sucy as syntax and semantic
analysis, further enrich this structure into, for example, an abstract syntax tree. In the end, code is generated
from this representation. Other tools, such as symbolic debuggers, pretty-printing programs or static analysis
tools, may also employ the internal representation built by the compiler. The resulting architectural style again
is that of repository: one memory component and a number of computational elements that act on the
repository. Unlike the database variant, the order of invocation of the elements matters in the case of a compiler.
Also, different computational elements enrich the internal representation, rather than merely update it.
The repository architectural style can also be found in certain AI applications. In computationally complex
applications, such as speech recognition, an internal representation is built and acted upon by different
computational elements. For example, one computational element may filter noise, another one builds up
phenomes, etc. The internal representation in this type of system is called a blackboard and the architecture is
sometimes referred to as a blackboard architecture. A major difference with traditional database systems is that
the invocation of computational elements in a blackboard architecture is triggered by the current state of the
blackboard, rather than by external inputs. Elements from a blackboard architecture enrich and refine the state

1
0
representation until a solution is found.
Layers Architectural Style
The final example of an architectural style is the layered architectural style. A prototypical instance is the ISO
Open System Interconnection Model for network communication. It has seven layers:
1. Physical
2. Data
3. Network
4. Transport
5. Session
6. Presentation
7. Application
The bottom layer provides basic functionality. Higher layers use the functionality of lower layers. The different
layers can be viewed as virtual machines whose 'instructions' become more powerful and abstract as we go from
lower layers to higher layers.

Table 13 - Architectural Style: Layers
Problem
We can identify distinct classes of services that can be arranged hierarchially. The system
can be depicted as a series of concentric circles, where services in one layer depend on
services from inner layers. Quite often, such a system is split into three layers:
1. Basic Services
2. General Utilities
3. Application Specific Utilities
Context
Each class of service has to be assigned to a specific layer. It may occasionally be difficult
to properly identify the function layer succinctly and, as a consequence, to assign a given
function to the most appropriate layer. This holds the more if we restrict visibility to just
one layer.
Solution
System Model: The resulting system consists of a hierarchy of layers. Usually, visibility
of inner layers is restricted.
Components: The components in each layer usually consist of collections of procedures.
Connectors: Components generally interact through procedure calls. Because of the
limited visibility, the interaction is limited.
Control Structure: The system has a single thread of control.
Variants
A layer may be viewed as a virtual machine, offering a set of 'instructions' to the next
layer. Viewed this way, the peripheral layers get more and more abstract. Layering may
also result from a wish to separate functionality, e.g. user interface layer or application
logic layer. Variants of the layered scheme may differ as to the visibility of components to
outer layers. In the most constrained case, visibility is constrained to the next layer up.

1
1

In a layered scheme, by definition, lower levels cannot use the functionality offered by higher levels. However,
the other way around, the situation is more varied. We may choose to allow layer n to use the functionality of
each layer m, with m < n. We may also choose to limit the visibility of functionality offered by each layer, and
for example restrict layer n to use only the functionality offered by layer n-1. A Design issue in each case is
how to assign functionality to the different layers of the architecture, i.e. how to characterize the virtual machine
it embodies. If visibility is not restricted, some of the elegance of the layered architecture gets lost. This
situation resembles that of programming languages containing low-level bit manipulation operations alongside
WHILE statements and procedure calls. If visibility is restricted, we may end up copying functionality to higher
levels without increasing the level of abstraction.
Using an example of a layered architectural style for use in telecommunications. It can be seen that layers do
not necessarily correspond to different layers of abstraction. Rather, the functionality of the system has been
separated. Two main guidelines drive the assignment of functionality to layers in this architecture:
1. Hardware dependent functionality should be placed in lower level layers than application dependent
functionality.
2. Generic functionality should be placed in lower layers than specific functionality.
The resulting architecture has four layers:
1. Operating System: This layer comprises the runtime system, database, memory management and so on.
2. Equipment Maintenance: This layer houses the control for peripheral devices and its interconnection
structure. It deals with such things as data distribution and fault-handling of peripheral hardware. The
bottom two layers togethre constitute the distributed operating infrastructure upon which applications
run.
3. Logical-Resource Management: Logical resources can be divided into two classes. The first class
constrains abstractions from hardware objects. The second class consists of software-related logical
objects, such as those for call-forwarding in telephony.
4. Service Management: This layer contains the application functionality.
A similar line of thought can be followed in other domains. For instance, it is hard to predict how future
household equipment will be assembled into hardware boxes. Will the PC and the television have the same box?
Will the television and the DVD player be combined or will they remain as separate boxes? No one seems to
know. Since the half-life of many of these products is about six months, industry is forced to use a building-
block approach, emphasizing reuse and the development of product families rather than products. A division of
functionality into a hardware-related inner layer, a generic signal processing layer, and a user-oriented service
layer suggests itself. The above architecture for telecommunications applications can be understood along the
same lines.
In practice, we will usually encounter a mixture of architectural styles. For example, many software
environments can be characterized as a combination of the repository and layered architectural styles. The core
of the system is a repository in which the various objects, ranging from program texts to work-breakdown
structures, reside. Access to these objects as well as basic mechanisms for the execution and communication of
tools are contained in a layer on top of this repository. The tools themselves are configured in one or more
layers on top of these basic layers. Interaction between tools may yet follow another paradigm, such as implicit
invocation.


1
2
Introduction to 3-Tier Architecture
Introduction
As a developer, the .NET framework and Visual Studio present many choices for choosing the
right architecture, from placing the data access code directly in the UI through datasets and data
source controls, to creating a data access layer that talks to the database, all the way to creating an n-
tier architecture approach that consists of multiple layers, and use data-transfer objects to pass data
back and forth.
If youve ever wondered why you should use layers and what the benefits are, this article is for you.
This article delves into the use of layers and how they can benefit any application.
What is a Layer?
A layer is a reusable portion of code that performs a specific function. In the .NET environment, a
layer is usually setup as a project that represents this specific function. This specific layer is in charge
of working with other layers to perform some specific goal. In an application where the presentation
layer needs to extract information from a backend database, the presentation would utilize a series of
layers to retrieve the data, rather than having the database calls embedded directly within itself. Lets
briefly look at the latter situation first.
Two-Tier Architecture
When the .NET 2.0 framework became available to the world, there were some neat features
that allowed the developer to connect the frameworks GUI controls directly to the database.
This approach is very handy when rapidly developing applications. However, its not always
favorable to embed all of the business logic and data access code directly in the web site, for
several reasons:
Putting all of the code in the web site (business logic and data access) can make the application
harder to maintain and understand.
Reusing database queries in the presentation layer often isnt done, because of the typical data
source control setup in the ASP.NET framework.
Relying on the data source controls can make debugging more difficult, often due to vague
error messages.
So in looking for an alternative, we can separate the data access code and business logic into separate
layers, which well discuss next.
The Data Layer
The key component to most applications is the data. The data has to be served to the presentation
layer somehow. The data layer is a separate component (often setup as a separate single or group of
projects in a .NET solution), whose sole purpose is to serve up the data from the database and return
it to the caller. Through this approach, data can be logically reused, meaning that a portion of an
application reusing the same query can make a call to one data layer method, instead of embedding
the query multiple times. This is generally more maintainable.

1
3
But the question is how is the data returned? Multiple frameworks employ different techniques, and
below is a summary:
ADO.NET Built into the .NET framework, ADO.NET contains a mechanism to query data out
of the database and return it to the caller in a connected or disconnected fashion. This is the
most common approach to working with data, because its already readily available. See more
at: http://en.wikipedia.org/wiki/ADO.NET.
Table Adapters/Strongly-Typed Datasets Strongly-typed datasets and table adapters provide
a similar means to querying the data through ADO.NET, but add strong-typing features,
meaning custom objects are generated for you to work with. See more here.
Enterprise Library Enterprise library Data Access Application Block provides a flexible way
to connect to databases of multiple types, without having to know anything about that
database, through an abstract approach. See more at: http://msdn2.microsoft.com/en-
us/magazine/cc188705.aspx (read part one first).
LINQ-to-SQL LINQ to SQL is an ORM tool that uses a DataContext object as the central
point to query data from the database. See more here. (read parts one through eight first).
Auto-Generated Code Tools like CodeSmith Studio automatically generate the code for you
based upon a database schema. Simply writing a script to output the code you want to use and
the backend is generated in a short amount of time.
Most (if not all) options above take advantage of the CRUD (create, read, update, or delete) operations
that databases support, so all of that is available as shown above. There are plenty of resources online
to help you get started. To see an overview of some of the options, please read this.
Business Layer
Though a web site could talk to the data access layer directly, it usually goes through another layer
called the business layer. The business layer is vital in that it validates the input conditions before
calling a method from the data layer. This ensures the data input is correct before proceeding, and can
often ensure that the outputs are correct as well. This validation of input is called business rules,
meaning the rules that the business layer uses to make judgments about the data.
However, business rules dont only apply to data validation; these rules apply to any calculations or
any other action that takes place in the business layer. Normally, its best to put as much logic as
possible in the business layer, which makes this logic reusable across applications.
One of the best reasons for reusing logic is that applications that start off small usually grow in
functionality. For instance, a company begins to develop a web site, and as they realize their business
needs, they later decide to add a smart client application and windows service to supplement the web
site. The business layer helps move logic to a central layer for maximum reusability.
Presentation Layer
The ASP.NET web site or windows forms application (the UI for the project) is called the presentation
layer. The presentation layer is the most important layer simply because its the one that everyone

1
4
sees and uses. Even with a well structured business and data layer, if the presentation layer is
designed poorly, this gives the users a poor view of the system.
Its best to remove as much business logic out of the UI and into the business layer. This usually
involves more code, but in my mind, the excess time (which ranges from minimal to moderate,
depending on the size of the application) pays off in the end.
However, a well-architected system leaves another question: how do you display it in an ASP.NET or
windows application? This can be more of a problem in ASP.NET, as the controls are more limited to
the type of inputs they can receive. If you use certain architectures, like passing datasets from the data
to the presentation layer, this isnt as much of a challenge; however, the challenge can come with
business objects that support drill-through business object references.
Why Separating Logic Is Useful?
You may wonder why it is important to move as much logic outside the presentation layer and into the
business layer. The biggest reason is reuse: logic placed in a business layer increases the reusability of
an application. As applications grow, applications often grow into other realms. Applications may
start out as a web application, but some of the functionality may later be moved to a smart client
application. Portions of an application may be split between a web site and a web or windows service
that runs on a server. In addition, keeping logic helps aid in developing a good design (sometimes
code can get sloppier in the UI).
However, there are some caveats to this: it takes a little longer to develop applications when most of
the logic resides in the business layer. The reason is this often involves creating several sets of objects
(data layer and access code, plus business objects) rather than embedding it in the application. The
extra time that it takes to do this can be a turnoff for some managers and project leads, especially
because it often requires you to be knowledgeable about object-oriented programming, more than
most people are comfortable with.
A layered approach is often a better approach because it pays dividends down the road. This is
because as more and more code is developed, the following happens:
Code is copied and pasted frequently, or code is reused in classes that could easily be moved to
a business layer.
Code that is very similar is often copied and pasted with slight modification, making
duplication harder to track down.
Its harder to maintain; even though applications with business objects are larger applications,
they usually are structured better.
Code is harder to unit test, if unit testing is available at all. Web applications and windows
forms projects are hard to use unit testing with.
A good architecture is often harder to implement, but is easier to maintain because it often reduces
the volume of code. This means that hours spent supporting an application are reduced.
Distributed Applications

1
5
Using a separation of layers can aid in development of distributed applications. Because the code is
broken up into layers, a layer that facilitates the use of remoting or web services can be added to the
project, with a minimal amount of work.
Development Techniques
When developing a business object architecture, its good to know about the many design patterns
that are out there. There are many websites, blogs, and books related to the subject of design patterns.
One of the more well-known books on the subject is titled Design Patterns, whom the authors are
often referred to as the Gang of Four.
Another useful development technique is called Refactoring, or improving the quality of your code by
making small changes to the way it works. This involves moving code into a method, or moving a
method from one object to another, in a systematic, logical way. Martin Fowler has written a great
book on this subject, called Refactoring, Improving the Design of Existing Code. There are plenty of
books on the subject; this one is the source that helped me to understand refactoring the most.
There are also tools on the market that can help you refactor in a faster way. One of those tools is
Resharper by Jet Brains, which looks for a lot of code patterns and refactors them in a way that is
useful. Some of the other refactoring tools that I heard about are Refactor Pro by DevExpress (free for
VB.NET and ASP.NET), Visual Assist X by Whole Tomato Software, and Just Code by OmniCore.
Conclusion
This article reviewed the use of layers in an application, and discussed the fundamentals of their use.
It also discussed the purpose of each layer, why using layers is important, and some other techniques
useful for developing applications.
---------------------------------------------------------------
Loose coupling
Service-Oriented Architecture
Web services promote an environment for systems that is loosely coupled and interoperable. Many of
the concepts for Web services come from a conceptual architecture called service-oriented
architecture (SOA). SOA configures entities (services, registries, contracts, and proxies) to maximize
loose coupling and reuse.
Software architecture describes the systems components and the way they interact at a high level.
These components are not necessarily entity beans or distributed objects. They are abstract modules
of software deployed as a unit onto a server with other components. The interactions between
components are called connectors. The configuration of components and connectors describes the
way a system is structured and behaves, as shown in Figure 2.1. Rather than creating a formal
definition for software architecture in this chapter, we will adopt this classic definition: The software
architecture of a program or computing system is the structure or structures of the system, which
comprise software components, the externally.

1
6
SOA is a relatively new term, but the term service as it relates to a software service has been around
since at least the early 1990s, when it was used in Tuxedo to describe services and service
processes (Herzum 2002). Sun defined SOA more rigorously in the late 1990s to describe Jini, a
lightweight environment fordynamically discovering and using services on a network. The technology
is used mostly in reference to allowing network plug and play for devices. It allows devices such as
printers to dynamically connect to and download drivers from the network and register their services
as being available.
Loose Coupling
Coupling refers to the number of dependencies between modules. There are two types of coupling:
loose and tight. Loosely coupled modules have a few well known dependencies. Tightly coupled
modules have many unknown dependencies. Every software architecture strives to achieve loose
coupling between modules.
Service-oriented architecture promotes loose coupling between service consumers and service
providers and the idea of a few well-known dependencies between consumers and providers. A
systems degree of coupling directly affects its modifiability. The more tightly coupled a system is, the
more a change in a service will require changes in service consumers. Coupling is increased when
service consumers require a large amount of information about the service provider to use the service.
In other words, if a service consumer knows the location and detailed data format for a service
provider, the consumer and provider are more tightly coupled. If the consumer of the service does not
need detailed knowledge of the service before invoking it, the consumer and provider are more loosely
coupled.
SOA accomplishes loose coupling through the use of contracts and bindings. A consumer asks a third-
party registry for information about the type of service it wishes to use. The registry returns all the
services it has available that match the consumers criteria. The consumer chooses which service to
use, binds to it over a transport, and executes the method on it, based on the description of the service
provided by the registry. The consumer does not depend directly on the services implementation but
only on the contract the service supports. Since a service may be both a consumer and a provider of
some services, the dependency on only the contract enforces the notion of loose coupling in service-
oriented architecture.
Although coupling between service consumers and service producers is loose, implementation of the
service can be tightly coupled with implementation of other services. For instance, if a set of services
shares a framework, a database, or otherwise has information about each others implementation,
they may be tightly coupled. In many instances, coupling cannot be avoided, and it sometimes
contradicts the goal of code reusability.
----------------------------------------------------------


1
7
XML
Extensible Markup Language (XML) is a markup language that defines a set of rules for
encoding documents in a format that is both human-readable and machine-readable. It is
defined in the XML 1.0 Specification produced by the W3C, and several other related specifications,
all gratis open standards.
The design goals of XML emphasize simplicity, generality, and usability over the Internet. It is a
textual data format with strong support via Unicode for the languages of the world. Although the
design of XML focuses on documents, it is widely used for the representation of arbitrary
data structures, for example in web services.
Many application programming interfaces (APIs) have been developed that software developers use to
process XML data, and several schema systems exist to aid in the definition of XML-based languages.
As of 2009, hundreds of XML-based languages have been developed, including RSS, Atom, SOAP,
and XHTML. XML-based formats have become the default for many office-productivity tools,
including Microsoft Office (Office Open XML), OpenOffice.org (OpenDocument), and Apple's iWork.
XML has also been employed as the base language for communication protocols, such as XMPP.
Key terminologies
An introduction to the key constructs most often encountered in day-to-day use.
(Unicode) Character
By definition, an XML document is a string of characters. Almost every legal Unicode character may
appear in an XML document.
Processor and Application
The processor analyzes the markup and passes structured information to an application. The
specification places requirements on what an XML processor must do and not do, but the application
is outside its scope. The processor (as the specification calls it) is often referred to colloquially as an
XML parser.
Markup and Content
The characters which make up an XML document are divided into markup and content. Markup and
content may be distinguished by the application of simple syntactic rules. All strings which constitute
markup either begin with the character "<" and end with a ">", or begin with the character "&" and
end with a ";". Strings of characters which are not markup are content.
Tag
A markup construct that begins with "<" and ends with ">". Tags come in three flavors: start-tags, for
example <section>, end-tags, for example </section>, and empty-element tags, for example <line-
break />.

1
8
Element
A logical document component either begins with a start-tag and ends with a matching end-tag or
consists only of an empty-element tag. The characters between the start- and end-tags, if any, are the
element's content, and may contain markup, including other elements, which are called child
elements. An example of an element is <Greeting>Hello, world.</Greeting> (see hello world).
Another is <line-break />.
Attribute
A markup construct consisting of a name/value pair that exists within a start-tag or empty-element
tag. In the example (below) the element img has two attributes, src and alt: <img src="madonna.jpg"
alt='Foligno Madonna, by Raphael' />. Another example would be <step number="3">Connect A to
B.</step> where the name of the attribute is "number" and the value is "3".
XML Declaration
XML documents may begin by declaring some information about themselves, as in the following
example.
<?xml version="1.0" encoding="UTF-8" ?>
Characters and escaping
XML documents consist entirely of characters from the Unicode repertoire. Except for a small
number of specifically excluded control characters, any character defined by Unicode may appear
within the content of an XML document. The selection of characters that may appear within markup
is somewhat more limited but still large.
XML includes facilities for identifying the encoding of the Unicode characters that make up the
document, and for expressing characters that, for one reason or another, cannot be used directly.
Valid characters
Unicode code points in the following ranges are valid in XML 1.0 documents:
U+0009, U+000A, U+000D: these are the only C0 controls accepted in XML 1.0;
U+0020U+D7FF, U+E000U+FFFD: this excludes some (not all) non-characters in the
BMP (all surrogates, U+FFFE and U+FFFF are forbidden);
U+10000U+10FFFF: this includes all code points in supplementary planes, including non-
characters.
XML 1.1 extends the set of allowed characters to include all the above, plus the remaining characters
in the range U+0001U+001F. At the same time, however, it restricts the use of C0 and C1 control
characters other than U+0009, U+000A, U+000D, and U+0085 by requiring them to be written in
escaped form (for example U+0001 must be written as or its equivalent). In the case of C1

1
9
characters, this restriction is a backwards incompatibility; it was introduced to allow common
encoding errors to be detected.
The code point U+0000 is the only character that is not permitted in any XML 1.0 or 1.1 document.
Encoding detection
The Unicode character set can be encoded into bytes for storage or transmission in a variety of
different ways, called "encodings". Unicode itself defines encodings that cover the entire repertoire;
well-known ones include UTF-8 and UTF-16.[11] There are many other text encodings that pre-date
Unicode, such as ASCII and ISO/IEC 8859; their character repertoires in almost every case are
subsets of the Unicode character set.
XML allows the use of any of the Unicode-defined encodings, and any other encodings whose
characters also appear in Unicode. XML also provides a mechanism whereby an XML processor can
reliably, without any prior knowledge, determine which encoding is being used.[12] Encodings other
than UTF-8 and UTF-16 will not necessarily be recognized by every XML parser.
Escaping
XML provides escape facilities for including characters which are problematic to include directly. For
example:
The characters "<" and "&" are key syntax markers and may never appear in content outside of a
CDATA section.[13]
Some character encodings support only a subset of Unicode: for example, it is legal to encode an XML
document in ASCII, but ASCII lacks code points for Unicode characters such as "".
It might not be possible to type the character on the author's machine.
Some characters have glyphs that cannot be visually distinguished from other characters: examples
are
non-breaking-space ( ) " "
compare space ( ) " "
Cyrillic Capital Letter A (А) ""
compare Latin Capital Letter A (a) "A"
There are five predefined entities:
1. < represents "<"
2. > represents ">"
3. & represents "&"

2
0
4. ' represents '
5. " represents "
All permitted Unicode characters may be represented with a numeric character reference. Consider
the Chinese character "", whose numeric code in Unicode is hexadecimal 4E2D, or decimal 20,013.
A user whose keyboard offers no method for entering this character could still insert it in an XML
document encoded either as 中 or 中. Similarly, the string "I <3 Jrg" could be
encoded for inclusion in an XML document as "I <3 Jörg".
"" is not permitted, however, because the null character is one of the control characters excluded
from XML, even when using a numeric character reference.[14] An alternative encoding mechanism
such as Base64 is needed to represent such characters.
Comments
Comments may appear anywhere in a document outside other markup. Comments cannot appear
before the XML declaration. The string "--" (double-hyphen) is not allowed inside comments.
Comments start with ""
International use
XML supports the direct use of almost any Unicode character in element names, attributes,
comments, character data, and processing instructions (other than the ones that have special
symbolic meaning in XML itself, such as the less-than sign, "<"). Therefore, the following is a well-
formed XML document, even though it includes both Chinese and Cyrillic characters:
<?xml version="1.0" encoding="UTF-8" ?>
<></>
Well-formedness and error-handling
The XML specification defines an XML document as a text that is well-formed, i.e. it satisfies a list of
syntax rules provided in the specification. The list is fairly lengthy; some key points are:
It contains only properly encoded legal Unicode characters.
None of the special syntax characters such as "<" and "&" appear except when performing their
markup-delineation roles.
The begin, end, and empty-element tags that delimit the elements are correctly nested, with
none missing and none overlapping.

2
1
The element tags are case-sensitive; the beginning and end tags must match exactly. Tag
names cannot contain any of the characters !"#$%&'()*+,/;<=>?@[\]^`{|}~, nor a space
character, and cannot start with -, ., or a numeric digit.
There is a single "root" element that contains all the other elements.
The definition of an XML document excludes texts that contain violations of well-formedness rules;
they are simply not XML. An XML processor that encounters such a violation is required to report
such errors and to cease normal processing. This policy, occasionally referred to as draconian, stands
in notable contrast to the behavior of programs that process HTML, which are designed to produce a
reasonable result even in the presence of severe markup errors.[15] XML's policy in this area has been
criticized as a violation of Postel's law ("Be conservative in what you send; be liberal in what you
accept").
Schemas and validation
In addition to being well-formed, an XML document may be valid. This means that it contains a
reference to a Document Type Definition (DTD), and that its elements and attributes are declared in
that DTD and follow the grammatical rules for them that the DTD specifies.
XML processors are classified as validating or non-validating depending on whether or not they check
XML documents for validity. A processor that discovers a validity error must be able to report it, but
may continue normal processing.
A DTD is an example of a schema or grammar. Since the initial publication of XML 1.0, there has been
substantial work in the area of schema languages for XML. Such schema languages typically constrain
the set of elements that may be used in a document, which attributes may be applied to them, the
order in which they may appear, and the allowable parent/child relationships.
DTD : Document Type Definition
The oldest schema language for XML is the Document Type Definition (DTD), inherited from SGML.
DTDs have the following benefits:
DTD support is ubiquitous due to its inclusion in the XML 1.0 standard.
DTDs are terse compared to element-based schema languages and consequently present more
information in a single screen.
DTDs allow the declaration of standard public entity sets for publishing characters.
DTDs define a document type rather than the types used by a namespace, thus grouping all
constraints for a document in a single collection.
DTDs have the following limitations:
They have no explicit support for newer features of XML, most importantly namespaces.

2
2
They lack expressiveness. XML DTDs are simpler than SGML DTDs and there are certain
structures that cannot be expressed with regular grammars. DTDs only support rudimentary
datatypes.
They lack readability. DTD designers typically make heavy use of parameter entities (which
behave essentially as textual macros), which make it easier to define complex grammars, but at
the expense of clarity.
They use a syntax based on regular expression syntax, inherited from SGML, to describe the
schema. Typical XML APIs such as SAX do not attempt to offer applications a structured
representation of the syntax, so it is less accessible to programmers than an element-based
syntax may be.
Two peculiar features that distinguish DTDs from other schema types are the syntactic support
for embedding a DTD within XML documents and for defining entities, which are arbitrary
fragments of text and/or markup that the XML processor inserts in the DTD itself and in the
XML document wherever they are referenced, like character escapes.
DTD technology is still used in many applications because of its ubiquity.
XML Schema: XML Schema (W3C)
A newer schema language, described by the W3C as the successor of DTDs, is XML Schema, often
referred to by the initialism for XML Schema instances, XSD (XML Schema Definition). XSDs are far
more powerful than DTDs in describing XML languages. They use a rich datatyping system and allow
for more detailed constraints on an XML document's logical structure. XSDs also use an XML-based
format, which makes it possible to use ordinary XML tools to help process them.
RELAX NG:
RELAX NG was initially specified by OASIS and is now also an ISO/IEC International Standard (as
part of DSDL). RELAX NG schemas may be written in either an XML based syntax or a more compact
non-XML syntax; the two syntaxes are isomorphic and James Clark's Trang conversion tool can
convert between them without loss of information. RELAX NG has a simpler definition and validation
framework than XML Schema, making it easier to use and implement. It also has the ability to use
datatype framework plug-ins; a RELAX NG schema author, for example, can require values in an
XML document to conform to definitions in XML Schema Datatypes.
Schematron
Schematron is a language for making assertions about the presence or absence of patterns in an XML
document. It typically uses XPath expressions.

ISO DSDL and other schema languages

2
3
The ISO DSDL (Document Schema Description Languages) standard brings together a
comprehensive set of small schema languages, each targeted at specific problems. DSDL includes
RELAX NG full and compact syntax, Schematron assertion language, and languages for defining
datatypes, character repertoire constraints, renaming and entity expansion, and namespace-based
routing of document fragments to different validators. DSDL schema languages do not have the
vendor support of XML Schemas yet, and are to some extent a grassroots reaction of industrial
publishers to the lack of utility of XML Schemas for publishing.
Some schema languages not only describe the structure of a particular XML format but also offer
limited facilities to influence processing of individual XML files that conform to this format. DTDs
and XSDs both have this ability; they can for instance provide the infoset augmentation facility and
attribute defaults. RELAX NG and Schematron intentionally do not provide these.

Related specifications
A cluster of specifications closely related to XML have been developed, starting soon after the
initial publication of XML 1.0. It is frequently the case that the term "XML" is used to refer to
XML together with one or more of these other technologies which have come to be seen as part
of the XML core.
XML Namespaces enable the same document to contain XML elements and attributes taken
from different vocabularies, without any naming collisions occurring. Although XML
Namespaces are not part of the XML specification itself, virtually all XML software also
supports XML Namespaces.
XML Base defines the xml:base attribute, which may be used to set the base for resolution of
relative URI references within the scope of a single XML element.
The XML Information Set or XML infoset describes an abstract data model for XML
documents in terms of information items. The infoset is commonly used in the specifications of
XML languages, for convenience in describing constraints on the XML constructs those
languages allow.
xml:id Version 1.0 asserts that an attribute named xml:id functions as an "ID attribute" in the
sense used in a DTD.
XPath defines a syntax named XPath expressions which identifies one or more of the internal
components (elements, attributes, and so on) included in an XML document. XPath is widely
used in other core-XML specifications and in programming libraries for accessing XML-
encoded data.
XSLT is a language with an XML-based syntax that is used to transform XML documents into
other XML documents, HTML, or other, unstructured formats such as plain text or RTF. XSLT
is very tightly coupled with XPath, which it uses to address components of the input XML
document, mainly elements and attributes.

2
4
XSL Formatting Objects, or XSL-FO, is a markup language for XML document formatting
which is most often used to generate PDFs.
XQuery is an XML-oriented query language strongly rooted in XPath and XML Schema. It
provides methods to access, manipulate and return XML, and is mainly conceived as a query
language for XML databases.
XML Signature defines syntax and processing rules for creating digital signatures on XML
content.
XML Encryption defines syntax and processing rules for encrypting XML content.
Some other specifications conceived as part of the "XML Core" have failed to find wide
adoption, including XInclude, XLink, and XPointer.
Use on the Internet
XML has come into common use for the interchange of data over the Internet. RFC 3023 gives rules
for the construction of Internet Media Types for use when sending XML. It also defines the types
"application/xml" and "text/xml", which say only that the data are in XML, and nothing about its
semantics. The use of "text/xml" has been criticized as a potential source of encoding problems and is
now in the process of being deprecated.[3] RFC 3023 also recommends that XML-based languages be
given media types beginning in "application/" and ending in "+xml"; for example
"application/svg+xml" for SVG.
Programming interfaces
The design goals of XML include, "It shall be easy to write programs which process XML
documents."[6] Despite this, the XML specification contains almost no information about how
programmers might go about doing such processing. The XML Infoset specification provides a
vocabulary to refer to the constructs within an XML document, but also does not provide any
guidance on how to access this information. A variety of APIs for accessing XML have been developed
and used, and some have been standardized.

Existing APIs for XML processing tend to fall into these categories:
Stream-oriented APIs accessible from a programming language, for example SAX and StAX.
Tree-traversal APIs accessible from a programming language, for example DOM.
XML data binding, which provides an automated translation between an XML document and
programming-language objects.
Declarative transformation languages such as XSLT and XQuery.
Stream-oriented facilities require less memory and, for certain tasks which are based on a linear
traversal of an XML document, are faster and simpler than other alternatives. Tree-traversal and

2
5
data-binding APIs typically require the use of much more memory, but are often found more
convenient for use by programmers; some include declarative retrieval of document components via
the use of XPath expressions.
XSLT is designed for declarative description of XML document transformations, and has been widely
implemented both in server-side packages and Web browsers. XQuery overlaps XSLT in its
functionality, but is designed more for searching of large XML databases.
Simple API for XML (SAX)

SAX is a lexical, event-driven interface in which a document is read serially and its contents are
reported as callbacks to various methods on a handler object of the user's design. SAX is fast and
efficient to implement, but difficult to use for extracting information at random from the XML, since
it tends to burden the application author with keeping track of what part of the document is being
processed. It is better suited to situations in which certain types of information are always handled
the same way, no matter where they occur in the document.
Pull parsing
Pull parsing[17] treats the document as a series of items which are read in sequence using the Iterator
design pattern. This allows for writing of recursive-descent parsers in which the structure of the code
performing the parsing mirrors the structure of the XML being parsed, and intermediate parsed
results can be used and accessed as local variables within the methods performing the parsing, or
passed down (as method parameters) into lower-level methods, or returned (as method return values)
to higher-level methods. Examples of pull parsers include StAX in the Java programming language,
XMLReader in PHP and System.Xml.XmlReader in the .NET Framework.
A pull parser creates an iterator that sequentially visits the various elements, attributes, and data in
an XML document. Code which uses this iterator can test the current item (to tell, for example,
whether it is a start or end element, or text), and inspect its attributes (local name, namespace, values
of XML attributes, value of text, etc.), and can also move the iterator to the next item. The code can
thus extract information from the document as it traverses it. The recursive-descent approach tends
to lend itself to keeping data as typed local variables in the code doing the parsing, while SAX, for
instance, typically requires a parser to manually maintain intermediate data within a stack of
elements which are parent elements of the element being parsed. Pull-parsing code can be more
straightforward to understand and maintain than SAX parsing code.

Document Object Model
The Document Object Model (DOM) is an interface-oriented application programming interface that
allows for navigation of the entire document as if it were a tree of node objects representing the
document's contents. A DOM document can be created by a parser, or can be generated manually by

2
6
users (with limitations). Data types in DOM nodes are abstract; implementations provide their own
programming language-specific bindings. DOM implementations tend to be memory intensive, as
they generally require the entire document to be loaded into memory and constructed as a tree of
objects before access is allowed.
Data binding
Another form of XML processing API is XML data binding, where XML data are made available as a
hierarchy of custom, strongly typed classes, in contrast to the generic objects created by a Document
Object Model parser. This approach simplifies code development, and in many cases allows problems
to be identified at compile time rather than run-time. Example data binding systems include the Java
Architecture for XML Binding (JAXB) and XML Serialization in .NET.
XML as data type
XML is beginning to appear as a first-class data type in other languages. The ECMAScript for XML
(E4X) extension to the ECMAScript/JavaScript language explicitly defines two specific objects (XML
and XMLList) for JavaScript, which support XML document nodes and XML node lists as distinct
objects and use a dot-notation specifying parent-child relationships.[19] E4X is supported by the
Mozilla 2.5+ browsers and Adobe Actionscript, but has not been adopted more universally. Similar
notations are used in Microsoft's LINQ implementation for Microsoft .NET 3.5 and above, and in
Scala (which uses the Java VM). The open-source xmlsh application, which provides a Linux-like shell
with special features for XML manipulation, similarly treats XML as a data type, using the <[ ]>
notation.[20] The Resource Description Framework defines a data type rdf:XMLLiteral to hold
wrapped, canonical XML.[21]
History
XML is an application profile of SGML (ISO 8879).
The versatility of SGML for dynamic information display was understood by early digital media
publishers in the late 1980s prior to the rise of the Internet.[23][24] By the mid-1990s some
practitioners of SGML had gained experience with the then-new World Wide Web, and believed that
SGML offered solutions to some of the problems the Web was likely to face as it grew. Dan Connolly
added SGML to the list of W3C's activities when he joined the staff in 1995; work began in mid-1996
when Sun Microsystems engineer Jon Bosak developed a charter and recruited collaborators. Bosak
was well connected in the small community of people who had experience both in SGML and the Web.
XML was compiled by a working group of eleven members,[26] supported by an (approximately) 150-
member Interest Group. Technical debate took place on the Interest Group mailing list and issues
were resolved by consensus or, when that failed, majority vote of the Working Group. A record of
design decisions and their rationales was compiled by Michael Sperberg-McQueen on December 4,
1997.[27] James Clark served as Technical Lead of the Working Group, notably contributing the
empty-element "<empty />" syntax and the name "XML". Other names that had been put forward for
consideration included "MAGMA" (Minimal Architecture for Generalized Markup Applications),
"SLIM" (Structured Language for Internet Markup) and "MGML" (Minimal Generalized Markup
Language). The co-editors of the specification were originally Tim Bray and Michael Sperberg-

2
7
McQueen. Halfway through the project Bray accepted a consulting engagement with Netscape,
provoking vociferous protests from Microsoft. Bray was temporarily asked to resign the editorship.
This led to intense dispute in the Working Group, eventually solved by the appointment of Microsoft's
Jean Paoli as a third co-editor.
The XML Working Group never met face-to-face; the design was accomplished using a combination
of email and weekly teleconferences.

Sources
XML is a profile of an ISO standard SGML, and most of XML comes from SGML unchanged. From
SGML comes the separation of logical and physical structures (elements and entities), the availability
of grammar-based validation (DTDs), the separation of data and metadata (elements and attributes),
mixed content, the separation of processing from representation (processing instructions), and the
default angle-bracket syntax. Removed were the SGML Declaration (XML has a fixed delimiter set
and adopts Unicode as the document character set).
Other sources of technology for XML were the Text Encoding Initiative (TEI), which defined a profile
of SGML for use as a "transfer syntax"; and HTML, in which elements were synchronous with their
resource, document character sets were separate from resource encoding, the xml:lang attribute was
invented, and (like HTTP) metadata accompanied the resource rather than being needed at the
declaration of a link. The Extended Reference Concrete Syntax (ERCS) project of the SPREAD
(Standardization Project Regarding East Asian Documents) project of the ISO-related
China/Japan/Korea Document Processing expert group was the basis of XML 1.0's naming rules;
SPREAD also introduced hexadecimal numeric character references and the concept of references to
make available all Unicode characters. To support ERCS, XML and HTML better, the SGML standard
IS 8879 was revised in 1996 and 1998 with WebSGML Adaptations. The XML header followed that of
ISO HyTime.
Ideas that developed during discussion which were novel in XML included the algorithm for encoding
detection and the encoding header, the processing instruction target, the xml:space attribute, and the
new close delimiter for empty-element tags. The notion of well-formedness as opposed to validity
(which enables parsing without a schema) was first formalized in XML, although it had been
implemented successfully in the Electronic Book Technology "Dynatext" software;[30] the software
from the University of Waterloo New Oxford English Dictionary Project; the RISP LISP SGML text
processor at Uniscope, Tokyo; the US Army Missile Command IADS hypertext system; Mentor
Graphics Context; Interleaf and Xerox Publishing System.
Versions
There are two current versions of XML. The first (XML 1.0) was initially defined in 1998. It has
undergone minor revisions since then, without being given a new version number, and is currently in

2
8
its fifth edition, as published on November 26, 2008. It is widely implemented and still recommended
for general use.
The second (XML 1.1) was initially published on February 4, 2004, the same day as XML 1.0 Third
Edition,[31] and is currently in its second edition, as published on August 16, 2006. It contains
features (some contentious) that are intended to make XML easier to use in certain cases.[32] The
main changes are to enable the use of line-ending characters used on EBCDIC platforms, and the use
of scripts and characters absent from Unicode 3.2. XML 1.1 is not very widely implemented and is
recommended for use only by those who need its unique features.
Prior to its fifth edition release, XML 1.0 differed from XML 1.1 in having stricter requirements for
characters available for use in element and attribute names and unique identifiers: in the first four
editions of XML 1.0 the characters were exclusively enumerated using a specific version of the
Unicode standard (Unicode 2.0 to Unicode 3.2.) The fifth edition substitutes the mechanism of XML
1.1, which is more future-proof but reduces redundancy. The approach taken in the fifth edition of
XML 1.0 and in all editions of XML 1.1 is that only certain characters are forbidden in names, and
everything else is allowed, in order to accommodate the use of suitable name characters in future
versions of Unicode. In the fifth edition, XML names may contain characters in the Balinese, Cham,
or Phoenician scripts among many others which have been added to Unicode since Unicode 3.2.
Almost any Unicode code point can be used in the character data and attribute values of an XML 1.0
or 1.1 document, even if the character corresponding to the code point is not defined in the current
version of Unicode. In character data and attribute values, XML 1.1 allows the use of more control
characters than XML 1.0, but, for "robustness", most of the control characters introduced in XML 1.1
must be expressed as numeric character references (and #x7F through #x9F, which had been allowed
in XML 1.0, are in XML 1.1 even required to be expressed as numeric character references[34]).
Among the supported control characters in XML 1.1 are two line break codes that must be treated as
whitespace. Whitespace characters are the only control codes that can be written directly.
There has been discussion of an XML 2.0, although no organization has announced plans for work on
such a project. XML-SW (SW for skunkworks), written by one of the original developers of XML,[35]
contains some proposals for what an XML 2.0 might look like: elimination of DTDs from syntax,
integration of namespaces, XML Base and XML Information Set (infoset) into the base standard.
The World Wide Web Consortium also has an XML Binary Characterization Working Group doing
preliminary research into use cases and properties for a binary encoding of the XML infoset. The
working group is not chartered to produce any official standards. Since XML is by definition text-
based, ITU-T and ISO are using the name Fast Infoset for their own binary infoset to avoid confusion
Criticism
XML and its extensions have regularly been criticized for verbosity and complexity.[36] Mapping the
basic tree model of XML to type systems of programming languages or databases can be difficult,
especially when XML is used for exchanging highly structured data between applications, which was
not its primary design goal. Other criticisms attempt to refute the claim that XML is a self-describing
language[37] (though the XML specification itself makes no such claim). JSON and YAML are

2
9
frequently proposed as alternatives; both focus on representing structured data, rather than narrative
documents.


3
0
XML Structure
Structure
Elements
Document Types
Document Structure
Document Type Definition (DTD)
An Example
Element Attributes
Process Instructions
Extensible linking Language (XLL)

1)XML Elements
To create an XML document, it must contain elements. Lets assume that I want to create a document
with the elements LAND, FOREST, TREE, MEADOW, GRASS. Here is how I would use these
elements:
<LAND>
<FOREST>
<TREE>Oak</TREE>
<TREE>Pine</TREE>
<TREE>Maple</TREE>
</FOREST>
<MEADOW>
<GRASS>Bluegrass</GRASS>
<GRASS>Fescue</GRASS>
<GRASS>Rye</GRASS>
</MEADOW>
</LAND>
Each element is enclosed in <> brackets. The ending element has the '/' character before its name. As
you can see, there is one element that contains all others, <LAND>. XML requires one element that
contains all others. This single element, which in this case is "LAND", is called the root element. The
FOREST element contains several TREE elements, and the MEADOW likewise contains several

3
1
elements of GRASS. Each element that is contained in another ends in that same element and
therefore each element is properly nested.
Elements that are included in another element are considered nested. The TREE elements in the
above example are nested in the FOREST element. The FOREST element is the parent element to the
TREE element and the TREE element is also called the sub-element to the FOREST element. These
relationships hold true as you move up and down the element hierarchy. The FOREST and MEADOW
elements are sub-elements to the LAND root element.

The below example is not well formed:
<LAND>
<FOREST>
<TREE>Oak</TREE>
<TREE>Pine</TREE>
<TREE>Maple
</FOREST>
</TREE>
<MEADOW>
<GRASS>Rye</GRASS>
</MEADOW>
</LAND>
Element Tags
XML elements require both a beginning tag and an ending tag for all elements that have content.
Elements with content may be written as:
<TREE>Very large Oak tree</TREE>
Elements with no content may be expressed as:
<NOTHING></NOTHING>
In shorthand it may be expressed as:

3
2
<NOTHING/>
Elements with no content may be used to display graphics and other material in the document.
Element Name Requirements
Begins with a letter or underscore.
The first character may be followed by any combination of letters, numbers, or other ASCII
characters.
Elements beginning with "XML" whether capatilized or not are reserved.
Element Content
Elements may contain:
Nested elements - Other sub-elements.
Processing instructions
Characters - Normal text.

CDATA sections
Used to enter text that contains special characters not displayed normally by the browser such as less
than or greater than sign. These signs are used to enclose tags and are special characters. An example
CDATA section:
<![CDATA[ The < and > characters are displayed normally here. ]]>
Entity references - An entitity reference is precluded by a & sign. It is used to refer to a previously
defined entity, much like a variable may be used in a program.
Character references - References to characters that are not displayed normally in XMS such as
the < or > characters. These characters are represented as &#60 and &#62 respectively and will be
presented on the browser as the less than or greater than character they represent.
Comments - Comments are included as shown below and may be placed anywhere except inside an
element tag (markup).
----------------------------------
2)XML Document Formation
This page describes how to form an XML document and the two types of XML documents. Since
XML does not require a Document Type Definition (DTD) there are two basic ways to create the
document.
Types of XML Documents

3
3
Well Formed - The logical structure is not validated against the DTD. A well formed
document follows a set of rules to qualify as "well formed".
Valid - Must have a DTD and obey all the rules. These rules are more stringent than rules for a
well formed document. The document can be defined by a DTD which is either embedded
inside the XML page or referenced as external to the page. Also you can write your own DTD or
use a pre-existing DTD written by someone else.
Well Formed
The definition of "well formed" is: There must be one and only one top level element.
All elements must have a starting and an ending tag with matching starting and ending names.
Element names are case sensitive.
Elements must be nested properly.
Valid
Valid documents must:
Be well formed.
Include a DTD.
Follow the rules set by the DTD.
---------------------------------------------
3)XML Structure
This page provides a description of XML structure including the document parts, the prologue, and
provides a simple XML example document.
Document Parts
Prolog
Document Element (root element)
The Prologue
The prologue, equivalent to the header in HTML, may include the following:
An XML declaration (optional) such as:
<?xml version="1.0"?>
A DTD or reference to one (optional). An example reference to an external DTD file:
<!DOCTYPE LANGLIST SYSTEM "langlist.dtd">
Processing instructions - An example processing instruction that causes style to be determined
by a style sheet:
<?xml-stylesheet type="text/css" href="xmlstyle.css"?>
An XML Document
Therefore a complete well formed XML document may look like:

3
4
<LAND>
<FOREST>
<TREE>Oak</TREE>
<TREE>Pine</TREE>
<TREE>Maple</TREE>
</FOREST>
<MEADOW>
<GRASS>Rye</GRASS>
</MEADOW>
</LAND>
The LAND element, above, is the root element.
The below document is not an XML document since it does not qualify by the rules of a well formed
document. There is more than one top level element which disqualifies the document from being well
formed.
<FOREST>
<TREE>Oak</TREE>
<TREE>Pine</TREE>
<TREE>Maple</TREE>
</FOREST>
<MEADOW>
<GRASS>Rye</GRASS>
</MEADOW>

3
5
Defining Display
If the HTML document is not linked to a style sheet, the XML document will be displayed with tags
included. The elements and tags may be color coded to aid in viewing the document. The document is
displayed without tags according to the style sheet if a link to one is specified. The following document
shows a document with a link to a cascading style sheet:
<DATABASE>
<TITLE>List of Items Important to Markup Languages</TITLE>
<TITLE2>Languages</TITLE2>
<LANGUAGES>SGML<LANGUAGES>
<LANGUAGES>XML</LANGUAGES>
<LANGUAGES>HTML<LANGUAGES>
<TITLE2>Other</TITLE2>
<OTHER>DTD<OTHER>
<OTHER>DSSL<OTHER>
<OTHER>Style Sheets</OTHER>
</DATABASE>
The below line, which is a part of the XML document above, is a processing instruction and is a part
of the prolog.
The style sheet, "xmlstyle.css", may look like:
DATABASE
{ display: block }
TITLE
{ display: block;
font-family: arial;
color: #008000;
font-weight: 600;

3
6
font-size: 22;
text-align: center }
TITLE2
{ display: block;
font-family: arial;
color: #000080;
font-weight: 400;
font-size: 20 }
LANGUAGES
{ display: block;
list-style-type: decimal;
font-family: arial;
color: #000000;
font-weight: 400;
font-size: 18 }
OTHER
{ display: block;
list-style-type: square;
font-family: arial;
color: #0000ff;
font-weight: 200;
font-size: 14 }
---------------------------------------------
4)XML DTD
In order to use DTDs with XML, the reader is encouraged to learn about the structure of DTDs. The
document called "Document Type Definition (DTD)" on this website gives a more thorough
explanation about how to read and construct a DTD than this document. The DTDs in this document
are very basic and should, however, be easy to understand even for those who don't have familiarity
with DTD's.

3
7
The DTD, whether included as part of the XML file or external to the XML file is used to define
content. The DTD is used to determine the elements allowed in the file and which elements can be
contained in other elements. It also describes the number of times specific elements may be contained
in other elements.
The DTD document on this website was written for SGML DTDs and the main difference lies in the
fact that XML requires a beginning and ending tag for all elements. SGML does not have this
requirement .
Element Declaration
Therefore in an SGML DTD an element tag for the <HR> element is:
<!ELEMENT HR - O EMPTY -- horizontal rule -->
If written for XML, the DTD would be:
<!ELEMENT HR EMPTY -- horizontal rule -->
The difference between the two examples is that the XML <HR> declaration does not define whether
the element requires a closing tag as done with the "- O" text. This is because all elements in XML are
required to have closing tags and therefore defining whether a closing tag is required is pointless.
-----------------------------------------------------
5)XML Example
This is an example of an XML document that used an external DTD file and cascading style sheet
(CSS) file.
The XML File
The following file is called "parts.xml".
<!DOCTYPE PARTS SYSTEM "parts.dtd">
<?xml-stylesheet type="text/css" href="xmlpartsstyle.css"?>
<PARTS>
<TITLE>Computer Parts</TITLE>
<PART>
<ITEM>Motherboard</ITEM>
<MANUFACTURER>ASUS</MANUFACTURER>
<MODEL>P3B-F</MODEL>
<COST> 123.00</COST>

3
8
</PART>
<PART>
<ITEM>Video Card</ITEM>
<MANUFACTURER>ATI</MANUFACTURER>
<MODEL>All-in-Wonder Pro</MODEL>
</PART>
<PART>
<ITEM>Sound Card</ITEM>
<MANUFACTURER>Creative Labs</MANUFACTURER>
<MODEL>Sound Blaster Live</MODEL>
<COST> 80.00</COST>
</PART>
<PART>
<ITEM inch Monitor</ITEM>
<MANUFACTURER>LG Electronics</MANUFACTURER>
<MODEL> 995E</MODEL>
</PART>
</PARTS>

This file specifies the use of two external files.
A DTD file called "parts.dtd". This is done on the second line:
<!DOCTYPE PARTS SYSTEM "parts.dtd">
The name after !DOCTYPE which is "PARTS" must be the same name as the encapsulating
element in the XML file which is <PARTS> in this case.
A CSS file called "xmlpartsstyle.css". This is done on the third line using a processing
instruction:
<?xml-stylesheet type="text/css" href="xmlpartsstyle.css"?>

3
9
The DTD File
The following file is called "parts.dtd".
<!ELEMENT PARTS (TITLE?, PART*)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT PART (ITEM, MANUFACTURER, MODEL, COST)+>
<!ATTLIST PART
type (computer|auto|airplane) #IMPLIED>
<!ELEMENT ITEM (#PCDATA)>
<!ELEMENT MANUFACTURER (#PCDATA)>
<!ELEMENT MODEL (#PCDATA)>
<!ELEMENT COST (#PCDATA)>
The root element is PARTS. The root element may contain no TITLE element or one TITLE element
along with any number of PART elements. The PART element must contain one each of items ITEM,
MANUFACTURER, MODEL, and COST in order. The PART element may contain an attribute called
"type" which may have a value of "computer", "auto", or "airplane". The elements TITLE, ITEM,
MANUFACTURER, MODEL, and COST all contain PCDATA which is parsed character data.
The Style File
The following file is used to set the style of the elements in the XML file. It is called
"xmlpartstyle.css".
PARTS
{ display: block }
TITLE
{ display: block;
font-family: arial;
color: #008000;
font-weight: 600;
font-size: 22;
margin-top: 12pt;
text-align: center }

4
0
PART
{ display: block }
ITEM
{ display: block;
font-family: arial;
color: #000080;
font-weight: 400;
margin-left: 15pt;
margin-top: 12pt;
font-size: 18 }
MANUFACTURER
{ display: block;
font-family: arial;
color: #600060;
font-weight: 400;
margin-left: 45pt;
margin-top: 5pt;
font-size: 18 }
MODEL
{ display: block;
font-family: arial;
color: #006000;
font-weight: 400;
margin-left: 45pt;
margin-top: 5pt;
font-size: 18 }
COST

4
1
{ display: block;
font-family: arial;
color: #800000;
font-weight: 400;
margin-left: 45pt;
margin-top: 5pt;
font-size: 18 }
How it Displays on your browser
If you click on the following link and the loaded document does not display in color, your browser
probably does not support XML. In this case, you should update your browser to the most recent
version.
-------------------------------------------------
6)XML Element Attributes
An XML attribute may be included with element declarations. XML Attributes are name/value pairs
that may be associated with the element. XML attributes may be used to control some characteristics
of the element. In the markup document attributes are used with the following form:
<ELEMENTNAME Importance="minimal">
Rules for XML attribute names are the same as rules for XML element names. The attribute name
may only appear once in the element start tag. The double or single quoted string may be used to
delimit the attribute value. The attribute value may not contain the < character. The attribute value
can only include the & character when using an entity or character reference.
The DTD determines which element attributes are required and what the defaults are. Read the DTD
Reference manual on this website for more information about writing DTDs and specifying element
attributes. XML Process Instructions
----------------------------------------------
7)XML Process Instructions
XML process instructions are normally included in the XML document prolog, commonly thought of
as the header in HTML. Processing instructions may be placed anywhere in the document so long as
they are outside the element tags.
standalone="yes"

4
2
The rules for the names of process instructions are similar to the rules for element names, however in
the case of process instructions there are some reserved xml process instructions such as "xml-
stylesheet".
The process instruction syntax:
<? target instruction ?>
The target is the application name the instruction is meant for. It can be a reserved value such as
"xml-stylesheet" or the name of an external application such as a script program name.
---------------------------------------------------
8)Extensible linking Language (XLL)
XLL formally was called XLink. XLL stands for Extensible Linking language and consists of the
following parts:
XPointer - It is built on XPath and it establishes a common system to specify node locations.
It allows for locating data that is not a complete node.
XLink - Advanced linking. It links to multiple destinations, is bi-directional and allows for
links to be displayed on other documents
XInclude - Merges XML infosets into one infoset.

-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-

Unit 4 - Final

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Unit 4 - Final

Diunggah oleh

Hak Cipta:

Format Tersedia

Copyright :IT ENGG PORTAL www.itportal.

Anda mungkin juga menyukai