Download lesson10

Software Paradigms
Software Paradigms (Lesson 10)
Selected Topics in Software Architecture
Table of Contents
1
World-Wide-Web ................................................................................................. 2
1.1 Basic Architectural Solution ............................................................................ 2
1.2 Designing WWW Applications ........................................................................ 7
2
CORBA ............................................................................................................... 11
2.1 Distributed Object Systems ............................................................................ 11
2.2 CORBA: Basics.............................................................................................. 12
2.3 CORBA: Services........................................................................................... 16
3
Database System ................................................................................................. 17
4
Real-Time Systems ............................................................................................. 20
This lesson presents a number of standard architectural solutions.
Software Paradigms
1
World-Wide-Web
The basic WWW properties are:

Remote access to documents

Interoperability between different platforms

Extensibility of software

Extensibility of data

Scalability
The basic architectural approach used in the WWW can be defined as:
1.1

Client/server style;

Hypertext transfer protocol (HTTP) that serves as a data transportation
layer

Special data format (HTML) that masks all hardware, operating system,
and protocol dependencies.
Basic Architectural Solution
Content producers and consumers interact through their respective servers and
clients.
Software Paradigms
The producer places content on a server machine and the content is described in
HTML. The server communicates with a client using the hypertext transfer protocol
(HTTP). The software on both the server and the client is based on HTTP and HTML
and so the details of the protocol and the dependencies on the platforms are masked
from the software.
Mapping basic WWW properties on architectural solutions:

Remote access = Build on top of Internet

Interoperability = Use HTML to mask platform details

Extensibility of software = Server-Site and Client-Site programming
(Virtual Machine Style)

Extensibility of data = references to any types of data

Scalability = client-server architecture style and local references to other
data
One of the main WWW components is a WWW client that display WWW documents
(content) so that the content consumer is presented with an understandable image
and with a possibility to access other related documents.
Software Paradigms
The user interface (UI) manager handles the look and feel of the cliental user
interface.
However, given that the set of resources that a WWW system can handle is open
ended, the UI manager, can delegate information display to external programs
(viewers) to view resources that are known by the system but not directly supported
by the UI manager.
For example, most Web viewers use an external program to view Postscript files,
Vector Graphics an movies. This delegation is a reasonable compromise between the
competing desires of user-interface integration (which provides for a consistent look
and feel and hence better usability) and extensibility.
The UI manager captures a user's request for information retrieval in the form of a
URL and passes the information to the access manager.
The access manager determines if the requested URL exists in cache and also
interprets history-based navigation (e.g., "back","forward", etc.).
Software Paradigms
The stream scheduler is an important architectural component to synchronize
"fast" local data processing operations performed by the UI manager and relatively
"slow" data access and data transfer operations performed by Cache Manager and
Protocol Manger.
The stream scheduler can be seen as a queue of requests to perform input/output
and data transfer operations.
The protocol manager manages the low-level communications, thus ensuring, for
the other parts of the system, transparent communication across a network.
The protocol manager determines the type of request and invokes the appropriate
protocol suite to service the request.
Software Paradigms
The WWW server ensures transparent access to the tremendous collection of
documents that is actually a primary WWW goal.
The server does this either by handling the access directly (for known resource
types) or through a proxy known as common gateway interface (CGI). CGI handles
resource types that a native server cannot handle and handles extension of the
functionality of the server, as will be discussed below.
The request scheduler is an important architectural component to synchronize
requests concurrently coming from multiple (often very many) clients and other
server components sharing a single data processing unit.
The request scheduler can be seen as a queue of clients' requests to the server.
The User Session Manager is an architectural component to resolve a conflict
between the server serving simultaneously many users and personalization of a
particular user access.
Software Paradigms
Normally, the user session manager keeps a user specific data (for example, user
status, login name, etc.), identifies a user for each particular request, and recovers
the user specific data to properly carry out the request.
When a request is received by the request manager, the type of request is
determined.

If a known file is requested, the HTTP server accesses the file system and
writes the requested information to the output stream.

If a program is to be executed, a process is made available (either new or
polled) through the CGI and the program is executed, with the output written
by the server request manager back to the WWW client.
In either case, CGI is one of the primary means through which servers provide for
extensibility, and ease of extensibility has become one of the most important
requirements driving the evolution of Web software. CGI has become an important
aspect of Web-based applications.
1.2
Designing WWW Applications
Most information served by a server is static; it changes only when its author
modifies it on its home tile system. Common Gateway Interface (CGI), on the
other hand, allow dynamic, request-specific information to be returned by a server.
The most common use of CGI, is to create virtual HTML documents- documents that
are dynamically synthesized in response to a user request.
Software Paradigms
CGI applications are written in a variety of languages, some of which are compiled
(C, C++, Fortran) and others run under control of a CGI compatible virtual machine
(Java Scripts, Java Servlets, PHP scripts, CGI scripts, etc.)
Thus, WWW technology may be seen as an operating environment for developing
full-fledged distributed applications.
In this case,

