The absence of guidelines and discussions on this topic puzzles me. As I’ve asked myself this question many times, without coming up with a one-size-fits-all solution. Is it a “Process”, a “System” or perhaps a “Unit of deployment”?
The BizTalk Documentation doesn’t shine much light on the subject:
“The BizTalk application is a feature of BizTalk Server that makes it quicker and easier to deploy, manage, and troubleshoot BizTalk Server business solutions. A BizTalk application is a logical grouping of the items, called "artifacts," used in a BizTalk Server business solution”
All that is of course true, but what does a BizTalk Application resemble? It often comes down to if you think of your BizTalk investment as a Service Bus or an Integration Platform. In relation to my own experience, I’ve tried to list pros and cons, using the BizTalk Application as a “Process”, a “System” or a “Unit of Deployment”.
if (BizTalk.Application == “Process”)
You could very well use the notion of a BizTalk Application as a Process such as “Order Processing” or “Payroll Processing”, deploying all the artifacts, related to that process, to the appropriate BizTalk Application. This works best if the Processes are well defined in the organization, and not made up as you go along developing your BizTalk solutions. I sometimes find it difficult to scope a “Process”, as Processes tend to overlap each other.It can therefore be a good idea to limit the number of Applications to reflect only the main processes (<~20), as you might otherwise run into trouble with lots of references between your Processes and reusable sub-processes.
figure1. Both the send and the receive port are implemented in the “Order Process” Application.
As working with Processes might work fine from a developing perspective, if can turn out to be a nightmare from a maintenance point of view. If one or more systems has to shut down for maintenance, how would you know what ports to stop or disable? You could solve this reflecting the name of the system in the port name, E.g. Rcv_SAP_OrderConfirmation or Snd_Navision_SalesStatistics. But you’d have to use Applications.<All Artefacts> to find the ports, which can be painful having 100+ ports.
If you are using BizTalk as an ESB, it’s difficult to fit On- and Off-ramps to anything but processes, as it would otherwise prohibit reuse of those services. For example, say you have a receive port providing contact information to anyone who cares to call it. The service in it self would in this case be a composite service (orchestration), made up of several calls to CRM and HR systems in order to return all contact related information about a person. Deploying that port a “Process Application”, would promote it to be a reusable port for anyone to consume, given, of course, that they are privileged.
else if (BizTalk.Application == “System”)
Grouping your ports and orchestrations by Systems, might come natural as services most often “belong” to a System. If your organization has identified “System owners”, it’d easy to find the responsible person for a particular end point.
figure 2. Ports are implemented in different applications, resembling the systems from where the message is received and sent to.
The flip-side, of course, is the lack of Process orientation. As the business side of the organization tends to talk in terms of Processes, you might find it challenging to find the relation between services and business processes. However, these processes are often implemented as orchestrations which makes things much easier.
In relation to the ESB context as mentioned above, – Reusable services are difficult to govern! If your organization finance the BizTalk platform based on how it’s utilized by its consumers, how would you know how many times the service has been called by each consumer? If you think of a BizTalk Application as a System you’d reuse on the level of orchestrations. Each new consumer would need its own service, which could have its own SLA.
The only problem is that, having orchestrations with port bindings across Application boundaries causes circular references. This is because, in order to bind a port to an orchestration, the port has to belong to the same application or a referenced one. I still struggle to understand the purpose of the “Application reference”, but it will eventually put you in a situation where you can’t bind the port because it belongs to an Application that is already referencing the Application your orchestration belongs to. You could of course get around this by using “Direct bound” ports in your orchestration, which often is a general recommendation.
else if (BizTalk.Application == “Unit of Deployment”)
Using the BizTalk Application as a “Unit of Deployment” means you’d group all your projects that can be deployed and undeployed together, into a single solution and deploy the whole package to a “Solution Application”. The downside in this case would be reusability, since you have to make sure there are no project or binary references to projects that is not part of the solution. – If there are, undeployment will get messy!
This is similar to “Application == Process” in all but the size of the “Process”. In my opinion, this works best for smaller BizTalk implementations, as this could otherwise cause any number of Applications.
In all fairness, you can create isolated, deployable solutions for both the “Process” and “System” approaches as described above. It would require more work and structure. But it can be done, as I’ve described in this article.
else if (BizTalk.Application == “BizTalk Application 1”) // ONE Application rules them all!
I don’t like this at all, but it does comes with some advantages as; no issues with Application references, easy deployment and of course the fact that you could disregard everything said above. But the lack of structure, not to mention size of the beloved combo boxes to select schemas and mapping from, would cause me to advise against this approach
else // let’s be pragmatic…
As developers are often found in the crossfire between the business and the maintenance, we are forced to take sides. But perhaps we could make a compromise. We could go with the “Application == System” approach, for all our proprietary ports and send ports, exposing system specific schemas. –But deploy our orchestrations and ports with canonical contracts to “Process Applications”. To solve the issue of governance, we could use Party resolution to monitor the usage of these “generic” services.
This would work from an deployment perspective as well, as we wouldn’t have to worry about Application references since “Process Applications” would never have to reference other “Process Applications”.
figure 3. All send ports and receive ports exposing proprietary schemas and protocols are deployed to “System Application” whereas public reusable receive ports are deployed as part of a “Process Application”.
BTW, I know I should have used a switch statement…