2.2 Process Integration concepts and notations

 < Day Day Up > 

2.2 Process Integration concepts and notations

In this section we introduce basic concepts and notations for capturing different types of interactions encountered in Process Integration.

2.2.1 Collaboration and Interaction

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.

click to expand
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.

click to expand
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.

click to expand
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.

2.2.2 Connectors and Adapters

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.

click to expand
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).

click to expand
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)

    • Summarization

    • Translation of identifiers (key management)

Coupling adapter connectors

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.

click to expand
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).

Connectors and synchronicity

In order to describe the time dependencies between the initiating operation and the resulting collaborative activities, two cases may be distinguished:

  • Synchronous interaction

    The initiating operation cannot complete until the interaction has been completed. In this case, the source application is synchronously coupled with the target application.

  • Asynchronous interaction

    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.

2.2.3 Classification of interaction between sub-systems

The interactions involved in Process Integration can be broadly classified as parallel and/or serial.

Parallel interaction

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.

click to expand
Figure 2-9: Parallel interaction

Serial 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.

click to expand
Figure 2-10: Serial interaction

Classification of Interactions

Distributing parallel and serial interactions along two dimensions of a matrix provides the four combinations shown in Figure 2-11.

click to expand
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 > 

Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net