As we said in a previous post, the connector algebra introduces a set of 'primitives' that models basic mismatch situation. These primitives are related to the mediator pattern introduced by the Go4. We have six basic primitives (explaination extracted from Towards Connector Algebra Paper):
- Extra send. This first mismatch considers a component that generates a redundant message a. Such a mismatch may be resolved by introducing a consumer that swallows the superfluous message. We model this by a parameterised primitive Cons(a).
- Missing send. This mismatch describes the case in which a component expects a message a that is not sent by another component. A mismatch of this type may be resolved by introducing a producer that generates the required message. This may be modelled by a parameterised primitive Prod(a).
- Signature mismatch. There are occasions when a message to be exchanged between two components is functionally compatible yet syntactically inconsistent. In the case of Connect, the functional equivalence of the messages a and b is assumed to be specified in an ontology. Such a mismatch may be resolved by means of a translating primitive T rans(a, b) that accepts message a as input and produces message b as output.
- Split message mismatch. A component may expect to receive a message a as a sequence of fragments of a. If message a can be decomposed into a1 , . . . , an , then the mismatch may be resolved with a primitive Split(a, [a1 , . . . , an ]) which accepts message a as input and offers a1 , . . . , an as output in that order.
- Merge message mismatch. Similar to the previous case, some components expect to receive a single message a in place of a fragmented version of a. If messages a1 , . . . , an can be composed into a, then the mismatch may be resolved with a primitive M erge([a1 , . . . , an ], a) which accepts messages a1 , . . . , an as input in that order, and generates a as output.
- Ordering mismatch. A component can expect to receive messages in an order different from the order used by the sending component. The mismatch can be resolved by introducing an ordering primitive Order([a1 , . . . , an ], π, [a1 , . . . , an ]), where π is a permutation of {1, . . . , n}.The primitive accepts inputs from one component in the order a1 , . . . , an , and produces outputs for the other in the order aπ(1) , . . . , aπ(n) .
The implementation of these concepts is slightly different. For example, the Trans class of the CABAC library implements signature mismatch primitive.This mismatch is semantically identical to message translator pattern included in EIP. Apache Camel supports the Message Translator (http://camel.apache.org/message-translator.html) from the EIP patterns by using an arbitrary Processor in the routing logic: in our case, we simply use the DSL (transform() method) into route definition. When you want to define a translator, you must includes the endpoints (through) and type interested in the communication. Later we see how create a simple mediator ;)
