Request/reply and services with Ingescape

French version

The issue of the interoperability in computer systems appeared at the same time as the first client/server architectures and has since continued to evolve around the notions of requests and responses (request/reply), as well as remote function calls (RPC/RMI). Client/server architectures remain the most widespread solution for making distributed systems interoperate, even if the limits imposed by this approach in terms of the level of coupling of the components have found solutions for more then a decade through software buses and stream exchanges (see Ingescape Platforms – Part 2 – Software Buses and Data Flows with Ingescape). 

This article takes up in a chronological and general way the successive contributions and changes around client/server communications by highlighting the issues and good properties that have emerged over time. We then present how Ingescape positions itself vis-à-vis this history and provides a state-of-the-art solution, as well as improved interoperability principles around the request/reply pattern.

If not already done, we recommend first reading Ingescape Platforms – Part 1 – Distributed Architectures and the Cloud with Ingescape.

Client/server

The principle of client/server communications has been the same since its origins and remains very present in the most current architectures. A server listens to requests from clients. A request includes a structured set of information that is processed by the server and can give rise to a response, also composed of structured data, from the server to the client that sent the request. To formulate a request, a client must know the address of the server. To respond to a request, the server must know the client’s address. This is what is called a strongly coupled system where any evolution of the server has repercussions for the clients who must also comply with the protocol imposed by the server.

Over time, client/server architectures have made it possible to cope with load increases, availability and resilience requirements, and the necessary specialization of servers in terms of the requests they know how to process and therefore to the complexity of their development. This is how appeared 3-tiers and then N-tiers architectures.

At the same time, clients have diversified according to:

• Heavy clients : independent applications running natively on an operating system,
• Light and rich clients  : applications running in a web browser with more or less complex application logic.

From the point of view of interoperability, the distinction between types of clients remains induced by the limitations of web browsers, particularly in terms of communication capabilities, necessarily passing through HTTP requests and more recently through websockets. This as opposed to stand-alone applications, capable of communicating by all other existing means (TCP/IP sockets, IPC, shared memory, etc.). In a given ecosystem, all types of clients, whether heavy or light, in fact share the same protocols and the same communication technologies.

SOA – Service Oriented Architectures

With N-tier architectures, communications protocols remained specific and difficult to represent and implement. This is how service-oriented architectures or SOA appeared, still using the principles of client/server and request/response but allowing a simpler description and composition of the exchanged data, thanks to XML and then JSON formalisms qualified as “pivotal formats” between the involved software entities.

The concept of “service” at the heart of the SOA acronym comes from the fact that the servers are hidden behind a layer of services responsible for encapsulating them and abstracting them through a communication protocol and a pivot format whose definition qualifies a service accessible to clients. This has the effect of lowering the level of coupling between the clients and the servers: the servers can evolve and even replace each other as long as they implement the same service, characterized by its communication protocol and its pivotal format for exchanges with clients. Similarly , clients are independent of servers and are only aware of services which can then introduce load management, fault tolerance, etc. to orchestrate different servers.

In concrete terms, for developers of servers, services and clients, SOAs have been democratized with the HTTP protocol above which have been grafted  SOAP and REST architectures and XML and JSON pivotal formats.

With this very open approach, SOAs can quickly generate a large quantity of services, posing two problems : their discovery by clients and their hosting, associated with administration tasks. We address both of these issues below .

ESB – Enterprise Service Bus

Services discovery is generally provided by a directory – which is itself a service – that clients and servers consult to obtain addresses and pivotal formats to use. The servers themselves may rely on third-party services and are therefore also clients. A set of services accessible from each other and coupled to a directory is called an enterprise service bus or ESB. This term actually designates an organization of a set of servers encapsulated in services and indexed in order to facilitate their use by developers and users of client applications of all formats (heavy, light, rich).

Security , encryption and authentication (or identity management, in particular Single Sign-On or SSO) are cross-functional services that are part of the ESB.

In the acronym ESB, the word “bus” is used to refer to the fact that services and clients are usable via their address, independently from the physical locations of the underlying computers. Some people consider this name imprecise insofar as buses generally designate architectural principles involving the notion of subscription.

Microservices, virtualization, containerization and cloud

Historically, services were hosted on independent computers, physically connected to a local network. The advent of virtualization (virtual machines) and containerization  technologies – including the iconic Docker technology – have made it possible to significantly increase the flexibility of hosting methods by completely freeing the correspondence between servers/services and physical computers.

