Browse Prior Art Database

Message flow optimization

IP.com Disclosure Number: IPCOM000010984D
Original Publication Date: 2003-Feb-06
Included in the Prior Art Database: 2003-Feb-06
Document File: 4 page(s) / 72K

Publishing Venue

IBM

Abstract

Enterprise application integration programs build message flow processes that consist of logically interconnected, specialized processing nodes. For usability, it is desirable to have many nodes that perform discrete, easy to maintain functions. For performance, it is desirable to have a single node that performs all the required functions. Disclosed is a technique to optimise message flows by aggregating multiple nodes into a single runtime node.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 4

Message flow optimization

Enterprise application integration programs build message flow processes that consist of logically interconnected, specialized processing nodes.

    From a usability and maintainability point of view, users prefer to build message flows with small, discrete nodes. A common problem is that such easy to develop and maintain message flows do not perform well at run time. This is because performance is much better if the message flow consists of as few nodes as possible.

    To solve this problem, users manually merge nodes to optimize performance at runtime.

    Disclosed is a technique to optimise message flows by aggregating multiple nodes into a single runtime node. The merging of nodes occurs by a mechanical process that software can perform at deploy time.

    This new function optimizes message flows at deploy time, by aggregating adjacent message flow nodes into a single runtime node. In the ideal case, the optimization produces a message flow at execution time that would effectively consist of one Input node, ONE process node and one or more Output nodes.

This optimization function gives three benefits:

Performance. It is generally acknowledged that there is a cost associated with

passing through each of the nodes in a flow, so in performance terms, it is best to write a message flow in as few nodes as possible.

Developer productivity. When users design flows for performance, rather than

readability, the result is large processing nodes that are difficult to debug and maintain. With the knowledge that the optimizing function will take care of performance, users can break down large compute nodes into sequences of small, easy to maintain nodes, without paying the penalty of reduced performance. This is especially useful when using the debugger.

Code reuse: small, specialized nodes are easy to reuse in other message flows....