Understanding the layers of a BizTalk solution
Continuing our train of thought about partitioning a BizTalk solution, we now arrive at a very familiar topic in system architecture: logical structure. From a logical standpoint, a properly constructed BizTalk solution, like any good software solution, stresses the separation of concerns in an effort to control dependencies. This throws off a lot of people new to BizTalk because it involves concepts from both the object-oriented and message-oriented theories of software development.
The following proximity diagram depicts how the layers in a BizTalk solution should interact. Only layers that actually touch each other should be interacting in any way. The intention from this should be quite clear; it is to isolate the layers in the solution and minimize their interaction points so as to create a more robust solution that does not allow changes to propagate throughout the core.
This layout will give us the ability to drastically change the solution, at its edges or in its core, without impacting other parts of the solution. A new external partner schema, say for a different vendor purchase order format, should have no impact on our orchestration layer or on our internal schemas. Conversely, a change to logic within an orchestration should be completely invisible to the outside world.
This same concept can also be expressed in a more detailed fashion with a UML diagram. The following diagram expresses the basic layers (or packages to use the classic term) in a BizTalk solution that follows these guidelines. This also allows us to further restrict the dependencies with relationships between layers expressed explicitly.
Again the goal is flexibility by tightly controlling contact points between different parts of a solution. Visual Studio can be leveraged to help enforce this architecture in your solution. Importantly, each of these packages actually represents a .NET assembly containing pertinent artifacts to that layer of the solution. For the rest of this chapter, package, assembly, and project will be used interchangeably.
Recall that at its core a BizTalk solution is really a specialized .NET application. Since these are .NET assemblies we are able to leverage the concept of references in the .NET framework and Visual Studio to enforce our layering pattern. This is done by creating separate projects in the solution for each of the layers presented previously.
If you're not already comfortable with the layers pattern, or you're already a little familiar with BizTalk solutions, you may be asking yourself 'So why do this?' Some would argue that you could just do a logical separation using solution folders and not need separate Visual Studio projects for each of the packages shown previously. While there certainly is some merit to this argument, it overlooks some very important capabilities inherent in this architecture.
For one, there is no chance of a dependency creeping throughout your solution, the Visual Studio references between projects will ensure that. Further, you can also now choose to deploy your solution in a variety of arrangements of tiers* derived from the layers presented above. Finally, and perhaps most importantly, this design allows you a much larger amount of flexibility when deploying, upgrading, and especially patching BizTalk solutions. Maps, for example, can have many mapping errors resolved and redeployed without requiring downtime in a highly available BizTalk group.
Tip
Tiers versus layers
I know it is subtle and often contested, but I believe tiers and layers to be two distinct concepts in application architecture. Layers exist in software at the design and development level, they represent abstractions and separations in that software whereas tiers exist on the deployment and operations level representing physical distribution of components. Although layers may be deployed on tiers that very closely resemble the same structure, there is no fundamental requirement to do so.
It is important to also note that not all solutions will follow this exact structure. A common variation I encounter is using pipelines from within orchestrations. If you must do this, be sure the pipeline uses internal messages and not external ones. You may end up needing both internal and external pipeline projects and that is perfectly acceptable, but they should be separate projects because they will reference separate schemas and this division is important to protect your architecture.