This increased flexibility, combined with the specialization of data processing, has also made it possible to reduce the size of services, as well as their ability to become more generic and reusable. This is how we talk about microservices that can be put into play in a system with virtualization/containerization mechanisms (vmware, docker, etc.) and the management systems that accompany them (kubernetes, etc.). These micro-services can operate on local hosting or in the Cloud, i.e. on delocalized and remotely accessible infrastructures.

Remote Procedure Calls and Remote Method Invocations – RPC and RMI

The request and response (or request/reply) design is characteristic of the client/server architecture and its descendants. However, the ability to transmit a command, with or without data, from one program to another through a communication medium (TCP/IP, IPC, etc.) is another software development concept used according to other principles grouped around Remote Procedure Call (RPC) or Remote Method Invocation (RMI) in object- oriented context .

Many RPC/RMI solutions exist and have succeeded in different programming languages and frameworks (Qt Remote Objects, XML-RPC, D-Bus, CORBA , etc.). All share the notions of commands accompanied by parameters, inherited from the calls of functions or object methods in classical computer programming. These commands can be synchronous : the client issuing the command is blocked until it receives the response from the server. But most RPC/RMI solutions today have become asynchronous, leaving synchronicity to specific cases that still require it.

Ingescape for services and request/reply

Basically, the different forms of request/replies andRPCs/RMIs rely on exactly the same principle of remote function calling with or without parameters. The related issues are also identical:

• For a given service, formalization of “functions” and their parameters , shared between clients and server,
• There are many formalisms including SOAP, WSDL, CORBA, etc. They create opportunities for automatic code generation, verification of formalisms, versioning of services, etc.
• Addressing a service for a request, and conversely addressing a client in the event response,
• Access to services from thick and thin clients, on local networks and/or from the Internet or remote and secure networks.

Formalization of “functions”

In today’s Cloud world, HTTP/REST/JSON solutions are the most popular for request/reply. In this “web” context, the development of a service, although largely tooled and using high-level descriptions, remains a process that takes several hours to several days between design and commissioning. The main cause is the number of software layers and therefore the amount of code (third party or specific) involved to ensure the operation allowing a client to call a service, a service to process the request and generate the response, and the client to process the received response.

RPC/RMI solutions are generally more direct to implement, linking calls to functions or object methods from a client to the related service then, in the most frequent case where the response is received asynchronously, by calling a client-side function, often called a callback, to process the received response. This is akin to basic principles of reactive programming that are easy for developers to understand.

An Ingescape agent exposes its services, called Ingescape services, in the manner of named functions, having a certain number of parameters (zero or more), each parameter being named and typed, according to the usual types proposed by Ingescape (bool, int, float, string, data).

With Ingescape, a myService service having a first parameter parameter1 of integer type and a second parameter parameter2 of character string type, exposed by an agent myAgent can be called from another agent according to a logic myAgent.myService(12, “my string” ), i.e. like calling a method on an object with the appropriate parameters.

The services of an agent are modeled in the definition of the latter. This is the form our example above takes in the Ingescape template:

{
    "definition": {
        "name": "myAgent",
        "version": "1.0",
        "services": [
            {
                "name": "myService",
                "arguments": [
                    {
                        "name": "parameter1",
                        "type": "INTEGER"
                    },
                    {
                        "name": "parameter2",
                        "type": "STRING"
                    }
                ]
            }
        ]
    }
}Code language: JSON / JSON with Comments (json)

And here is the visual and editable form it takes in the Ingescape tools suite:

If an additional need for structuring is necessary, the proposed model can be supplemented by third-party formalisms. For example, a “character string” type parameter can be defined as being JSON or XML with which a particular schema (DTD, XSD, etc.) is associated. Similarly , a “data” type parameter , i.e. binary data, can be defined as serialized structured dat , associated with a serialization formalism such as Protocol Buffers with a specific “.proto” file and message. In this way, there is no limit to the complexity of the data that can be exchanged through the& nbsp ;services.

Depending on the computer language in which the agent is developed, the service is directly mapped to a processing function that directly takes up the service parameters, as well as the identity of the client calling the service (or the server that generated the response) . In this way, the developer has the direct possibility of responding to a request, without having to delve into different software layers.

