Conceptual Architecture for Firebird.html

<h2>Conceptual Architecture for Firebird</h2>

<P>Hubert Chan and Dmytro Yashkir<BR>
Faculty of Mathematical, Statistical and Computer Sciences<BR>
University of Waterloo, Canada.<BR>
January 29, 2002</P>
<p>Updated by : Popa Adrian Marius<br> 
January , 2011
</p>
<H4>Abstract</H4>
<P>In this paper, we investigate the conceptual architecture for the Firebird
database. We identify the major components of the database system and their interactions.
Some of these components themselves have their own architectures, which we will also
discuss. We present some scenarios which illustrate the interactions between the
components. We show that the top-level architecture is styled after a pipe and
filter architecture, while each component may have its own architectural
style.</P>
<P><B>Table of Contents</B></P>
<P>Conceptual Architecture for Firebird 2.5</P>
<UL>
<LI>Introduction
<LI>Top-level architecture
<LI>Remote communication
<LI>SQL translator
<LI>JRD
<LI>JRD and Lock module
<LI>Use scenarios
<LI>Extensibility of Firebird
<LI>Conclusion
</UL>
<H4>Introduction</H4>
<P>
Software architecture presents developers with a tool for organizing large, complex
software systems into various components, allowing the developers to better understand
the system as a whole by reducing the number of components which must be kept in mind. It
allows each developer to focus on a smaller part of the system, and enables the
development team to integrate its work together by specifying the interfaces
between the various parts in a clear and well defined manner.</P>
<P>There are several different types of architectural views. The conceptual architecture is a high-level view, with
relatively few details, and is particularly well suited for describing the
functionality of a system.</P>
<P>In this paper, we investigate the conceptual architecture for the
Firebird database. Interbase is developed by Borland, and an open source
version (Interbase 6.0) was released in July 2000 under the InterBase Public License
(derived from the Mozilla Public License). However, due to Borland&rsquo;s attitude
towards community developers, the Firebird project was created, developing its own
database based on Borland&rsquo;s source code. </P>
<P>Firebird includes many tools and utilities for developing and administering a
database, and the code base includes code from older versions, as well as some experimental branches
(Firebird 3.0 with java extensions ). We will not be considering these in our analysis.</P>
<P>We begin by discussing the overall
architecture of the system. We then look at the architectures of some of the
subsystems, and we finally present scenarios which illustrate the behaviour of
the system in response to queries generated by clients.</P>
<H4>Top-level architecture</H4>
<P>Firebird can be divided into four
major components (see Figure 1): the remote connection system, the SQL
translator, the relational database engine, and the lock manager. The arrows in
the diagram indicate the flow of data. We include the clients in the diagram to
illustrate their relationship with the rest of the system.</P>
<img src="http://www.ibphoenix.com/images/doc_25_1.gif" align=middle border=0>
<P><I>Figure 1: Top-level architecture</I></P>
<P><B>remote connection system <a href=http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/branches/B2_5_Release/src/remote/>(REMOTE)</a>:</B> This subsystem allows remote clients
to connect to the database over different network protocols. It is composed of
two parts: a client-side component and a server-side component.
</P>
<P><B>SQL translator <a href=http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/branches/B2_5_Release/src/dsql/>(DSQL)</a>:</B> This subsystem translates requests from SQL into
BLR, the native language of the database.</P>
<P><B>relational database engine <a href=http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/branches/B2_5_Release/src/jrd/>(JRD)</a>:</B> This subsystem performs the actual
queries.</P>
<P><B>lock manager <a href=http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/branches/B2_5_Release/src/lock/>(LOCK)</a>:</B> This subsystem handles synchronization among
transactions.</P>
<P>The arrangement of the remote connection system, SQL translator, and relational
database engine, can be seen as a pipe and filter style of architecture: a request
flows through the remote
connection system, to the SQL translator, where it is converted to BLR. The BLR
goes through the relational database, which returns a request through the
remote connection system.</P>
<H4>Remote communication</H4>
<P>The remote communication subsystem, REMOTE, allows clients to communicate
remotely, or locally, with the server. It enables communication over several
different network protocols, such as TCP/IP, <a href=https://firebird.svn.sourceforge.net/svnroot/firebird/firebird/branches/B2_5_Release/doc/README.xnet>XNET</a> (replaced the former IPC/IPServer and is firebird implementation of the local transport protocol)
The subsystem is split roughly into two parts: a server side, and a client side. It
contains generic code for client-server communication, as well as
protocol-specific code.</P>
<P>It can be viewed as a layered system: conceptually, the client sends requests
to the server, through a generic communication layer. The generic layers communicate
through a protocol-specific layer, and the protocol-specific layers communicate through
the operating system's network stack. This is much like to a two-layered
version of the OSI reference network model.</P>
<P>
<img src="http://www.ibphoenix.com/images/doc_25_2.gif" align=middle border=0>
</P>
<P><I>Figure 2: Remote connection</I></P>
<P>The client can also communicate with the server locally, using a module which
emulates a network connection by using shared memory. </P>
<H4>SQL translator</H4>
<P>The SQL translator,>DSQL, converts SQL queries into the native BLR language. Its
architecture is like that of a simplified compiler: it contains a lexer,
parser, symbol table, and code generator.</P>
<P>
<img src="http://www.ibphoenix.com/images/doc_25_3.gif" align=middle border=0>
</P>
<P><I>Figure 3: SQL translator</I></P>
<P>As in all compilers, the lexer, parser, and code generator are arranged, conceptually,
as a pipeline. The lexer divides the input into tokens, the parser determines the
meaning of the input, based on the tokens, and the code generator emits BLR code which is
equivalent to the original SQL. </P>
<H4>JRD</H4>
<P>The JRD subsystem executes
requests and returns their results. It handles the access to the disk through a
virtual IO system, verifies that security constraints are followed, and ensures
that transactions are handled atomically.</P>
<P>Requests first pass through a
compiler, which translates from BLR into an internal representation of the
request. It calls the metadata subsystem, MET, to get metadata pertaining to
the request, and to ensure that the requested tables are present.
</P>
<P>
<img src="http://www.ibphoenix.com/images/doc_25_4.gif" align=middle border=0>
</P>
<P><I>Figure 4: Relational database engine</I></P>
<P>The Exec subsystem then
processes the requests, using the B-tree subsystem for indexing, the security
subsystem to check user priviledges, the transation subsystem to ensure atomic
execution of a series of requests, the sort subsystem to sort, and the lock
manager to ensure concurrency. It uses a virtual IO system to access the disk,
and it uses the metadata subsystem to operate on metadata. </P>
<P>The virtual IO subsystem is a
layered system with three layers. The top layer presents an abstract method for
accessing the data on the disk. The second layer, the cache manager, handes
caching of the data, to speed up data access. It is the last layer which has a
concept of structured data in the database. The final layer is a physical IO
layer which is specific to the operating system on which the engine is run, and
makes the system calls to access the disk.</P>
<H4>JRD and Lock module</H4>
<P>The main purpose of the lock
module is concurrency control, when multiple users are accessing same database
file simultaneously. Such situations are a common occurrence during the normal
operation of any DBMS.  </P>
<P>Lock handling is separated into
two major parts: the lock handler sub-module inside the JRD and the Lock module
that handles concurrent access to the lock table. Figure 5 illustrates
relationship between these parts.</P>
<P>
<img src="http://www.ibphoenix.com/images/doc_25_5.gif" align=middle border=0>
</P>
<P><I>Figure 5: JRD and Lock module</I></P>
<P>Requests that need access
to the lock mechanism are divided into two major categories, metadata
modification requests and usual data requests. Both of these categories use
lock the handler to be able to access the lock mechanism. </P>
<P>Normally when modification is
needed, a lock on the appropriate data is requested. Then modification is
performed and the lock is released. If it is impossible to gain a lock, the
lock handler can wait certain amount of time for the other lock handler to
release the lock and then resume normal execution.</P>
<P>The Lock module itself waits for
the requests from lock handlers. From their requests it performs modifications
to the lock table.</P>
<H4>Use scenarios</H4>
<P>This section describes two common
scenarios of the InterBase operation. These help better understanding of the
DBMS architecture.</P>
<H5>Scenario 1: New table creation</H5>
<P>This scenario describes the
creation of a new table in the database. When reading through the following
description, please refer to the appropriate diagrams above.</P>
<OL>
<LI>Request originates from the user
application, and is passed to Remote module client side</LI>
<LI>Requests is packaged depending on the network used and passed through the network
to the Remote server
side</LI>
<LI>DSQL is called to transform
request from SQL to BLR</LI>
<LI>JRD is called, CMP is called to compile the request</LI>
<LI>Exec is called to execute the request, MET is called</LI>
<LI>Request begins execution in MET since it modifies metadata for the DB</LI>
<LI>Lock handler is called to obtain a lock on the metadata of the DB</LI>
<LI>Lock handler calls Lock, which adds appropriate lock to the lock table</LI>
<LI>MET calls virtual IO library to commit changes to the disk</LI>
<LI>Appropriate disk handling routine is called depending on the file system</LI>
<LI>MET calls Lock handler, which calls Lock to remove lock from the Lock table</LI>
<LI>JRD calls Remote module to return success message to the user program</LI>
<LI>Remote moves the message through the network and get it to the user application</LI>
</OL>
<H5>Scenario 2: Search for a row by index field</H5>
<P>This scenario describes simple
search request to the database.</P>
<OL>
<LI>Request is created in the user application and passed to the Remote client side</LI>
<LI>Remote moves request to the server side and calls DSQL</LI>
<LI>DSQL transform SQL of the request into BLR</LI>
<LI>JRD is called and CMP compiles the request</LI>
<LI>EXEC starts executing the request</LI>
<LI>Virtual IO is called to get appropriate table</LI>
<LI>Cache is checked for the data requested</LI>
<LI>Search routine in B-tree module is called to find row with appropriate index</LI>
<LI>Remote is called and returns result of the search to the user application</LI>
</OL>
<H4>Extensibility of InterBase</H4>
<P>A good test for any system
architecture is how it can accommodate future changes and expansions. InterBase
existed under different names since 1985; obviously large number of changes and
enhancements was implemented since then. However the basic conceptual
architecture did not change.</P>
<P>First, let's examine some changes
made in the Remote module. With the appearance of a large number of new LAN
standards, Remote was modified to allow it to work with them. Since all of the
network communication routines are isolated in the remote module, these changes
do not affect other parts of the system. An example of such a modification is
the addition of the IPSERVER module inside Remote. It was added to allow users
to run InterBase on a single Windows-based machine where client and server
share one machine. This modification was relatively simple, even though there
is no LAN involved whatsoever in this implementation.</P>
<P>A second example of modifications
is the addition of the Windows file system to the Virtual IO module. To add the
ability to run InterBase on a machine using the Windows file system, the only
modification required was to add another subsystem in the IO system that
enables operation with the Windows file system.</P>
<H4>Conclusion</H4>
<P>In this paper, we discuss the conceptual architecture for InterBase. The system is
composed of four major compenents, arranged in a pipe and filter style. We also look at
the architecture within some of the subsystems. We provide scenarios illustrating
the behaviour of the system in response to different client requests and the
interactions between the subsystems, and we demonstrate how the architecture
allows for extensions to the system, such as new network protocols or file
systems.</P>
<H5>References</H5>
<P><A HREF="http://www.cs.cmu.edu/~garlan/">Garlan, David </A>and
<A HREF="http://www.cs.cmu.edu/afs/cs.cmu.edu/user/shaw/www/Shaw-home.html">Shaw, Mary</A>
,&ldquo;
<A HREF="http://web.archive.org/web/20010208083910/http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/intro_softarch.html">An
Introduction to Software Architecture&rdquo;</A>, <I>Advances in Software
Engineering and Knowledge Engineering</I>, Volume 1, World Scientific
Publishing Co., 1993.<BR>
Harrison, Ann and Beach, Paul; &ldquo;
<a href="http://www.ibphoenix.com/resources/documents/search/doc_32">A Cut Out and Keep Guide to the Firebird Source Code</a>&rdquo;; IBPhoenix; October 2001.<br>
Harrison, Ann; &ldquo;
<A HREF="http://web.archive.org/web/20020213052216/http://www.ibphoenix.com/ibp_source_overview.html">High-level Description
of the InterBase 6.0 Source Code</A>&rdquo;; IBPhoenix.<br>
Kruchten,
Phillipe B., <a href="http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf">The
4+1 Views Model of Architecture</A>, IEEE Software, Nov 95, pp
42-50.<br>
<a href="http://www.ibphoenix.com/resources/documents/search/doc_119">Y-Valve Architecture</a> , From Jim Starkey on the Firebird Development List 13th December 2003.<br>
<a href="http://www.ibphoenix.com/resources/documents/attic/doc_116"> Vulcan Architecture</a> 30th Apr 2004 Vulcan Development page.<br>
<a href="http://www.ibphoenix.com/resources/documents/design/doc_33"> OSRI Architecture </a> The Philosophy, The Model , The API ,Layering and Implementation Rules.<br>
</p>

