Pattern for Designing Binding-Agnostic Processing Elements (29-Sep-2009)

Pattern for Designing Binding-Agnostic Processing Elements

In many messaging and business integration development tools, the steps for processing input through the described system are depicted using graphical elements. Each step or a collection of steps are represented with visual indicators and connected with a graph. For the purpose of this article, we will call these visual indicators as nodes. Typically these nodes encapsulate information associated with it that describes how the node should process the input, and

p

 otentially the output. Additionally, some of these nodes serve as boundary interfaces with external systems.

Typically, the nodes that serve as interfaces with external systems require some sort of binding information. This binding information describes, at minimum, where and how the described system will communicate with external system(s). Without this knowledge the nodes would not be able to function. There are many types of bindings, each with their benefits and tradeoffs. Usually, a messaging or business integration development tool will support multiple types of binding. Similarly, an implementation may choose or change different types of bindings depending on their circumstances and need.

There exist structures, such as Web Service Definition (WSDL) files and SCA Component Description (SCDL) files which embed binding information within their schema. These files can then be used by the node to configure the binding information. In some scenarios, it is necessary for the end user to know and understand the binding information; however, in many cases,

p

 articularly for novice users and when binding information for the external system has been defined externally, knowledge of binding information is not required. In fact, the presence of binding information is detrimental to the consumability of the development tools since:

- The novice user may be overwhelmed by the technical jargon describing the binding
- The technical jargon may give the novice user the impression that the tool is complex
- The novice user expects a large learning curve before they can understand the usage of the node.

These drawbacks are counterproductive to a goal of making development tools more accessible for business users.

This leads to a problem particularly when the external service is re-engineered and the binding type has changed. For example, originally the external service may have defined a binding using SOAP over HTTP. However, SOAP over HTTP does not have transaction support which was found to be required. The binding was then changed to MQ which indeed contains transaction support. Suppose the novice user was able to configure their original message flow or business integration process using pre-built wizards, but has since done a substantial amount of work. One solution to update the binding would be to star...