In addition, the services  exchanged with Ingescape also incorporate a concept of token which allows individual monitoring of the various requests and responses, so that when a client sends requests to a server, the client always knows which of its requests corresponds to the received answer, which also carries the token.

The  Ingescape services therefore offer the same conceptual and formal possibilities as web services of the HTTP REST/SOAP XML/JSON type and as the world of RPC/RMI, with a much simpler level of complexity, equivalent to that of declaring a function in a simple computer program. If we add the fact that it is for example very simple to create a “server” agent using the NodeJS technology and “client” agents operating in JavaScript in a browser web, Ingescape can be directly evaluated and compared to the usual HTTPS/REST/JSON technologies to concretely measure the contributions in terms of efficiency, control and supervision of requests/responses.

Addressing and access to services

HTTP/REST/JSON solutions require the implementation of an addressing and name resolution system linked to the HTTP protocol. RPC/RMI systems generally rely on similar solutions with a central directory.

In contrast, Ingescape is based on a completely decentralized meshed network (see the article Ingescape Platforms – Part 1 – Distributed Architectures and the Cloud with Ingescape). To use a service, it suffices to know the name of the agent which carries it. The availability of an agent and the services it carries is actively detected by the other agents, just like a disappearance, due to voluntary stoppage or breakdown: each agent knows in real-time which are the agents present. Ingescape therefore provides a capacity for  resilience and natural dynamic adaptation, difficult to set up in classic client/server systems.

Several clones of an agent can carry the same service and coordinate together to provide hot redundancy and a “front” agent can also serve as an intermediary for a team of “calculation” agents in order to perform a load balancing on one or more virtual or physical machines, or even on different infrastructures.

The monitoring capabilities of Ingescape platforms provide a unique ability to detect variations or inconsistencies in agent service descriptions via their definition, which is itself versioned. Ingescape therefore provides a  global consistency check  at the scale of a platform, this control being updated in real time at the time of any arrival and any departure of an agent, allowing reactivity and an immediate alert in the event of inconsistency or loss of service.

Finally, HTTP/REST/JSON solutions often offer low communication performance, inherent to HTTP/TCP/IP, with high latencies and predetermined communication channels. The “multi-transport” aspect and the raw performance of Ingescape make it possible to achieve much higher performance, solely dependent on the physical locations of a client and a server and the bandwidth accessible between them. With Ingescape, since communications are not limited to TCP/IP but can benefit from much faster channels if the services are located on the same hardware, Ingescape services are also suitable for very high performance processing without modifying the existing code for the developed service.

Interoperability between Ingescape and other types of solutions

Unlike all the third-party technologies mentioned in this article, Ingescape offers natural interoperability with HTTP /REST/JSON and RPC/RIM solutions. Based on formalisms such as the WSDL or Swagger/OpenAPI, and using the automatic code generation technologies accompanying Ingescape, it is particularly easy to create gateways between Ingescape platforms and existing systems of the client/server type, using HTTP/REST/ JSON or RPC

Here are the interoperability schemes facilitated by Ingescape with respect to the client/server approach:

• Gateway
  • An existing web service on a given server can be encapsulated by a dedicated Ingescape agent that translates each web service into an Ingescape service with the corresponding parameters . The agent formulates requests to the server in HTTP/REST/JSON format and retransmits the responses from the server directly to the agent having requested a given service. This gateway type approach allows a very simple implementation of existing web services to a local or remote Ingescape platform and is also valid for RPC/RMI type solutions.
• Hybridization of an existing server
  • In a more integrated way , a server can include an Ingescape layer in parallel to an existing HTTP/REST/JSON or RPC/RMI layer. In this way , the server becomes an agent in its own right and can offer much better communication performance than HTTP/REST/JSON without giving up the latter. From experience, the implementation of this type of strategy for Microsoft SQL Server, NodeJS, etc. is very simple to implement and imposes negligible constraints on the architecture and the load of the existing server.
• Ingescape agent as HTTP/REST/JSON or RPC/RMI server
  • A service carried by an agent as an Ingescape service can also be relayed via a gateway or directly by a HTTP/REST/JSON or RPC/RMI implementation by the agent itself, which then also becomes a server.

These three approaches show the flexibility that Ingescape brings to the decompartmentalization of data and services in a client/server context.

Summary

As a summary , we provide a table presenting the major principles expected for client/server, request/reply and (micro)services solutions, and how Ingescape handles each of them.