Conceptual Architecture for Firebird_Romanian.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ro"
      lang="ro"> 
  <head> 
    <meta http-equiv="Content-Type"
          content="text/html;charset=utf-8" /> 

<h2>Arhitectura Conceptuala pentru Firebird</h2>

<P>
Autorii Originali:
Hubert Chan and Dmytro Yashkir<BR>
Faculty of Mathematical, Statistical and Computer Sciences<BR>
University of Waterloo, Canada.<BR>
January 29, 2002</P>
<p>Adusa la zi : Popa Adrian Marius<br> 
12 Decembrie 2010
</p>
<H4>Introducere</H4>
<p>
In aceasta lucrare, investigam arhitectura conceptuala pentru sistemul de baze de date Firebird. Identificam componentele majore si interctiunile intre ele. Cateva din aceste componente au o arhitectura proprie pe care deasemeni o vom discuta.Prezentam cateva scenarii care ilustreaza interactiunile dintre aceste componente.V-om arata ca arhitectura de baza este organizata dupa o arhitectura pipe(teava) si filtru cu fiecare componente avand stil propriu de architectura. 
</p>
<P><B>Cuprins</B></P>
<P>Architectura conceptuala pentru Firebird 2.5</P>
<UL>
<LI>Introducere
<LI>Architectura de nivel superior
<LI>Comunicarea la distanţă
<LI>Translatorul SQL
<LI>JRD
<LI>JRD si modulul Lock (Blocare)
<LI>Scenarii de utilizare
<LI>Extensibilitatea sistemului Firebird
<li>Concluzii
</ul>
<h4>Introducere</H4>
<p>
Arhitectura Software le prezinta dezvoltatorilor o unealta sa organizeze sisteme mari ,complexe 
in componente variate permitand dezvoltatorilor o mai buna intelegere a sistemului ca intreg si 
reducand numarul de componente ce trebuie tinute in minte.Ii permite fiecarui dezvoltator sa se
concentreze pe o bucata mai mica din sistem si astfel ii permite echipei de dezvolatare sa integreze
munca sa prin specificare unor interfete intre diversele parti intr-o maniera curata/concisa si bine definita.
</p>
<p>
Existam mai multe tipuri de vederi arhitecturale, Architectura conceptuala este o vedere de nivel inalt cu relativ 
putine detalii , si este in mod particular bine potrivita pentru descrierea functionalitatii unui sistem.
</p>
<p>
In aceasta lucrare , ne intereseaza arhitectura conceptuala pentru sistemul relational Firebird.
Interbase a fost dezvoltat de Borland , apoi o versiune (Interbase 6.0) a fost facuta libera cu sursele deschise
si lansata in anul 2000 (Iulie) sub licenta InterBase Public License (derivata din Mozilla Public License). Totusi , 
datorita atitudinii Borland impotriva comunitatii de dezvoltatori , proiectul Firebird a fost creat si dezvolta propriu 
sistem relational pornind de la sursele publicate de Borland. 
</p>
<p>
Firebird include multe instrumente si utilităţi pentru dezvoltare si administrare a bazeleor de date,
codul de baza (svn repository) contine si cod din versiunile mai vechi precum si ramuri experimentale (Firebird 3.0 cu 
proceduri externe scrise in Java, C++). Nu vom considera acestea in analiza noastra.
</p>