HTTP serves as a transport protocol

HTML server as graphic user interface

purpose-oriented functionality is implemented as a CGI compatible application
Actually, the term CGI compatible application may be seen as an Internet access to
any local application.
For example, a database management system, spreadsheet, expert system, etc.
Software Paradigms
Unfortunately, all such internet applications experience common problems:

Performance: all the calculations requested by a number of clients are
performed on the server what results in a longer responce time.

Usability: HTML does not provide such up-to-date graphical user interface
solutions as drag/drop, animation,vector graphics, etc.

Internet Traffic: almost any user actions results in generating and
transfering rather long HTML files what considerably increase an Internet
traffic and the system overall costs for users.
Of course, the WWW technology provides another solution to build WWW compatible
applications - client site applications.
A particular WWW server may just provide access to a purpose-oriented applications
which are interpreted by a WWW client.
Software Paradigms
Moving calculations to a client site considerably increases performance and
decreases an internet traffic.
At the same time, all such internet applications experience user interface problems
and especially browser incompatibility.
Software Paradigms
2
CORBA
Distributed object systems are distributed systems in which all entities are modeled
as objects. Distributed object systems are a popular paradigm for object-oriented
distributed applications. Since the application is modeled as a set of cooperating
objects, it maps very naturally to the services of the distributed system.
CORBA, or Common Object Request Broker Architecture, is a standard
architecture for distributed object systems. It allows a distributed, heterogeneous
collection of objects to interoperate.
2.1
Distributed Object Systems
CORBA is an architecture for distributed object systems. It basically means two
things:

A system functionality is defined by means of Object-Oriented
programming paradigm.

calculation is distributed over a network.
Object-Oriented programming paradigm:

A system is presented in a form of Objects

Objects (Clients) request services from other objects (Servants)

Everything else is defined by CORBA in terms of this basic paradigm.
A distributed calculation is implemented over a location transparency. Exactly the
same request mechanism is used by the client regardless of where the server is
located. It might be in the same process with the client, down the hall or across the
planet. The client cannot tell the difference.
Software Paradigms
2.2
CORBA: Basics
The location transparency is implemented as a pecial component called ORB
(Object Request Broker).
ORB is a special computer network environment providing transportation of requests
and data from one physical location to another.
In CORBA, every object instance has its own unique object reference, an
identifying electronic token.
Software Paradigms
Clients use the object references to direct their invocations, identifying to the ORB
the exact instance they want to invoke (Ensuring, for example, that the books you
select go into your own shopping cart, and not into your neighbor's.)
CORBA essentially separates object interface from implementation.
In interface is defined by means of special IDL (Interface Definition Language).
Any client that wants to invoke an operation on the object must use this IDL
interface to specify the operation it wants to perform, and to marshal the arguments
that it sends.
The interface to each object is defined very strictly. In contrast, the implementation
of an object − its running code, and its data − is hidden from the rest of the system
(that is, encapsulated) behind a boundary that the client may not cross. Clients
access objects only through their advertised interface, invoking only those operations
that that the object exposes through its IDL interface, with only those parameters
(input and output) that are included in the invocation.
An interface definition (IDL) is compiled into

client stubs (used to request a sevice) and

object skeletons (used to provide a service).
Stubs and skeletons serve as proxies for clients and servers, respectively.
Software Paradigms
When the invocation reaches the target object, the same interface definition is used
there to unmarshal the arguments so that the object can perform the requested
operation with them. The interface definition is then used to marshal the results for
their trip back, and to unmarshal them when they reach their destination.
In order to invoke the remote object instance, the client first obtains its object
reference.
There are many ways to do this, but we won't detail any of them here. Easy ways
include the Naming Service and the Trader Service (below).
The client acts as if it's invoking an operation on the object instance, but it's actually
invoking on the IDL stub which acts as a proxy. Passing through the stub on the
client side, the invocation continues through the ORB (Object Request Broker), and
the skeleton on the implementation side, to get to the object where it is executed.
CORBA has standardized inter−object collaboration process at two key levels:

First, the client knows the type of object it's invoking (that it's a shopping cart
object, for instance), and the client stub and object skeleton are generated
from the same IDL. This means that the client knows exactly which
operations it may invoke, what the input parameters are, and where they
have to go in the invocation; when the invocation reaches the target,
everything is there and in the right place.
Software Paradigms
In order to be able to do that, the the system needs to have access to information
about the object's location and operating environment. The database containing this
information is called Implementation Repository and is a standard component of
the CORBA architecture.
The Implementation Repository may also contain other information pertaining to the
implementation of servers, such as debugging, version and administrative
information.

