Databases and Systems

247
the Object Request Broker (ORB), which transparently transmits request from
clients to object implementations.
Once the interface for a distributed object is defined in IDL, any client can use it
depending only on the objects public interface. It is irrelevant to the client where the
object implementation resides or in what language it is implemented. In order to
invoke methods on the CORBA object, the client needs to obtain an object reference
for that object. The object reference serves as a proxy object on which the client can
invoke methods as defined in IDL
It is worth comparing the CORBA approach with the more familiar Remote
Procedure Call (RPC). Using RPC a client invokes a function on a server, while in
CORBA a client invokes a method on an object. Such a CORBA object is a purely
logical entity whose implementation is unknown to the client. In many cases the
server implements several CORBA objects as shown in Figure 1.
Figure 1 : RPC versus CORBA
Microsoft’s Distributed Component Object Model (DCOM) [3] is an important
alternative to CORBA. However, DCOM is not considered here because of its
proprietary nature and lack of cross-platform support.
Interfacing Databases with IDL
How should interfaces to databases look? Should the data model be reflected in IDL,
and if yes how? Since the answer to these questions depends very much on the
concrete application, the best way to find the “right” IDL is very often a use-case
analysis [8]. Several important cases will be examined in this section using the simple
example of protein sequences. It is important to understand that these different
possibilities do not exclude each other – they simply meet different requirements of
different applications. In our example, every protein sequence has a number of
attributes, one of which is a reference to an entry in the EMBL Nucleotide Sequence
Database.