In part 2, I started describing our framework design pattern for defining application integration scenarios.  At the top level is our Model object that contains one or more Business Entities.  Each Business Entity can also contain one of more Business Entities to represent any hierarchical business entity structure that occurs in the real world.  Each Business Entity contains one or more BusinessFlows.  A BusinessFlow represents Business Processes which can be a simple A2A integration or a complex workflow process.  With respect to our DSL Visual Designer, each object in the model includes a wizard and/or property sheet for the Business Analyst (BA) to enter values that describe the object being configured.

 

Looking at the next level in the object model we can see that a BusinessFlow contains 2 or more Applications and 1 or more Connections.  An Application object represents a real-world computer application.  We have a number of Application objects pre-built (see Application Types in the model) allowing the BA to select from a list. If the Application required by the BA is not in the list, then a custom Application is entered which will require custom code to describe its interface (i.e. Adapter).  Each Application has an Adapter.  An Adapter is a plug-in connector where one end of the connector knows how to natively communicate with the Applications API and the other end exposes an interface that has been transformed into XML messages (including XSDs) that the Application can exchange with other Applications.
 
In our continuing example of financial applications exchanging data, the Application may be MS Great Plains which comes with a COTS adapter (i.e. connector) that performs this transformation in communicating with Great Plains native API and exposes an XML messaging interface.  Since we are using BizTalk as the underlying me