Second, the client's ORB and object's ORB must agree on a common protocol
- that is, a representation to specify the target object, operation, all
parameters (input and output) of every type that they may use, and how all
of this is represented over the wire.
This function is fulfilled by General Inter-ORB Protocol (GIOP); it has been
specifically defined to meet the needs of ORB-to-ORB interaction and is designed to
work over any transport protocol that meets a minimal set of assumptions. Of
course, versions of GIOP implemented using different transports will not necessarily
be directly compatible; however their interaction will be made much more efficient.
Apart from defining the general transfer syntax, OMG also specified how it is going to
be implemented using the TCP/IP transport and thus defined the Internet InterORB Protocol (IIOP).
Software Paradigms
2.3
CORBA: Services
Object Services are domain-independent interfaces that are used by many
distributed object programs.
For example, a service providing for the discovery of (Searching for) other available
services is almost always necessary regardless of the application domain.
Two examples of Object Services that fulfill this role are:

The Naming Service -- which allows clients to find objects based on names;

The Trading Service -- which allows clients to find objects based on their
properties.
There are also Object Service specifications for

lifecycle management,

security,

transactions,

event notification, etc.
Common Facilities -- Like Object Service interfaces, these interfaces are also
horizontally-oriented, but unlike Object Services they are oriented towards end-user
applications.
An example of such a facility is the Distributed Document Component Facility
(DDCF), a compound document Common Facility based on OpenDoc.
DDCF suports an interoperability of objects based on a document model, for
example, facilitating the linking of a spreadsheet object into a report document.
Software Paradigms
3
Database System
Architecture of any RDBMS system is heterogeneous. These systems utilize not only
one architectural style but rather they combine a number of architectural styles into
a complex software architecture.
At the top level, RDBMS can be seen as a client/server system.
The client is the process that issues special data processing commands (database
transactions).
Database transactions are processed by the server that actually access the
database. Thus, the server:

Controls the physical files containing the data.

Checks user login and privileges.

Support logical and physical structure of the database (integrity)

Optimize transactions to increase performance

Manages transactions received from multiple clients
Software Paradigms
Normally, a Database Management System (DBMS) has a number of ready-made
clients allowing a user to work interactively with a database using SQL commands or
another data manipulation language. Such clients are called system clients.
A database application is implemented as a number purpose-oriented clients that
use special API (Application Programming Interfaces) to initiate database
transactions. The transactions are embedded into the code to access/modify
database. In this case, the programming language is called Host Programming
Language.
Conceptually, a database server is build using layered architecture. We can
distinguish

Communication Layer that provides a transparent communication between
the server and clients independently of their physical position.

Logical Layer that implemnts main DBMS functionality in accordance with
logical data model supported by the system

Physical Layer that masks all hardware, operating system, and protocol
dependencies.
Normally, logical layer consists of the following components:

Transaction Manager that accumulate and queue data transactions received
from different clients.

Session Manager that resolves a conflict between the server serving
simultaneously many users and personalization of a particular user access
Software Paradigms

Transaction Engine that parses, optimizes and carry out database
transactions

Recovery Engine control whether a transaction has been carried out
successfully, and recovers the database in case of any erroneous situations
Note, the Transaction Engine and Recovery Engine are built on top of functionality
provided by the physical layer.
Physical layer os a database server consists of the following components:

Buffer Manager that controls elements of the database in RAM. Typical
problems that is solved by the component is reducing of read/write operations
by keeping most frequently accessed parts of the database in RAM.

Resource Manager that controls such additional data elements as database
journals, flags, dynamically built indexes, etc.

Storage Manager that implements a patform and position independent
storage access operations.
Software Paradigms
4
Real-Time Systems
Real-time systems operate under strong time conditions (constraints), they are
inherently distributed and dynamic.
In order to reflect these properties, software architecture for real-time systems
which monitor, control, or simulate real world processes must provide adequate
means to cope with time, concurrency, and decentralisation.
Most often, real-time systems are design using "Event" architectural style.
Additionally, the real-time architecture should reflect the following tasks:

time-stamping of all involved processes.

scheduling of all involved resources.
The event receiver gets all the events from external sensors and internal systems
components. Additionally, the component.

provides an event time-stamp using a high resolution global clock

calculates a time until when the event should be processed

sends the time-stamped event (i.e. a so-called task) to the task scheduler.
Software Paradigms
The task scheduler controls the order in which the tasks are carried out by the
system.
We can see it as a dynamic changing the tasks priorities as follows:

for each task the system keeps an average time needed to carry it out and
relative importance

the prority can be calculated using a particular time restriction, relative
importance and current system time.

the task scheduler selects a task having highest priority, and sends it to
process manager that initiates a special process for an especially designed
software component. Note, if the task manager encounters a task having
higher priority then currently running process, the process is interrupted.
The priority assignment scenario above is known as "worst-case" scenario. However,
it is a non-trivial problem to find the relative importance of tasks such that the whole
system behaves optimal.
Since there might be a number of processes running concurrently resources
(memory, input/output devices, etc.) might be redistributed between processes.
The resource manager allocates system resources to processes in accordance with
their relative priority.
For example, in accordance with the "worst-case" strategy all system resources are
allocated for a process if the task priority reaches a certain threshold value (task is a
risk for the whole system functionality).
Software Paradigms