<p>
Incepem prin a discuta arhitectura globală a sistemului, Dupa care ne uitam la arhitectura unora din subsisteme, in final 
prezentam cateva scenarii care sa ne ajute sa ilustram comportamentul sistemului in raspus la interogările generate de clienti
</p>

<h4>Architectura de nivel superior</h4>
<p>
Sistemul Firebird poate fi divizat in patru componente majore (vezi Figura 1): 
sistemul de conexiune la distanta, translatorul SQL , motorul relational , si manager de 
blocare (Lock Manager).Sagetile in diagrama indica fluxul de date.Include clientii in diagrama pentru a 
indica relatia lor cu restul sistemului.
</p>
<img src="http://www.ibphoenix.com/images/doc_25_1.gif" align=middle border=0>
<p><i>Figura 1: Architectura de nivel superior</i></p>
<p><b>sistemul de conexiune la distanta (REMOTE):</b>	Acest subsistem permite clientilor aflati la distanta sa se conecteze la baza de date
folosind diferite protocoale de retea.Este compus din doua parti pe partea de client 
si pe partea de server.

<p> 
<p><b>Translatorul SQL (DSQL):</b>	Acest subsistem translateaza cererile din SQL in BLR, limbajul nativ al sitemului relational.<p>
<p><b>Motorul relational al sistemului(JRD):</b> Acest subsistem efectuează si executa interogarile. </p>
<p><b>Sistemul de blocare (LOCK):</b> Acest subsistem asigura sincronizarea intre tranzactii 
transactions.</p>
<p>Acest aranjament intre Sistemul de conexiune la distanta , Translatorul SQL si Motorul relational poate fi privit ca o arhitectura tip teava si filtru: o cerere curge prin conexiunea la distanta pana la translatorul SQL , de unde este convertit in limbajul BLR.BLR merge prin sistemul relational (motor) si întoarce o cerere prin sistemul de conexiune la distanta</p>
<h4>Sistemul de conexiune la distanta</h4>
<p>Sistemul de conexiune la distanta , REMOTE permite clientilor sa comunice 
la distanta sau local cu serverul. Permite comunicarea folosind protocoale diferite 
precum TCP/IP ,IPC (XNET) , Lan Manager. Subsistemul este impartit in doua parti : partea 
de server si partea de client. Contine cod generic pentru comunicarea client-server precum si 
cod specific pentru fiecare protocol.</p> 
<p>Poate fi privit ca un sistem stratificat: conceptual , clientul trimite cereri 
spre server , printr-un canal,nivel generic de comunicare. Straturile generice comunica
printr-un protocol specific fiecarui nivel, si fiecare nivel specific protocolului comunica prin 
nivelul de retea al sistemului. Aceasta seamana cu un model de retea OSI stratificat pe doua nivele.
<p>
<p>
<img src="http://www.ibphoenix.com/images/doc_25_2.gif" align=middle border=0>
</p>
<P><I>Figure 2: Remote connection</I></P>
<P>The client can also communicate with the server locally, using a module which
emulates a network connection by using shared memory. </P>
<H4>SQL translator</H4>
<P>The SQL translator,>DSQL, converts SQL queries into the native BLR language. Its
architecture is like that of a simplified compiler: it contains a lexer,
parser, symbol table, and code generator.</P>
<p>
<img src="http://www.ibphoenix.com/images/doc_25_3.gif" align=middle border=0>
</p>
<p><I>Figure 3: SQL translator</I></P>
<p>As in all compilers, the lexer, parser, and code generator are arranged, conceptually,
as a pipeline. The lexer divides the input into tokens, the parser determines the
meaning of the input, based on the tokens, and the code generator emits BLR code which is
equivalent to the original SQL. </P>
<H4>JRD</H4>
<P>The JRD subsystem executes
requests and returns their results. It handles the access to the disk through a
virtual IO system, verifies that security constraints are followed, and ensures
that transactions are handled atomically.</P>
<P>Requests first pass through a
compiler, which translates from BLR into an internal representation of the
request. It calls the metadata subsystem, MET, to get metadata pertaining to
the request, and to ensure that the requested tables are present.
</P>
<P>
<img src="http://www.ibphoenix.com/images/doc_25_4.gif" align=middle border=0>
</P>
<P><I>Figure 4: Relational database engine</I></P>
<P>The Exec subsystem then
processes the requests, using the B-tree subsystem for indexing, the security
subsystem to check user priviledges, the transation subsystem to ensure atomic
execution of a series of requests, the sort subsystem to sort, and the lock
manager to ensure concurrency. It uses a virtual IO system to access the disk,
and it uses the metadata subsystem to operate on metadata. </P>
<P>The virtual IO subsystem is a
layered system with three layers. The top layer presents an abstract method for
accessing the data on the disk. The second layer, the cache manager, handes
caching of the data, to speed up data access. It is the last layer which has a
concept of structured data in the database. The final layer is a physical IO
layer which is specific to the operating system on which the engine is run, and
makes the system calls to access the disk.</P>
<H4>JRD and Lock module</H4>
<P>The main purpose of the lock
module is concurrency control, when multiple users are accessing same database
file simultaneously. Such situations are a common occurrence during the normal
operation of any DBMS.  </P>
<P>Lock handling is separated into
two major parts: the lock handler sub-module inside the JRD and the Lock module
that handles concurrent access to the lock table. Figure 5 illustrates
relationship between these parts.</P>
<P>
<img src="http://www.ibphoenix.com/images/doc_25_5.gif" align=middle border=0>
</P>
<P><I>Figure 5: JRD and Lock module</I></P>
<P>Requests that need access
to the lock mechanism are divided into two major categories, metadata
modification requests and usual data requests. Both of these categories use
lock the handler to be able to access the lock mechanism. </P>
<P>Normally when modification is
needed, a lock on the appropriate data is requested. Then modification is
performed and the lock is released. If it is impossible to gain a lock, the
lock handler can wait certain amount of time for the other lock handler to
release the lock and then resume normal execution.</P>
<P>The Lock module itself waits for
the requests from lock handlers. From their requests it performs modifications
to the lock table.</P>
<H4>Use scenarios</H4>
<P>This section describes two common
scenarios of the InterBase operation. These help better understanding of the
DBMS architecture.</P>
<H5>Scenario 1: New table creation</H5>
<P>This scenario describes the
creation of a new table in the database. When reading through the following
description, please refer to the appropriate diagrams above.</P>
<OL>
<LI>Request originates from the user
application, and is passed to Remote module client side</LI>
<LI>Requests is packaged depending on the network used and passed through the network
to the Remote server
side</LI>
<LI>DSQL is called to transform
request from SQL to BLR</LI>
<LI>JRD is called, CMP is called to compile the request</LI>
<LI>Exec is called to execute the request, MET is called</LI>
<LI>Request begins execution in MET since it modifies metadata for the DB</LI>
<LI>Lock handler is called to obtain a lock on the metadata of the DB</LI>
<LI>Lock handler calls Lock, which adds appropriate lock to the lock table</LI>
<LI>MET calls virtual IO library to commit changes to the disk</LI>
<LI>Appropriate disk handling routine is called depending on the file system</LI>
<LI>MET calls Lock handler, which calls Lock to remove lock from the Lock table</LI>
<LI>JRD calls Remote module to return success message to the user program</LI>
<LI>Remote moves the message through the network and get it to the user application</LI>
</OL>
<H5>Scenario 2: Search for a row by index field</H5>
<P>This scenario describes simple
search request to the database.</P>
<OL>
<LI>Request is created in the user application and passed to the Remote client side</LI>
<LI>Remote moves request to the server side and calls DSQL</LI>
<LI>DSQL transform SQL of the request into BLR</LI>
<LI>JRD is called and CMP compiles the request</LI>
<LI>EXEC starts executing the request</LI>
<LI>Virtual IO is called to get appropriate table</LI>
<LI>Cache is checked for the data requested</LI>
<LI>Search routine in B-tree module is called to find row with appropriate index</LI>
<LI>Remote is called and returns result of the search to the user application</LI>
</OL>
<H4>Extensibility of InterBase</H4>
<P>A good test for any system
architecture is how it can accommodate future changes and expansions. InterBase
existed under different names since 1985; obviously large number of changes and
enhancements was implemented since then. However the basic conceptual
architecture did not change.</P>
<P>First, let's examine some changes
made in the Remote module. With the appearance of a large number of new LAN
standards, Remote was modified to allow it to work with them. Since all of the
network communication routines are isolated in the remote module, these changes
do not affect other parts of the system. An example of such a modification is
the addition of the IPSERVER module inside Remote. It was added to allow users
to run InterBase on a single Windows-based machine where client and server
share one machine. This modification was relatively simple, even though there
is no LAN involved whatsoever in this implementation.</P>
<P>A second example of modifications
is the addition of the Windows file system to the Virtual IO module. To add the
ability to run InterBase on a machine using the Windows file system, the only
modification required was to add another subsystem in the IO system that
enables operation with the Windows file system.</P>
<H4>Conclusion</H4>
<P>In this paper, we discuss the conceptual architecture for InterBase. The system is
composed of four major compenents, arranged in a pipe and filter style. We also look at
the architecture within some of the subsystems. We provide scenarios illustrating
the behaviour of the system in response to different client requests and the
interactions between the subsystems, and we demonstrate how the architecture
allows for extensions to the system, such as new network protocols or file
systems.</P>
<H5>References</H5>
<P><A HREF="http://www.cs.cmu.edu/~garlan/">Garlan, David </A>and
<A HREF="http://www.cs.cmu.edu/afs/cs.cmu.edu/user/shaw/www/Shaw-home.html">Shaw, Mary</A>
,&ldquo;
<A HREF="http://web.archive.org/web/20010208083910/http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/intro_softarch.html">An
Introduction to Software Architecture&rdquo;</A>, <I>Advances in Software
Engineering and Knowledge Engineering</I>, Volume 1, World Scientific
Publishing Co., 1993.<BR>
Harrison, Ann and Beach, Paul; &ldquo;
<A HREF="http://web.archive.org/web/20020406105328/http://www.ibphoenix.com/ibp_source_guide.html">InterBase
Source Code Guide</A>&rdquo;; IBPhoenix; October 2001.<BR>
Harrison, Ann; &ldquo;
<A HREF="http://web.archive.org/web/20020213052216/http://www.ibphoenix.com/ibp_source_overview.html">High-level Description
of the InterBase 6.0 Source Code</A>&rdquo;; IBPhoenix.<BR>
Kruchten,
Phillipe B., <a href="http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf">The
4+1 Views Model of Architecture</A>, IEEE Software, Nov 95, pp
42-50.<br>
<a href=http://ibphoenix.com/main.nfs?a=ibphoenix&page=vul_y_valve>Y-Valve Architecture</a> , From Jim Starkey on the Firebird Development List 13th December 2003<br>
<a href=http://ibphoenix.com/main.nfs?a=ibphoenix&page=vul_architecture> Vulcan Architecture</a> 30th Apr 2004 Vulcan Development page<br> 
</P>