In part 5 of the evolution of the Azure based integration platform we had some new initiatives around exposing API’s to external parties.
The aim was to expose an API that business partners would be able to integrate with parts of our technology estate. It could have equally been exposing API for mobile devices or to app developers or one of the many scenarios but in this case it was about partners.
Rather than jump to the platform diagram I have decided that this solution is a little more complex and we need to also add a diagram illustrating how the solution would look.
In this case we would add Azure API Management to our platform. This is kind of a no brainer for an external API project because its a low cost addition but it also allows us to stick a proxy in front of the API have a place to manage the API but to also get a bunch of monitoring information. We can also implement a couple of patterns here if required too.
For the back end behind the API we have chosen to implement a custom WebAPI component which will be hosted in an Azure Website. We could have also considered an Azure VM or Web Role but the Azure Website is simpler from our perspective and lets Microsoft manage more of the experience for us.
Behind the API we will use Azure Service Bus for much of the communications infrastructure. This allows us to implement one way, two way and call back message exchange patterns. It also allows us to do publish and subscribe.
We may have a couple of different subscribers which collect messages from service bus. These include:
- BizTalk Server
- A .net messaging framework hosted as an Azure Web Role
- A .net messaging framework hosted as an on premise windows service
A point to note at this stage is the .net messaging framework for Azure Service Bus is the AppFx.ServiceBus framework which is available on codeplex. This framework is really light weight and is ideal for collecting messages from service bus and sending them to a WCF Service and potentially returning a response. We would tend to use BizTalk as the processor for messages when the message handling is more complex and requires complex transformation or orchestration or another of the features BizTalk provides. When it was just simple message forwarding the AppFx.ServiceBus component gives us something very similar to WCF Routing Service.
If you have taken a few mins to digest the information above and review the diagram you can see we have implemented a message bus pattern with a couple of different options for processing messages depending on what we need to do. One way is light weight and can work with on premise or cloud options and the other allows us to implement more complex patterns. On top of this message bus we have simply added an API Gateway style component to expose this integration platform to the external world in a way which is easy for them to consume. This is an approach I have used a number of times in the past and the biggest benefits or this are the speed of delivery around exposing new API features because of the plumbing infrastructure which is easy to work with.
Next lets take a look at how this new solution has added and evolved our Azure based integration platform. I have highlighted with a red box the bits which have been extended or added.
In this case we have made the following changes:
- API Management has been added to make it easier to secure, manage and monitor any API’s we expose. This can be reused for other API’s we add in the future
- We have extended the use of Azure Websites to host our custom API Gateway which we developed in .net with WebAPI
- We have extended the use of Azure Service Bus to use a new namespace to contain the messaging bus behind the API to support communication with our various integration resources
- We have added the use of an Azure Worker role to host the .net messaging framework for simple cloud hosted message processing
- We have extended the use of BizTalk for complex message processing
- We have added an on premise Windows Service to host the .net messaging framework for simple on premise message processing
In addition to these changes we would be reusing the use of the WCF Service Proxy components we created for our applications earlier in the platform evolution. The ones we used would depend on the features we build and the data we need but we could use the ones hosted on premise or in the cloud as an Azure website with very little effort.
With this architecture we have the foundation of a platform which is a powerful enabler for creating API solutions specifically for this project but also there would be a lot of reuse opportunities for future API and other types of project too.
