Selected Topics in Software Architecture

file:///E|/LV_CD/wbtmaster/main_library/swp7.htm

Selected Topics inSoftware Architecture

This lesson presents a number of standard architectural solutions.

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:

● 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.

1.1 Basic Architectural Solution

file:///E|/LV_CD/wbtmaster/main_library/swp7.htm (1 of 22) [10/16/2002 4:17:53 PM]


Content producers and consumers interact through their respective servers and clients.

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.

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.).



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.



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.

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.

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.

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.

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.

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.



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.



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.

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.

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 Inter-ORB Protocol (IIOP).

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.

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

Normally, a Database Managemnt 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

● 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.

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.



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 importances 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 threshhold value (task is a risk for the whole system functionality).




Documents

Selected Topics in Software Architecture