Application systems are intended to meet a business or organizational need. These commonalities have led to the development of software architectures that describe the structure and organization of particular types of software systems. Application architectures encapsulate the principal characteristics of a class of systems.
The application architecture may be re-implemented when developing new systems but, for many business systems, application reuse is possible without reimplementation. We see this in the growth of Enterprise Resource Planning (ERP) systems from companies such as SAP and Oracle, and vertical software packages (COTS) for specialized applications in different areas of business.
As a software designer, you can use models of application architectures in a number of ways:
As a starting point for the architectural design process. If you are unfamiliar with the type of application that you are developing, you can base your initial design on a generic application architecture. Of course, this will have to be specialized for the specific system being developed, but it is a good starting point for design.
As a design checklist If you have developed an architectural design for an application system, you can compare this with the generic application architecture. You can check that your design is consistent with the generic architecture.
As a way of organizing the work of the development team The application architectures identify stable structural features of the system architectures and in many cases, it is possible to develop these in parallel. You can assign work to group members to implement different components within the architecture.
As a means of assessing components for reuse If you have components you might be able to reuse, you can compare these with the generic structures to see whether there are comparable components in the application architecture.
As a vocabulary for talking about types of applications If you are discussing a specific application or trying to compare applications of the same types, then you can use the concepts identified in the generic architecture to talk about the applications.
There are many types of application system and, in some cases, they may seem to be very different. However, many of these superficially dissimilar applications actually have much in common, and thus can be represented by a single abstract application architecture. I illustrate this here by describing the following architectures of two types of applications:
Transaction processing applications -Transaction processing applications are database-centered applications that process user requests for information and update the information in a database.
Language processing systems-Language processing systems are systems in which the user’s intentions are expressed in a formal language (such as Java). The language processing system processes this language into an internal format and then interprets this internal representation. The best-known language processing systems are compilers.
Now let us understand about each of them in detail -
Transaction Processing Systems (TP Systems):
Transaction Processing (TP) systems are designed to handle user requests related to information retrieval from a database or requests for updating a database.
A key concept in TP systems is the idea of a database transaction, which is a sequence of operations treated as a single atomic unit.
The completion of all operations within a transaction is essential before database changes become permanent. This ensures the consistency of the database even in the event of failures during transaction processing.
User Perspective on Transactions:
From a user's perspective, a transaction in any coherent sequence of operations that fulfils a specific goal, such as searching for flight times from London to Paris. If a user transaction doesn't necessitate changes to the database, it may not be treated as a technical database transaction.
Example of a Transaction:
An illustrative example of a transaction is a customer's request to withdraw money from a bank account using an ATM. This involves tasks like accessing the customer's account details, checking the balance, adjusting the balance based on the withdrawal amount, and instructing the ATM to dispense cash. Until all these steps are completed, the transaction is considered incomplete, and the customer accounts database remains unchanged.
Architectural Structure of Transaction Processing Systems:
Transaction processing systems are typically interactive and handle asynchronous user requests. The architectural structure of TP applications involves several components:
I/O Processing Component: Users make requests through this component, initiating the transaction.
Application Logic: The request is processed by application-specific logic.
Transaction Manager: Usually embedded in the database management system, the transaction manager ensures the proper completion of the transaction. It signals to the application that processing has finished.
Architecture of Transaction Processing Systems:
TP systems can be organized using a 'pipe and filter' architecture, where different components handle input, processing, and output. For instance, consider a banking system allowing customers to query accounts and withdraw cash from an ATM. The system comprises two cooperating software components—the ATM software and the account processing software in the bank's database server. Input and output components are implemented in the ATM, while the processing component resides in the bank's database server.
Transaction Processing Systems play a crucial role in managing database transactions, ensuring their atomicity, and handling user requests in an organized and reliable manner. The 'pipe and filter' architecture is a common approach to organizing the components involved in transaction processing.
1.1 Information Systems:
All systems involving interaction with a shared database can be considered transaction-based information systems.
Information systems facilitate controlled access to extensive information, such as library catalogues, flight timetables, or patient records in a hospital.
Increasingly, information systems are web-based, and accessed through web browsers.
The top layer supports the user interface, while the bottom layer represents the system database.
Layers include the user communications layer (handling input/output from the user interface) and the information retrieval layer (with application-specific logic for database access and updates).
This model can map directly onto servers in Internet-based systems.
Example Architecture (MHC-PMS):
Layers in the model include:
Top Layer: Implements the user interface (implemented via a web browser).
Second Layer: Provides user interface functionality, including login, role checking, form/menu management, and data validation.
Third Layer: Implements system functionality, including security, patient information management, data import/export, and report generation.
Bottom Layer: Utilizes a commercial database management system, providing transaction management and persistent data storage.
Web-Based Information and Resource Management Systems:
Modern information and resource management systems are typically web-based, utilizing web browsers for user interfaces.
E-commerce systems, for example, accept electronic orders and coordinate the delivery of goods or services.
Application-specific layers in e-commerce systems may include features like a 'shopping cart' for users to collect items and pay for them in a single transaction.
Server Organization in Web-Based Systems:
Systems are often implemented as multi-tier client-server architectures.
Components include:
Web Server: Manages user communications, with the user interface implemented via a web browser.
Application Server: Implements application-specific logic, information storage, and retrieval.
Database Server: Facilitates data movement to and from the database and manages transaction management.
Multiple servers enable high throughput, handling hundreds of transactions per minute, and scalability by adding servers as demand increases.
Language Processing Systems:-
Language processing systems translate natural or artificial languages into another representation, and in the case of programming languages, may also execute the resulting code.
Compilers in software engineering translate artificial programming languages into machine code.
The architecture of a Language Processing System for Programming Languages:
Source Language Instructions: Define the program to be executed.
Translator: Converts source language instructions into instructions for an abstract machine.
Abstract Machine: Represents the machine that will execute the instructions.
Interpreter: Fetches and executes instructions using data from the environment.
Output: The result of interpreting instructions on the input data.
Compiler Architecture in General Programming Environments :
Components:
Lexical Analyzer: Converts input language tokens to an internal form.
Symbol Table: Holds information about names of entities (variables, classes, objects) used in the text being translated.
Syntax Analyzer: Checks syntax using a defined grammar and builds a syntax tree.
Syntax Tree: Internal structure representing the compiled program.
Semantic Analyzer: Checks semantic correctness using information from the syntax tree and symbol table.
Code Generator: Walks the syntax tree and generates abstract machine code.
Other components may analyze and transform the syntax tree to improve efficiency and remove redundancy from generated machine code.
Alternative Architectural Patterns (Garlan and Shaw, 1993):
Composite of a repository and a pipe and filter model.
In a compiler architecture, the symbol table serves as a repository for shared data.
Phases of lexical, syntactic, and semantic analysis are organized sequentially and communicate through the shared symbol table.
Repository-Based Architecture-
Suitable for integrated programming support tools.
Symbol table and syntax tree act as a central information repository.
Tools or tool fragments communicate through the repository.
Grammar definition and output format definition are placed in the repository.
Enables immediate reflection of changes from one component to others.
The choice of architectural pattern depends on the context, with repository-based architecture being more suitable for integrated systems where immediate reflection of changes is crucial.