Pattern: Query Broker



A Query Broker is a very comfortable, though expensive, form of decoupling logical and physical views in a database access layer.


Consider the running example of an invoice . The OrderInvoiceView models the logical data structure while the OrderPhyiscalView and the CustomerPhysicalView model the corresponding physical tables.


You have decided to use the Relational Database Access Layer. You use Hierarchical Views as interface to the application kernel and Physical Views to encapsulate database access.


How to connect the Hierarchical Views, that make the Logical Access Layer and the Physical Views, that make the Physical Access Layer for reading and writing?



Use a Broker [Bus+96] to connect the layers. The Hierarchical Views form the client side of the Query Broker, the Physical Views constitute the server side. Describe services using directed acyclic graphs (DAG) and use a tree matching algorithm to find best matches. Let the Query Broker assemble the Physical Views and deliver the result in a Query Result container.


A Broker is a standard technique for decoupling. Use the standard structure and adapt it to the Database Access Layer framework:

Figure 8 :           The Query Broker is a Broker adapted to the Database Access Layer Framework.

Figure 9 :           Tree matching to resolve requests to the Query Broker. The left side shows the OrderInvoiceView of our order processing system, the right side depicts the corresponding two Physical Views. If the Query Broker gets the left presentation as request, it figures out that the Physical Views on the right side are the best way to satisfy the request.

Dynamic Behavior

In the following scenario an application kernel object creates an OrderInvoiceView causing a database read(). The QueryBroker handles the read() and matches a view description against available services via the matchServices() method. The QueryBroker forwards the request to two different ConcretePhysicalViews: the OrderPhysicalView and the CustomerPhysicalView. These two read() the data from the database and deliver the results by packing the data into result containers. The Broker has to merge both result containers to deliver one result to the OrderInvoiceView. The OrderInvoiceView unpacks the data into its instance variables.


Figure 10 :         Retrieving data via a Query Broker.




A further refined variant of a Query Broker allows a very flexible development process. A Query Broker that is also enabled to generate on-the-fly dynamic SQL queries can be used to substitute the Physical Access Layer during early development stages. This works fine for clean database models but becomes hard with Overflow Tables.

Later, you add more and more Physical Views using static SQL. If even this proves to be too slow, the Physical View implementations can be made even faster using the tuple interface of the database. The Query Broker shields the application kernel from such tuning. It responds to request with the fastest services he can find in his registry.

Related Patterns

[Bus+96] contains a comprehensive discussion of Brokers in general.

Brown and Whitenack describe a Broker [Bro+96] on a per class basis. Note, that Query Broker is more general.

Known Uses

The Query Broker is a compilation of various best practices:

The VAA data manager [VAA95] defines views in terms of the logical data model. It uses a generated hard wired coupling of layers. Our experiences at HYPO-Bank [Kel+96a, Col+96] taught us to use dynamic descriptions wherever possible. Two projects at sd&m used other important parts of the approach.

sd&m’s LSM project used dynamic SQL, migrated to static SQL and ended up with a tuple interface. The idea was born from bad experiences with a slow database server. The project makes extensive use of a runtime data dictionary and bridges dynamic queries and pre-compiled queries completely.

The Fall/OK project for the German police uses tree matching. The software copes with queries by example on a large data model. The data model changes very rapidly.

CORBA Persistent Object Service [Ses96] also use a Broker. Application kernel objects write their instance data to streams and a Broker (Persistent Object Manager) forwards the stream to some Persistent Object Service (database or other). Persistent Object Services may be arbitrary databases not known to the object. This is also the simple a case of a one to one mapping between service requests and servers that fulfill them. Note that this design is now (2000) replaced by another one.