I really enjoyed Kent Weare’s presentation at Integrate this week which will be about some thoughts on helping companies with the decision around choosing the right technologies to make up their integration platform.  To accompany the talk there is a whitepaper which Steef-Jan Wiggers and I were asked by Kent to help him produce.

Anyway on the back of that I was thinking a little about some of the different combinations of technologies Ive seen used to implement an integration platform over the years and thought id make a note of them below.  Would be interesting to hear what other people have come across.

Example 1

The example I talked about in the Azure Hosted Integration Platform architecture used the below technologies.  In this case we had a number of different types of hybrid integration patterns being implemented and the below technologies gave us the flexibility to use the right tool for the right job.

  • BizTalk Server standard on Azure IaaS
  • Azure Service Bus
  • Azure Service Bus Relay
  • WCF Routing Service
  • WCF
  • Azure API Management
  • BizTalk 360
  • AppFx.ServiceBus messaging framework for Service bus
  • WCF Routing Service

 

Example 2

This set of technologies is something I have seen quite commonly where a customer wants to do a lot of BizTalk messaging type integration.  Using MSMQ along side BizTalk allows you to compliment the durable messaging provided by the BizTalk message box with durable messaging also available outside BizTalk which can help you to increase the decoupling in your solution.

  • BizTalk Server On Premise
  • WCF
  • MSMQ

 

Example 3

This is one of the most typical scenarios I have seen, this covers many customer requirements where you simply have traditional usage of BizTalk as the main integration host and using WCF + other BizTalk adapters.

  • BizTalk Server On Premise
  • WCF

There is occasionally an anti-pattern which comes up in scenarios where you have this pattern.  Sometimes the problem here is that you get blinkers on and try to solve every problem with BizTalk when some of the other technologies in the integration platform could be a better fit.

 

Example 4

In this case we have an integration platform developed a few years back and it was similar to that in example 1.  We have hybrid connectivity going on here and also BizTalk at the heart of the integration platform.

  • BizTalk Server On Premise
  • MSMQ
  • NService Bus
  • WCF
  • WCF Routing Service
  • Azure Service Bus Relay
  • Azure Hosted API
  • APIGee
  • Oracle Data Integrator

In this case we also had NService Bus complimenting the messaging solution to offer light weight messaging but working well alongside BizTalk in a similar way as described on the nservice bus website.

Example 5

This example was for a customer who did not have a big investment in an integration product but had really focused on the light weight integration components.

  • Azure Service Bus Relay
  • WCF Routing Service
  • WCF
  • Azure Service Bus Messaging
  • AppFx.ServiceBus messaging framework

We were able to do lots of agile and low cost integration patterns but we did hit challenges when we got to some of the more complex situations and there were cases where we needed something like the BizTalk orchestration capability.

 

Example 6

In this example we were looking at another simple light weight integration solution but this time instead of Azure Service Bus, RabbitMQ was the chosen queue technology.

  • RabbitMQ
  • .net
  • WCF

With this platform you can do many of the light weight requirements but some of those harder workflow based requirements will be difficult to implement.

 

 

As you can see there are a number of different ways you can build your platform and there are also considerations like do I build the entire platform up front and hope it gets used vs do I incrementally build it as I need to.  Would be interesting to hear what others are using.

 

Buy Me A Coffee