VersaCloud as a Cloud-Based Middleware Server in depth

Our cloud-based middleware server, depicted from a high-level perspective in Figure 1, is designed to function as a middleman or broker for all transactions run on back-end servers on behalf of demands received from users. Users might be running end-user software on any kind of device connected to the Internet: examples include standard executables running on some computer, apps running on mobile devices like smartphones, tablets or smartwatches, or web pages running inside a browser that have associated programming logic developed in a scripting language (like for example JavaScript).

In order to access our transaction server, the chosen user environment must be able to communicate using one of the protocols for which our transaction-server has a front-end connector implemented. Each of our front-end connectors is an independent software module, hosted inside our cloud-based middleware server, responsible for receiving API calls from end-users using exactly one specific communication protocol, and routing calls received to our single entry point engine, as depicted in Figure 2.

For example, element represents our Web-Service Front-End connector, which is implemented as a Web-Service on our cloud-based middleware server, hence being called on behalf of users by sending an XML file containing information about the desired API call. Our connector just parses the XML file and sends data into the single entry point engine.

Another connector is based on Microsoft's OLE DB remote database access protocol, which allows end-users to call a stored procedure on our cloud-based middleware server, which then routes the call to our single entry point engine. Our OLE DB connector is implemented as a stored procedure on SQL Server.

By isolating the communication protocol from the single entry point engine, VersaCloud's cloud-based middleware server can handle as many protocols as needed, without any need for changes inside our single entry point engine coming up due to communication protocols requirements.

The same protocol-based routing concept is used by our single entry point engine to access services provided by back-end servers. For each protocol involved, we implement one back-end connector: each is a software module receiving data from our single entry point engine with the only purpose to send it over to a back-end server and then retrieve a single return value.

In order to manage this data being sent from end-user software to back-end servers, our single entry point engine needs to store, besides the data itself, data about each and all transactions started, about the users allowed to start them and the services they can demand from back-end servers. The best way to conceptualize our single entry point engine is considering all of this data as a huge finite state automaton, responsible for storing the state of each user, of each transaction and of each back-end provided functionality's details.

As the volume of transactions to be handled could easily grow into millions per day, the concrete implementation of the finite state automaton is based upon a relational database, whose data is accessible only to our single entry point engine: inside this specific relational database implementation, one table exists for each type of entity we need to store state data (like users, transactions, rights, and so on).

This multi-tier architecture can also be described as a Service Oriented Architecture (often represented by the acronym SOA), where back-end servers provide basic services, and our middleware servers' single entry point engine functions as the service 'bus' – using bus in this case with the same meaning it has in hardware design, where it is used to name the set of connections that let data flow between integrated circuits sitting on a single board.

VersaCloud's cloud-based middleware server could be integrated with a variety of new types of front-end software and/or back-end servers, just by adding new front-end connector or back-end connector modules.

Regarding front-end software, we observe that new types of end-user devices are launched by hardware manufacturers on an almost continuous basis: new mobile platforms are introduced, while others leave the market. Also, new Internet-connected devices are being introduced continuously: drones, refrigerators, autonomous cars and wearable devices are some examples of new devices that have not yet standardized communication protocols. Migrating from one to another over time is much easier and cheaper if the remaining parts of the software architecture remain stable, as is made possible with our cloud-based time-limited transaction manager.

US Patent Requested