Design Pattern Collection
4.3 Architecture and Design Patterns
4.3.3 Integration of components
Software components encapsulate functionality that is either provided locally, or remotely by an external system. For example, a service providing weather data.
As already mentioned before, data / knowledge in a knowledge processing system can come from many different sources that must be integrated. External systems provide their ser-vice via a remote communication technology (for example a web serser-vice). For integration, usually a separate integration layer is introduced, but this can also be in the business logic layer, where all the other services are located by wrapping the technology code, needed to access external services.
External Systems
This section concentrates on the connectors and messaging channels. These are the various types of how a system can communicate with another one. For this collection, it is assumed that the various endpoints needed for communication already exist (these will be handled in section 4.3.5).
Requirements
The development of external systems is not under the control of the software engineer re-sponsible for the knowledge processing system. Interfaces or data structures can change, or even be substituted completely. Also, the internal representation of data in a knowledge pro-cessing system can differ from the structure that an external service provides. When com-munication takes long (e.g., because of large amounts of data), polling should be avoided.
Also the external system can use different technologies for remote communication.
• Loose coupling to external services allows exchanging them easily (e.g., by hiding the concrete web address, or using an interface contract).
• Independent changes of internal data structures (containing data sent to clients): Pro-vides flexibility to react to changes of the internal logic without affecting clients.
• Integration of services with different interfaces: Combining multiple services that have a similar purpose, but provide data in different formats or via different inter-faces.
• Notification of messages / results: Allows asynchronous execution and therefore avoids blocking of the application.
• Communication between components (unknown to each other): Influences the loose coupling of the services by avoiding the use of hardcoded addresses (for example, hypermedia in REST, or keeping URLs in a central location).
• Flexibility to react on changing remote communication addresses: External services can move to other servers with other IP addresses. These should be exchangeable without having to change source code or redeploy the application.
• Support of and mapping to different web service types (e.g., from REST to SOAP):
Freedom in choosing without having to reimplement certain logic.
• Support of and mapping to different data formats (e.g., from XML to JSON): Services can provide data in different formats. Automatic conversion is helpful.
• Usage in different architecture layers: the usage of external services should not be logically limited to a specific architecture layer. This increases the flexibility to use external services, which is a benefit for prototyping.
• Prototyping: Possibility to quickly test communication with external services (useful, when solving security issues, for example).
• Asynchronous communication: Important feature (together with the automatic noti-fication of messages / results), to avoid blocking in the application.
Patterns
Most of the following patterns were originally defined by Fowler [43]. Trowbridge et al.
[127] have collected and extended them. Relevant patterns are:
• Data Transfer Object (DTO) (Fowler [43]) is used for exchanging data in a well-defined structure.
• Message Bus (Hohpe and Woolf [55], Trowbridge et al. [127]) allows keeping the communication with external systems exchangeable by hiding the concrete address.
• Message Channel, Message Router, Message Bridge, Point-to-Point Channel and Datatype Channel (Hohpe and Woolf [55]) are further specializations, or modifica-tions of the Message Bus pattern.
• Portal Integration, Entity Aggregation and Process Integration (Trowbridge et al.
[127]) describe the different possible places where integration can be done.
• Shared Database, Maintain Data Copies and File Transfer (Trowbridge et al. [127]) are possible ways to exchange data with external systems.
• Distributed Object Integration, Message Oriented Middleware (MOM) Integration, Service-Oriented Integration and Presentation Integration (Trowbridge et al. [127]) describe patterns for combining applications. The first three patterns allow to "inte-grate applications at the logical business layer", whereas Presentation Integration also allows the combination of applications that were not intended to work together.
• Publish-Subscribe (Buschmann et al. [22], Trowbridge et al. [127]) is a communica-tion pattern that is also suitable for asynchronous integracommunica-tion.
Internal Services / Components
Also, internal components have to be integrated to allow them to work together. Whereas external systems communicate via a remote communication technology, internal compo-nents run in the same process (or thread), and dependencies are defined in a way prede-fined by the programming language.
Requirements
Internal integration is done within an application, in the same programming language (or a compatible one, keyword "polyglot programming"). For example, a class depending on another class. Therefore, this deals with the dependencies of services in the program itself.
Also here the principles of maintainable software should be followed.
• Integration of components not designed for enterprise applications (e.g., inference algorithms): Reuse of existing libraries to avoid costly re-implementation of complex algorithms (also the integration of object-oriented implementations into non-object-oriented ones and vice versa (e.g., C, or Prolog)).
• Loose coupling of components: Ensures extensibility and exchangeability.
• Extensibility of components: Due to changing requirements in projects, also the source code changes. Therefore, single components of a software system should be easily ex-tensible.
• Runtime reconfiguration: Avoid costly restarts of the application by allowing to re-configure the system at runtime (e.g., execution time of periodic jobs, or algorithm parameter settings).
Loose coupling Chang
esofinter nalDS
Different interf
aces
Messag
e notification Data
Processing Communication
with "unkno wn"
Flexibility forchang
es
Diff.
remo
tetechnologies Diff.
formats Diff.
architecture layers
Prototyping Async.
communication
DTO X X X
Message Bus X X X X X
Message Channel X X X X
Message Router X X X X
Message Bridge X X X X X X
Point-to-Point Channel X
Datatype Channel X X X
Portal Integration X X
Entity Aggregation X X X X X X
Process Integration X X X X
Shared Database X X X
Maintain Data Copies X X X X
File Transfer X X X X X
DO Integration X X X X X
MOM Integration X X X X X X
SO Integration X X X X X
Presentation Integration X X X X
Publish-Subscribe X X X
Table 4.2: Mapping of design patterns to requirements for external integration.
• Communication between components (unknown to each other): This requirement supports the loose coupling of components by avoiding a direct dependency on other components.
• Asynchronous communication: Avoid blocking of the application.
• Sharing of data to be processed: Data should be easily transportable to other services.
Patterns
• Blackboard (Buschmann et al. [22]) enforces communication of different services. It, therefore, provides an "open" storage space that can be used for sharing data, results, etc.
• Whiteboard (Kriens and Hargrave [70]) is a variant of the Observer pattern (Gamma et al. [46]). The process of manually registering an Observer falls away.
• Shared Repository (Lalanda [73]) allows sharing different data structures.
• Service Locator (Alur et al. [5]) provides a possibility to reduce coupling of compo-nents.
• Dependency Injection (Fowler [44]) can be compared with the Service Locator, but without the need for an active lookup of the components.
• Listener / Observer (Gamma et al. [46]) allows registering for notifications on an event. This pattern reduces the tight coupling of components. A variant of this pattern is Publish - Subscribe (see Buschmann et al. [22]).
• Pipes and Filters (Buschmann et al. [22]) describes how to integrate systems operat-ing on a data stream.
The main selection criteria for these patterns are anabstractionfrom the concrete component and the ability tointegratedifferent kinds of components. Also,loose couplingof components by abstracting from their concrete implementation must be enforced. The mapping of the patterns to the identified requirements is presented in table 4.3.