You have to build an object/relational access layer alongside legacy applications on a host computer. Both suites of applications, the old transaction based applications and your new object-oriented applications should use the same host database access layer so that you have single source on you host computer. Most off the shelf access layer products are constructed on top of an ODBC interface. This does not combine well with a transaction system, as running a host as a remote SQL server is not the way things are handled.
How do you connect an object/relational access layer to a host computer running a transaction system?
Performance versus straightforward design: The straightforward design that provides access to a relational database on a host computer is to run the host as a remote SQL server. Unfortunately this is not fast enough and does not offer enough possibilities for tuning on a transaction system.
Single source: You want to use access layer modules from your host applications as well as from client applications.
Integration of legacy systems: You might want to add other legacy data sources like IMS/DB databases or flat files.
all queries to a communication agent, using bundled
write. Install another communication agent on your host computer that
unpacks the query packets and executes them one by one under the control of the
host transaction monitor. Send back a packet containing query results or the
return codes of the access layer modules from the host computer.
Connecting and object/relational access layer to a host transaction system [Kel+98b
The structure (see Figure 7 ) shows the following similarities and differences compared to a normal object/relational access layer based on a remote database driver based on ODBC or similar:
The interface of the tuple layer remains unchanged.
Insert a client and a host communication agent below the tuple layer. The client communication agent bundles write queries (see bundle manager in the bundled write pattern). The client communication agent is an object that buffers requests and does not execute them before it is told to do so. If the other communication agent on the host side receives a bundle of requests, it executes them one by one by calling access modules, buffers the results and sends back a bundle of results. The client communication agent only checks return codes and delivers results if necessary.
Install another communication agent as a dispatcher and write it as a host transaction (e.g. under IMS/TM or CICS).
Have this host communication agent call the host access layer modules that implement the functionality of your client's query objects - the query objects are proxies for the host access layer modules.
The host access layer modules will access the database.
Performance versus straightforward design: This solution offers reasonable performance, as we can see in more than one independent productive systems [Bar+95 , Sta+97 ]
Single source: is given, as the host database modules can be used from both object-oriented client applications and conventional host applications. A project to write the host access layer can normally justified from the gains of productivity that result from using the host access layer from host applications alone.
Integration of legacy systems: It is straightforward to wrap another data source than a relational database by host access layer modules.
This pattern is an application of proxies [GOF95 ] in the sense that the query objects on the client are proxies for the host access layer modules. The communication agents on the host and on the client implement bundled write.
The Hypo-Project [Bar+95 , Kel+98b ] uses this pattern as well as the Phoenix project. TopLink offers a separate mainframe interface as a byproduct to its standard access layer product. This is used in the Phoenix project [Sta+97 ] together with a host access layer written in C.