Parts 1 through 5 discussed the details of our application integration framework design pattern.  A Business Analyst (BA) uses our DSL Visual Designer (as a RIA) that has our framework design pattern implemented to declaratively model specific application integration scenarios.  There is one optional point in the declaration where a small amount of custom code may be required and that is if a custom application adapter is required.  Other than that option, any application integration scenario, regardless of size or complexity can be 100% declaratively modeled using our DSL Visual Designer.

 

This goes directly to the point of why model driven development using the Software Factory approach works which in my opinion, represents the state of the art in software engineering today.  My intent in writing Parts 1 through 5 was to walk through how our application integration framework pattern can be used to model any application integration scenario.  The output of our DSL modeling tool is an XML definition that declaratively defines a specific application integration solution as defined by a BA and validated by our Software Factory schema (i.e. our framework model that we just walked through in parts 1 through 5).

 

Next I will discuss our Software Factory in detail and how it works based on a particular application integration definition.  Have a look at this logical view of our Software Factory.  It contains 3 subsystems, they are: the DSL Visual Designer that we just walked through, our Software Factory, and our runtime system.

 

You already know what the DSL Designer does.  The Software Factory takes the DSL Designer XML tools output and configures our Software Factory template.  This means that all of the properties that were set by a BA in the DSL Designer are interpreted by our Visual Studio script and populates a Visual Studio solution with pre-built code artifacts, including source and destination XSD schemas, adapters, business rules, XSL maps, any custom assemblies uploaded by the customer, source and destination namespaces, BizTalk orchestrations, and our pre-built runtime applications are added to the solution.

 

Once the Visual Studio solution and projects have been populated with the specific XML configuration information, a deployment project is added to the solution and the solution is built and packaged as a .msi, ready for deployment.  The Customer is then notified that the package is ready to be downloaded, the Customer downloads the packaged solution and runs it on the target server. During installation, we ask the Customer for credentials for the solution to run along with the source and destination addresses of where the applications to be integrated exist on the network. In our .msi, we check for the existence of BizTalk Server, SQL Server, IIS, etc., to ensure all of the services are installed and running correctly.

 

Configuring and extending Visual Studio is a relatively simple process as the Visual Studio extensibility model is well documented and provides for easy automation.  After designing and developing 25 BizTalk integration solutions, setting the same old properties, adding pre-built orchestration schedules, schemas, etc. is easy.  Sure, some projects are more difficult than others and a little manual manipulation may be required, but generally the time it takes to configure and build an application integration solution using the Software Factory approach is a matter of days instead of months, and thats the point of this series of posts.

 

Parts 1 through 6 have been captured in a Live Meeting demonstration that can be viewed online.

 

Next post we wrap up our discussion on the evolution of software industrialization.