In part 1, I described my experience using Software Factories, including DSLs, to predictably and repeatedly solve application integration problems.  Our Software Factory framework pattern evolved over the course of 4 years and 25 application integration projects.  Essentially we developed a product that encapsulated our framework pattern that could solve any application integration problem with minimal coding.  This was done by analyzing what is common and what is variable to every application integration scenario and designing a framework model to cover these scenarios.  My intent here is to cover each aspect of the model and discuss how and why we arrived at our overall application integration framework pattern.

 

Referring to our framework object model, the top most container is the Model object in which it contains all of the objects that make up one or more application integration scenarios.  Essentially it is an abstract (root) container, which translates to the top-level drawing canvas in our (DSL) visual designer modeling tool.

 

The first common modeling construct is that all application integrations occur within a Business entity or between Business entities.  A Business entity is an abstract object that can represent an individual company, a division of a company, a remote office, an enterprise or small group within an organization.  A Business entity may also contain other Business entities.

 

It seems obvious or even taken for granted that a Business entity models a real world construct (i.e. a real business).  However, in my experience this construct is typically either overlooked or viewed as trivial.  The reality is that application integrations do not occur in thin air, they are tied to real businesses, thus part of the problem domain we are interested in modeling.  Having this construct allows us to model any application integration scenario within or between any number of uniquely named Business entities.  For example, lets say we have 50 satellite offices that are geographically dispersed that use various accounting software packages that need to exchange financial data with a centralized financial package (i.e. Corporate HQ). 

 

Without the capability to model this in a visual designer would make it very difficult to design and construct this application integration scenario, let alone actually visualize semantically what is actually going on. While we are talking about the business entities and the logical connections between the business entities, we are also describing the many properties of each unique business entity and its relationships to each other.  This translates into unique name spaces required to define the paths between (or within) these businesses in the models XML definition output.  In other words, we have declaratively captured all of the information required for each business and to navigate from one business entity to the next.

 

Looking at the framework design pattern at the next level, we can see that each business entity has one or more Business Flows.  A Business Flow is an abstract object contained in a collection whose parent is a Business entity. The Business Flow represents a particular Business Process which may be a simple A2A integration, or may be a complex workflow process.  For example, if one of our satellite offices (i.e. business entity) had three financial applications that exchanged data between each to form an aggregation, before it sent its aggregation to the centralized financial package, then we need the capability to model this. 

 

You can see an example of what this visually looks like in this layered view of our visual designer model at the canvas layer called Business Flow.  You can see how this visual representation conforms to our framework design pattern.  You can also see how this visual representation can scale to represent any number of Business Entities and the collections of Business Flows for each Business Entity.  While this occurs in the real world, few application integration vendors toolsets have the capability to capture this critical information.

 

In part 3, we will continue walking through our application integration framework pattern.