Shared-Data Style
4.2.1 Overview
In the shared-data style, the pattern of interaction is dominated by the exchange of persistent data. The data has multiple accessors and at least one shared-data store for retaining persistent data.
Database systems and knowledge-based systems are examples of this style. One feature of a shared-data style is the method by which the data consumer discovers that data of interest is available. If the shared-data store informs data consumers of the arrival of interesting data, the shared-data style is called a blackboard. If the consumer has responsibility for retrieving data, the shared-data style is called a repository. In modern systems, these distinctions have been blurred, as many database management systems that were originally repositories now provide a triggering mechanism that turns them into blackboards.
4.2.2 Elements, Relations, and Properties
The shared-data style, summarized in Table 4.2, is organized around one or more shared-data stores, which store data that other components may read and write. Component types include shared-data stores and data accessors. The general computational model associated with shared-data systems is that data accessors perform calculations that require data from the data store and writing results to one or more data stores. That data can be viewed and acted on by other data accessors. In a pure shared-data system, data accessors interact only through the shared-data store(s). However, many shared-data systems also allow direct interactions between nonstore elements. The data-store components of a shared-data system provide shared access to data, support data persistence, manage concurrent access to data, provide fault tolerance, support access control, and handle the distribution and caching of data values.
The stylistic specializations differ along two dimensions: the nature of stored data and the control model. In the blackboard style, data accessors are sometimes called knowledge sources, and the shared-data store is called the blackboard. The computational model for such systems is that knowledge sources are "triggered," or invoked, when certain kinds of data appear in the database. The computation of a triggered knowledge source will typically change the data in the blackboard, thereby triggering the actions of other knowledge sources. Blackboard systems differ in how the data is structured within the blackboard and in the mechanisms for prioritizing the invocation of knowledge sources when more than one is triggered.
| Elements |
|
| Relations | Attachment relation determines which data accessors are connected to which data repositories. |
| Computational model | Communication between data accessors is mediated by a shared-data store. Control may be initiated by the data accessors or the data store. |
| Properties | Same as defined by the C&C viewtype and refined as follows: types of data stored, data performance-oriented properties, data distribution. |
| Topology | Data accessors are attached to connectors that are attached to the data store(s). |
One of the first systems to employ the blackboard style was a speech-understanding system called Hearsay II [Nii 1986]. A more modern variation is provided by "tuple spaces," as exemplified by Linda and JavaSpaces. A tuple space is a repository that contain tuples, or lists of values. Clients communicate with one another by releasing dataa tupleinto tuple space. Clients can also register to be notified of changes in a tuple space. Other forms of such triggered databases are sometimes called continuous-query databases.
A particular portion of a system will be either a blackboard or a pure repository, depending on where the initiative lies in accessing data. Trigger mechanisms are common in systems that use work-flow management to inform data accessors of the modification of particular types of data making that use a blackboard. In other portions of such systems, the data accessor is responsible for initiating a query. Thus, it is important to identify those data accessors that can initiate a query and those that are triggered by actions on particular data. If data accessors are triggered by the respository, the circumstances under which the triggers are activated are important to document.
4.2.3 What the Shared-Data Style Is For and What It's Not For
The shared-data style is used whenever various data items have multiple accessors and persistence. Use of this style has the effect of decoupling the producer of the data from the consumers of the data; hence, this style supports modifiability, as the producers do not have direct knowledge of the consumers.
Analyses associated with this style usually center on performance, security, privacy, reliability, and compatibility with, for example, existing repositories and their data. In particular, when a system has more than one data store, a key architectural concern is the mapping of data and computation to the data stores and their local data accessors. For example, distributing data or providing redundant copies may improve performance but often at the cost of added complexity and a decrease in reliability and security.
4.2.4 Relation to Other Styles
This style has aspects in common with the client-server style, especially the n-tiered client-server form. In information management applications that use this style, the data store is often a relational database, providing relational queries and updates using client-server interactions. In other cases, the data store and its associated servers may provide an object-oriented data model, in which object methods become the main form of interaction with the data. Enterprise JavaBeans is a good example of an architectural framework in this style.
The publish-subscribe style is similar to the blackboard style except it lacks persistence of the data.
4.2.5 Example of the Shared-Data Style
Figure 4.3, taken from Appendix A, shows part of a shared-data view of the ECS system.
Figure 4.3. The primary repository of the ECS system. The gateways and maintenance tool are data accessors; SYBASE and DS are components of the data repository.