There are virtually limitless factors
needed to be taken into consideration when evaluation client/server
architecture. These factors range from hardware requirements,
deployment topology, communication protocol, middleware requirements,
integration of management interface, security aspects, scalability
(horizontal and vertical) of the solution, development application
interfaces, etc. Similarly, client/server database has a number of
characteristics which can impact the overall solution. Peter Rob et
al. (2009) notes that these include interoperability and remote query
execution.
On of the most important
client/server database management system characteristic is
interoperability which manifest itself in the ability to “provide
transparent data access to multiple and heterogeneous clients”
(Peter Rob, Carlos Coronel and Steven Morris, 2009. Appendix F. Page
158). Numerous clients written in Java, .NET, C/C++ or Perl have the
capacity to interact with the database management server to retrieve
or update information through usage of standard protocols such as
ODBC and JDBC.
In addition, client/server DBMS
architecture allow the end-user to manipulate the information stored
in the server DBMS in a number of forms. For example, one design can
utilize resources (often distributed) allocated to the DBMS server to
process the information (thin client), while another design can
distribute the information processing relying on the computing
resources of the clients (fat client). Peter Rob et al. (2009) notes
that in many cases, the client/server architecture is closely related
to distributed database management systems (DDBMS) where the
processing of a single query can take place on a number of remote
servers.
The client/server database
architecture can take a number of forms. Peter Rob et al. (2009)
mentions 2-tier and 3-tier architecture which adds a middleware
between the client and the server tierd. The middleware, as the name
suggests, has a number of functions to facilitate connectivity to the
database management server ranging from exposing ODBC or MQ API,
converting query formats and managing security aspect (authentication
and authorization). Mohammad Ghulam Ali (2009) suggests a 4-tier
database architecture which adds a Global Database Management System
component to decompose the query “into a set of sub queries to be
executed at various remote heterogeneous local component database
servers” (Ali, M 2009).
As with any application,
distribution of business logic and/or presentation increases the
number of attack vectors, thus requiring thorough
risk assessment and implementation of appropriate compensating
controls to secure the overall solution (Cherry, D 2011). For
example, distribution of information from a single location into
multiple clients can have a security impact on information considered
as private or confidential.
Don Klely (2011) notes that additional security controls should be
implemented to compensate for the remote storage (on the client side)
and transportation of the information. Although this can be solved
through a trivial implementation of SSL/TLS protocol between the
database server and clients, the solution designer has to consider
all applicable risks (both technical and operational) before deciding
on the optimal compensating control(s).
Bibliography
- Ali, M 2009, 'A Multidatabase System as 4-Tiered Client-Server Distributed Heterogeneous Database System', arXiv, EBSCOhost, viewed 16 August 2012.
- Cherry, D 2011, Securing SQL Server [Electronic Book] : Protecting Your Database From Attackers / Denny Cherry, n.p.: Burlington, MA : Syngress, 2011., University of Liverpool Catalogue, EBSCOhost, viewed 16 August 2012.
- Kiely, D 2011, 'Key Ways to Secure ASP.NET Applications with a SQL Server Back End', SQL Server Magazine, 13, 12, pp. 27-31, Computers & Applied Sciences Complete, EBSCOhost, viewed 16 August 2012.
- Peter Rob, Carlos Coronel and Steven Morris, 2009. “Database Systems: Design, Implementation and Management”. 9th Edition. Course Technology.
