|< Day Day Up >|| |
In this section we introduce basic concepts and notations for capturing different types of interactions encountered in Process Integration.
Integration between people, process, and applications can be thought of as collaboration and interaction between participating entities.
In the most general sense, a collaboration denotes N-to-N activities between sub-systems within a distributed system. As shown in Figure 2-3, complex collaborations between sub-systems can be broken down into more basic interactions. An interaction focuses on 1-to-1 or 1-to-N activities originating from a single sub-system.
Figure 2-3: Collaboration topologies
In this way, complex collaborations involving many sub-systems can be decomposed into simpler interactions that are easier to analyze. Data analysts use a similar approach when analyzing complex data with many-to-many relationships. Normalization is used to reduce many-to-many relationships between data to 1-to-many relationships.
Note that we do not show a link from A-to-C on the right of Figure 2-3. This is because, in breaking the interaction down, we found that A only initiates interactions with B, D, and E. The C-to-A interaction will be modeled in another 1-to-N interaction.
As we just saw, an interaction is a collaboration originating from a single component. Figure 2-4 shows an interaction between a source application and a target application. The initiating operation is indicated by a small solid circle.
Figure 2-4: Definition of interaction
Complex interactions may be decomposed into several simpler interactions to enhance the level of detail. An example is shown in the Figure 2-5, where a query for a quote is decomposed in a request step, an acknowledgement step, and a final reply step.
Figure 2-5: Decomposition of complex interactions
An ellipse spanning one or more basic interactions denotes a shared context involved in a complex interaction between two or more sub-systems. Examples of shared contexts are session, security, transaction, process control, and so forth.
Complex interactions with multiple target applications also can be decomposed into multiple 1-to-1 interactions, as long as there is one initiating operation within a source application. The interaction patterns approach can then be applied to these 1-to-1 interactions.
The terms connector and adapter are often used interchangeably. This section defines their use in a Patterns for e-business context.
Connectors provide the connectivity between source and target applications. A connector is always present to facilitate interaction between two sub-systems.
Depending on the required level of detail, a connector can be:
A primitive (or unmodelled) connector, represented by a simple line between sub-systems
A component (or modelled) connector, represented by a rectangle on a line between sub-systems
For lower-level modelling, a primitive connector can always be decomposed into a modelled connector and two adjacent primitive connectors, as shown in Figure 2-6. This way, connector models can be recursively decomposed until the correct level of detail is reached.
Figure 2-6: Decomposition of connectors
It is useful to distinguish two connector subtypes, as shown in Figure 2-7:
An adapter connector is concerned with enabling logical connectivity by bridging the gap between the context schema and protocols used by the Source application (S type) and Target application (T type).
A path connector is concerned with providing physical connectivity between Source and Target applications. It may be very complex (for example, the Internet) or very simple (an area of shared storage).
Figure 2-7: Relationship between connectors and adapters
These connector subtypes are orthogonal, meaning a connector may be both an adapter connector and a path connector. The relationship between connectors and adapters is shown in Figure 2-7.
Adapters provide the logical connectivity to an application. Without adapters, each application would need to implement the specific interface of the target application.
It is useful to distinguish three types of adapters:
Control adapters are not concerned with content. They are only concerned with the activities involved in flow operations:
Transforming the protocol used between the segments
Segmenting, batching, and sorting data blocks
Correctly interacting with the path connector to execute the transport operation (This includes respecting the protocol rules.)
View adapters are concerned with transforming content but only in terms of its technical representation. Examples include:
Element demarcation schemes, such as delimited, fixed-length, and XML
Element sequencing schemes, such as keys and collation sequences
Element encoding schemes, such as character set, number format, and date format
Model adapters transform the semantic content and normally require business input to define correct operational rules. Some examples are:
Splitting out subsets of data
Joining external data (augmentation/enrichment)
Translation of identifiers (key management)
Coupling adapter connectors can be used to implement a common integration protocol such as messaging, RMI/IIOP, SOAP/HTTP, and so on. As shown in Figure 2-8, the adapter functionality between the source application and the target application is decomposed into two halves. Each half adapts to and from a common intermediate protocol.
Figure 2-8: Coupling adapters
If there are multiple point-to-point connections between a group of sub-systems, this approach can significantly reduce the number of different adapters required. Each sub-system only needs one adapter (instead of needing a different adapter to connect to each sub-system).
In order to describe the time dependencies between the initiating operation and the resulting collaborative activities, two cases may be distinguished:
The initiating operation cannot complete until the interaction has been completed. In this case, the source application is synchronously coupled with the target application.
The initiating operation can complete before the interaction completes. The operation is then regarded as asynchronous, and the source application is synchronously decoupled from the target application.
The interactions involved in Process Integration can be broadly classified as parallel and/or serial.
An interaction is denoted as parallel if it includes a set of concurrent 1-to-1 interactions between a source application and multiple target applications, as shown in Figure 2-9.
Figure 2-9: Parallel interaction
An interaction is denoted as serial if it includes a series of 1-to-1 interactions between a source application and multiple target applications that are subject to time sequenced dependencies, as shown in Figure 2-10.
Figure 2-10: Serial interaction
Distributing parallel and serial interactions along two dimensions of a matrix provides the four combinations shown in Figure 2-11.
Figure 2-11: Classification of interactions
This classification framework is used later in this chapter to classify Application patterns for both Application Integration patterns (intra-enterprise) and Extended Enterprise business patterns (inter-enterprise).
|< Day Day Up >|| |