Whitepaper continued... 

Introduction: This is a continuation of the whitepaper on the Host Integration Server introduced here. We now elaborate on the four components of the overall design – namely, APIs, Events, Messaging, and Orchestration.  

Description:  

1) APIs 

APIs are a prerequisite for interactions between services. They facilitate functional programmatic access as well as automation. For example, a workflow orchestration might implement a complete business process by invoking different APIs in different applications, each of which carries out some part of that process. The majority of these steps are backend processing for the host integration server and providing APIs from this server enables downstream automation. 

Yet making APIs available for other software to call is harder than one might think due to the questions that need to be answered as follows: 

How is the number of calls from the application be rate-limited, authenticated, authorized, and audited? 

If the APIs are going to be published which is the typical case, how will they be secured and hardened? 

If the API response time is critical, how to squeeze out top-notch performance from the API layer? 

How to monitor and analyze how the APIs are called so that the patterns in API usage might indicate a trend that significantly impacts the business? 

How to make the APIs developer-friendly to endear them for integration? Will documentation, code samples, and others suffice? 

The benefit of hosting the service on Azure encompasses these questions and automatically addresses all these concerns by the Azure API management. 

2) Orchestration: 

Integrating applications commonly requires implementing all or part of a business process. It can involve connecting software-as-a-service implementation such as Salesforce CRM, update on-premises data stored in SQL Server and Oracle database, and invoke operations in an external application. These translate to specific business purposes and custom logic for the Host Integration Server. 

This logic does not need to be monolithic. One option is to build it in the traditional way using C#, JavaScript, Java, or some other programming language which brings certain limitations such as delays and retries. Another approach might involve defining these via a workflow so that the steps can be completed independently by any agent and with context. 

Azure Logic Apps facilitate this approach. Each logic app is a workflow that implements some process. This might be a system-to-system process, such as connecting two or more applications. Alternatively, it might be a user-to-system process, one that connects people with software and potentially has long delays. Logic Apps is designed to support either of these scenarios. 

Finally, a logic application can access all kinds of other applications.