I had a discussion with a friend the other day and thought it was worth sharing some thoughts for discussion on this. Ok so the question is:
What type of BizTalk application are you building?
Based on my experiences of seeing BizTalk implementations around the world I am pretty sure a lot of people will now be thinking “huh what do you mean I’m building a BizTalk one”.
This is exactly the point I was making to my friend. It is very common that I see two types of BizTalk application structure:
- The one application to rule them all model
- The one size fits all model
Ok so lets dissect this. The one application to rule them all model is the one I hate passionately. This is where you have one code base and Visual Studio solution and it has a mountain of different BizTalk stuff in it doing all kinds of different integration processes. Sometimes this is in the flavour where it gets packaged up and installed to BizTalk just in one BizTalk application/msi and another flavour is that you end up with multiple msi’s that get installed as a number of different BizTalk applications but they all came from the same code base and are all tightly interwoven and coupled together.
The one size fits all model is basically a code base and application that is used for all integration scenarios no matter what. This is far less or an issue than the above model but it can lead developers to see every integration problem in the same way and try to shoe horn them into the one size fits all approach.
I believe there are the following types of BizTalk application that you might build:
- An EAI style application
- A Business Process Automation style application
- A point to point style application
- An ESB style application
- Integration Service Application
The point here is that the implementation of different types of integration pattern requires slightly different approaches and if we separate them into their own self contained code bases and applications we create a natural decoupling which will make our lives a lot easier when it comes to the implementation and on going maintenance phases of our projects.
Lets take a look at these types of application in more detail.
BizTalk EAI Application
A BizTalk EAI application is has the focus of containing resources to help you integrate with 1 application. It should handle the conversion between canonical message formats and that end application. The EAI application is potentially taking messages from the “bus” and doing the things that need to be done to get data in and out of the application that it works with. I guess you could also consider this type of application to be something like an ESB Adapter for that end application which converts the message bus pull to a push integration pattern.
Business Process Automation Style Application
This application is usually a container for a bunch of integration logic and connectivity to deal with a specific business process. An example might be that you have an application containing all of the schemas, maps, orchestrations and ports required to implement the retrieval and loading of claims into the claims processing application. These applications are typically the more complex ones but everything about this process is in one place.
Point to Point Style Application
A point to point style application is often frowned up on because “we dont like point to point integration” but the reality is there are many integration scenarios where your supporting legacy processes where this is just the most effective way to integrate two systems to support the requirement. Often this type of application will involve feeds of data in a batch format too. Sometimes its handy to have a BizTalk application which can be a container for a number of batch style point to point processes just to make your implementation and management easier but its important to not intermingle the resources between these processes across your code base. Keep things together so its easy to understand what process uses what resources.
ESB Style Application
An ESB style application can be using the ESB toolkit or can be using a message bus and then providing service coordination across other services or message bus queues. In simple implementations this application may use ports to talk to applications but in larger implementations we like to keep a separation of concern between the service coordination and the application integration pieces. This is one of the use cases where flowing a message between applications can be important.
Integration Service Application
Im not 100% sure of what my preference to call this type of application is, but an example might be that I have a service exposed from BizTalk which is called and then a scatter gather process is implemented which will interact with a number of applications to fulfil getting all of the data and will then return the response. This type of application is often quite similar to the Business Process Automation style but it will usually be much simpler and focused on delivering the back end for a service rather than the automation of an entire business process.
Why all of these types?
The main reason I prefer to have these types of application is to make my BizTalk applications small simple and decoupled. If I have these three characteristics then I will often find it much easier to deliver solutions which work well and are easy to maintain and change. I like the BizTalk applications we create to have a specific and identified purpose. I dont like them to be a dumping ground for integration processes which we arent sure where to put.
If I need to allow my BizTalk applications to work together then that is fine but they should work together via the message box or via messaging going via Service Bus. This keeps the BizTalk applications decoupled and minimized references between then which means simplicity.
Why doesn’t everyone do this?
I believe the main reason this approach isnt wide spread is because its not that easy to set up new code bases for a BizTalk application. If you create a template for some of your solution types then this can work well, but if you go the extra mile and ensure your doing good build and deployment approaches with consistency then you can be in a situation where creating a new code base and build isnt a big deal but the benefit is that as an architect your team can know that a BizTalk application is expected to be used for a certain type of integration and certain patterns and it will help to create blueprints for the developers to follow.
Summary
This is some of the thinking behind the way we have implemented BizTalk applications to ensure that we are successful and consistent in our approach. I think a lot of my thinking in this space comes from my background and preferences to have small discreet components which work well together to deliver an overall solution but they are relatively interchangeable in themselves and decoupled from each other.
Id be really interested to hear what others are doing and how they identify what type of stuff should go in an application and when a new application should be created versus using an existing one.
