The legacy problem -- integrating CORBA
[]
introduction,
legacy,
interfaces,
examples,
conclusions,
references,
appendix
CORBA technology is well-suited to develop
distributed applications.
For new projects, the restrictions imposed by
CORBA can be taken into consideration from the start.
For projects that carry the legacy of existing code,
a decision must be made to what extent the
CORBA functionality is integrated with the legacy code.
On one side of the spectrum,
CORBA technology can be used simply for wrapping the legacy
code.
For example a database may be embedded
in a CORBA server, without affecting the database itself.
However, for an object-oriented framework such as hush
such a solution is not very satisfying.
Instead, one would like to have the basic
interfaces of hush available to develop
distributed components of arbitrary granularity.
In this section, we will discuss some of the issues
that arise when extending a given (GUI or hypermedia)
framework with CORBA IDL interfaces reflecting
the functionality of the original framework.
Object creation and access
The CORBA Naming Service may be used to provide access to
an object residing somewhere on a server.
Alternatively, the server may export a reference to
a factory object that allows the client to create objects within the
server.
For giving access to objects within a particular hush
component, we have provided dots (distributed object tables)
for both hush and widgets components.
Using the dot the client can access an object of a given type by
the name it is given by the server.
The object must already exist in the server.
In case clients are allowed to create objects within
the server, a factory is provided for creating hush
or widget objects.
Client-side adaptors
The intermediary between clients and servers in a CORBA-based system
are the CORBA IDL classes generated by the idl compiler
from the IDL interfaces.
These classes (using the C++ language binding)
inherit directly from the CORBA::Object class and hence
do not fit within the given class hierarchy.
To allow clients the use of CORBA IDL classes wherever one
of the original hush classes is expected,
client-side adaptors have been provided for each of the hush
or widgets IDL classes.
An additional advantage of client-side adpators is that
they allow for overcoming the
'weaknesses' of IDL with respect to
overloading member functions,
parametrized types and operator definitions.
Typically, client-side adaptors have their corresponding hush class
as a base class and simply delegate method invocations
to the CORBA object they encapsulate.
Events versus object method invocation
Since GUI components are in some way typically
event-driven, one may be inclined to limit
the communication between such components to exchanging events.
The CORBA Event Service would suffice for such communications.
Nevertheless, in our opinion events should be used in a very restricted manner.
Events tend to break the 'crisp' object interfaces that
are one of the benefits of an object-oriented
approach to design.
For the hush CORBA extensions, we have chosen for retaining the original hush
object interfaces.
Note however that the IDL interfaces are somewhat more
abstract than the corresponding C++ interfaces.
Nevertheless, the event interface is part
of the hush module.
Together with the dispatch function of
the handler interface incoming events resulting from user
actions may be dispatched directly to
remote components. See the [Canvas] example.
[]
introduction,
legacy,
interfaces,
examples,
conclusions,
references,
appendix