In part 3, I described our application integration framework pattern at the level of BusinessFlows.  A BusinessFlow contains 2 or more Applications and 1 or more Connections.  I described how the framework pattern works with Applications and in this post we discuss Connections between Applications.

 

A Connection represents a logical connection to each Application, and physically to each Applications Adapter.  A Connection contains 1 or more DataFlows.  A DataFlow is a collection object that contains other objects, which we will describe in a minute, but its construct allows us to contain one to many DataFlow rows.  Each DataFlow row specifies the direction in which the communication of messages (i.e. data) flow.  It also specifies which Application in the integration scenario has initiated the event in the communication, either in real-time or on a scheduled (i.e. batch) basis. 

 

For example, if I have MS Great Plains on one end of the connection and the Corporate HQ Financial Application on the other end of the connection, I can specify that MS Great Plains will be the initiator of the business event and the messages (i.e. financial data) will flow from MS Great Plains to the HQ Financial Application.  Further, I can specify the DataFlow row type of communication.  For example, one-way asynchronous, one-way asynchronous, two-way request response synchronous, and two-way request w