In this opportunity I want to share with you a tool that we are developing in order to improve the software development process on BizTalk Server. First I want to let you think about some topics  that are very often when you develop EAI applications using BizTalk Server . To put in context the problem that we are facing  I'll ask you some questions::

  1. How do you design your System?
    1. Do you have any high level of abstraction modeling tool where you can specify you system requirements and the relationships between the systems that you want to integrate ?
    2. How do you model the relationship between orchestrations, pipelines, maps, schemas?
    3. Do you have any modeling tool in order to have a simple and complete view of your system?
  2. How do you instrument your system?
    1. Do you have any way to specify the functional and nonfunctional requirements?
    2. Do you use any instrumentation API? Is generated automatically?
    3. Do you provide system’s health pack for your system like SCOM management pack?
    4. How you verify that your system is well instrumented?
  3. How do you deploy your system?
    1. Have you any tool to deploy your system?
    2. Do you make the deployment scripts by hand?
    3. This tool or self-made scripts (if you have any) verify the host system requirements before install any application’s component?
    4. How you ensure that the artifacts of your system are well configured in the host server?
  4. How do you ensure your system quality ?
    1. Do you use any static code checker?
    2. Do you use any static model checker?
    3. How do you ensure a acceptable testing code coverage?
    4. How do you ensure that the developers are using the best practices?
  5. Do you use any ALM system to manage your process?
    1. How you track all pending tasks?
    2. This tasks are associated with your system components (code, orchestrations)? how do you do that?
    3. Are you be able to make impact analysis for specific artifacts?
    4. How do you know the progress of specific system component and match that with the original requirements?

And the last question,but not less important is:  How many time do you spend making tasks that are not related with your business logic?

In response to all of this questions we are  developing a tool based on DSM in order to specify all system requirements and relationships between components in a top-down system design approach. In this approach the abstract models give rise to more concrete models until  reach the most essential artifacts of the system, like: code, scripts, configuration files, management packs, and so on. By the other hand also the model checking rules are generated, in order to verify your system each time that you build it or deploy it.

Let’s see how we do that:

First at all you have to specify your system at a high level of abstraction where you can use a set of predesigned components that appear in the Visual Studio toolbox as the following picture shows.

 image Fig 1) System Model View

The most important component in the tool box is the Process, that represent an abstract functional unit that will give rise  low level models that will be defined later by the software architect. In the process component you can specify functional events and measures,  depending of the business requirements to be implemented . A process can be connected with other process, with Integration Components (IC) and the last one with Application Servers (AS) (we will talk later about the IC and AS) in order to have a high level of abstraction model.

The following picture  shows the process representation.

image Fig 2) Process, Events and Measures model representation

Events are notifications that the process will throw at run time and can be of different severities  “Warning”, “Information”, “Error”. The event are alerts or notifications  about a system condition and can be used by the system monitoring tool to execute some actions depending on  the event itself.

image Fig 3) Event properties

Measures are based on OS performance counters and can be used to store certain values related with technical or business functionality during a period of time, EJ: items processed per second, item count, and so on. Measures and Events defined on the model will be used by the artifacts generators to generate a portion of the system management pack.

image Fig 4) Measures properties

The other elements of your tool box with a high relevance to the model are the Integration Components (IC) ,as I mention before.The IC represent the communication type that the process will use to interact with other systems. These can be connected with the Application Server's components in order to define where the services provider will be hosted. For example a Web Service will be hosted by a Windows Server host or a File will be stored in a Unix system. Here are a partial  list of Integration Components that you can use to model your system: File, HTTP, Web Service, Data Base, FTP, POP3 , SMTP, Message Queue, SWIFT, and more.

The following picture shows a complete system model in order  to give you an idea about how to design your system in a high level of abstraction.

image Fig 5 )  High level system design

 

In the next post I’ll continue describing the functionality of the low level models to give you a picture on how our tool works and  show you the main features that response all questions made at the beginning in this blog.