Composite Applications

It has been a long time since my last blog post.  It certainly hasn’t been for a lack of content but it is amazing how fast time flies when you are busy.  I have been spending a lot of time lately working on composite applications and will be posting a number of entries around this topic.

One of the first questions that people ask is what is a composite app? 

Composite apps can take on many forms and use many differing technologies.  Many times people will talk about composite Apps and will only be referring to the UI tier.  While the concept of a UI composite can be compared to a mashup (a UI that combines publically available web based services to create a meaningful combination of information to a user) a UI composite is built to use business sources – in many scenarios these sources (assets) already exist within the organization from previous application development efforts. 

A composite app can also refer to just the middle tier as well.  Many companies have spend a lot of time and money over the past many years building out SOA services.  A composite app can consist of orchestration services that draw on the functionality of these different services.  One thing to keep in mind however, is that a composite app is not make a SOA architecture.  Instead they they will build on top of the work that has already been done to create a SOA architecture. 

The idea of a composite app is to build upon existing software assets to quickly bring data to consumers in new way. 

Many of the articles and blogs on this subject talk a lot around the UI tier.  While that is a very important part of a composite application, I am going to spend time over the next few posts talking about composites at the middle tier.

There is a very good all-up article titled What Are Composite Applications from Atanu Banerjee where he walks through the full composite application stack.  In this article he outlines three steps that a solution architect must do to design a composite application.  Those things are to:

• Choose a composition stack. Pick one or more containers from each tier, and a set of component types that are deployable into those containers.
• Choose components. Define the repository of assets that must be built from this set of component types, based on business needs.
• Specify the composite application. Define the ways in which those assets will be connected, to provide a particular cross-functional process. The platform should enable these connections to be loosely coupled.

Each of these things are required so that the consumer can get the most benefit.  Over and above this, the organization should start to benefit by realizing faster time-to-benefit turnaround as well as faster time-to-deployment.  These two, along with exposing existing LOB data are the three driving factors that are making the idea of composite applications so popular.

In my next several posts, I will cover some of the technical choices, how to bring bridge between services that live in BizTalk and services that live in AppFabric, and some of the lessons learned.