The web is a disconnected architecture. A disconnected architecture means, the server creates a channel between the clients, sends the data between these channels, and disconnects itself. Hence the server can unload all the resources necessary to communicate with the client after the response is sent back to the client. This approach even though it is very effective in most cases, modern applications cannot operate only with it. The resulting disconnected data negatively impacts business growth. Thus, it requires a ready communication system for communication across a disconnected application ecosystem.
HTTP lacks server push operation, meaning, the Web always needs to proactively request a resource, and then only the server responds to the request. Now, what if you need to do a long-running job with continuous notifications on the browser when the job is done? You cannot do it with Web through classic HTTP, because it does not support continuous streams of data. One option is that you continuously poll the server to get updates. But making so many connections to the server continuously may kill the resources over a period, eventually making it an unreliable solution. This is because if you employ HTTP, there will be multiple connections made to the server over time even when it is not required. The server must load the data into memory but without anything to do with it under most circumstances.
APPSeCONNECT uses heavy-duty operations and relies heavily on its workers. These workers do all the heavy lifting like sending bulk emails, updating subscription notifications, publishing scripts, and even installing packages. These tasks may require a huge amount of time and even resources, which is why we cannot rely on performing these operations directly through HTTP protocol because of implicit timeout.
Communication System for Inter-Process Communication
Being a multi-tenant application, it is a requirement to have resilient communications. For the purposes of inter-process communication, we use the following Communication Systems:
1. Enterprise Service Bus (Indirect Communication System)
Offline tasks which are implicit and do not require human input may be implemented using indirect communication. In the case of indirect communication, we need the following communication system setup:
Here the producer is the Web Application or any application (for example a Scheduler application) which places a message into an Enterprise Service Bus. Suppose there are “n” number of consumers that works in tandem to read from the queue and follow the instructions. Here the service bus will also have Persistent storage, which makes it a fail safe in case of a disaster. AMQP or Advanced Messaging Queuing Protocol is used as the communication system between the communicating agents.
The image which we have depicted above is a simplified version of how the working principle of indirect communication works, in actuality it is just an aggregate of multiple processes with multiple Service bus instances.
Some use cases for Indirect Communication:
- Scheduler executing ProcessFlow over a schedule.
- Sending Daily Emails or execution of Rules.
- Generating scripts for Deployment
- Triggers from External LOB Applications through Webhooks and many more.
Each of these indirect communications has an underlined persistent storage in place, such that it can be resilient to external failures.
2. TCP Sockets (Direct Communication System)
Now that you have understood the indirect communications for background processing, sometimes it is the users who invoke an operation that requires direct communication between the client system with the server systems. Here Direct Web socket connections are necessary.
APPSeCONNECT Hub is the server that connects all the applications or components together. It creates a connection between the Web Browsers, the Background Processors, and the Agents. We call any client application which connects to the Hub as a Hub proxy. The Hub Proxy requests to connect to the Hub using an HTTP request. This is a handshake request which enables the server to generate a long-running connection between the agent and the Cloud. The data sent to the Web socket then on will follow the WSS (WebSocket Secure) protocol which is a standard for secure web socket connectivity.
For example, in the above diagram, the simplified version of real-time communication is explained. The user opens the Web Portal and automatically gets connected to its own tenant, placed in our Host Server. Similarly, the Agent component is also connected to the same Hub in our Host Server, such that it forms a group of connections for each tenant. Here in our case, a Tenant is just a representation of one customer.
The authentication system to the Hub requires a valid organization identification, such that it can create a hub for a particular tenant. Now when the user sends a signal, in our case, a signal to execute a ProcessFlow, the Hub receives the request and transfers it to the Agent for which it is requested. This way, the Hub acts just as an intermediary to generate real-time communications between the server and the client.
Some use cases of Direct Communication:
- Execute ProcessFlow from Web Browser.
- Deploying a ProcessFlow.
- Getting a Snapshot for an On-Premises Execution.
- Fetching Operational logs and many more.
Now that you understood the basic premise of our real-time communication system, you must understand how the signaling happens to the browser. As you know, browsers are generally very diverse in nature as the users use various brands and versions of them. Supporting the latest features through it and giving everyone the best-of-breed experience requires a lot of additional processing. Let us look into the architecture of our Hub.
Here in the above image, you can see how our Hub architecture is laid out. Our Hubs will automatically identify the transport options and depending on the features present, it will first try to open Web sockets, but if it is not available, it will try for Server sent events. Now there are browsers that are old enough and are not capable of invoking any of them, for those scenarios, we have Forever frames, where an iFrame will be requested but the request is held forever in HTTP. This is a bypass of the HTTP Protocol. But sometimes iFrames are not accepted by the servers, in such a case we use AJAX long polling. The hub also has a Persistent API layer which lets us save the Groups and data into storage.
The agents connect to the Hub using their own proxies and then uses the created communication system to send data to and fro to the Hub.
Conclusion
As communication is one of the major requirements for any distributed application, we employ huge effort into building a resilient and robust communication system such that each of the components can individually create its own communication system to get connected with the server. Our communication system is completely decoupled and uses standard protocols to communicate, with each of the tenants being completely isolated from one another. In the case of indirect communication, it is separated by Service Bus instances, or Service Bus Topics, while in the case of direct communication it is separated by Groups and authentication. This system is open for extensibility and can be used for various other enhancements that can be done in near future.
Thank you.
If you have multiple systems employed in your business and want to seamlessly integrate all the data and processes between them, connect them under one single platform with our hybrid iPaaS APPSeCONNECT. Automate business processes and improve your productivity and efficiency with us!
