Databases Reference
In-Depth Information
12.4.3
Service-Oriented DBMSs
In the service-oriented approach, DB tasks are unbundled from each other
and represented as services. Each service is implemented on top of a common
platform. Services should be as independent as possible from each other, that
is, they should not rely on the availability of another service in the environ-
ment. Specifically, they should not assume that other services are imple-
mented in a particular way. Thus, DB services and their implementations
are viewed as components. Given that both the platform and the service
interfaces are standardized, exchangeability and compatibility are guaran-
teed. Different implementations of a service can be exchanged, and imple-
mentations of different services—possibly from different vendors—can be
plugged together.
An example of this approach is CORBAservices [39], which leverages
several DBMS tasks to general object systems. These services are standardized
by the Object Management Group (OMG). Service interfaces are defined
using the IDL. Services related to DB functionality include persistency, con-
currency, relationships, transactions, queries, and collections.
CORBAservices offers further non-DB services such as licensing and
event notification. Whenever a system (e.g., an application server) to be
implemented needs some DB functionality, it can receive the appropriate
support by using the corresponding service. Such requests are handled in a
location-transparent way by object request brokers (ORB) [40], which form
the platform on top of which services are implemented.
In contrast to the other approaches discussed here, components (i.e.,
services) are not meant to extend or customize a DBMS. Rather, the systems
constructable by using services are distributed applications located above
the DBMS level. In fact, services like persistence could be implemented by a
DBMS, and the transaction service is typically implemented by transaction
processing monitors [41].
The underlying semantics and models (such as the transaction model
and the query language) are fixed. Thus, for a transaction service, there will
be different implementations all implementing transactions such as flat
or nested ACID-transactions, but transactions such as cooperative or other
forms of nonstandard transactions [42] would not be supported.
A second example for this approach is the so-called strawman architec-
ture [10] developed at CCA. The aim of that study was to propose standard
interfaces between users/applications and DBMSs as well as standards for
internal interfaces (such that different DBMS subsystems can be combined
more easily). The CCA study identified 79 subcomponents, which are
