The system itself can be integrated in different ways, such as:
* direct integration (communication via API point-to-point, advantages: minimum overhead, disadvantages: two-way revision of systems is required, complexity of change management, complexity of scaling, no reuse);
* using gateways (communication through the API of an integration layer, such as a queue with a firewall, advantages: minimum overhead, unified API, disadvantages: complexity of change management, complexity of scaling, no reuse);
* Enterprise data bus or enterprise service bus (ESB) provides asynchronous umbrella integration based on the principles of event and service approach (SOA, service-oriented architecture). The corporate data bus is able to flexibly route messages from one service to another. (advantages: unification, reusability due to SOA, replaceability of services due to SOA, disadvantages: an expensive solution in many applications, delivery time from tens of milliseconds);
* Service Mesh, like ESB, is umbrella, but applications do not need to integrate with it, since applications running in a containerized environment immediately receive integration. (microservices, advantage: minimum overhead, not noticeable for application developers);
* Integration file gateways and point-to-point file transfer (file overload). Point-to-point file transfer is the same point-to-point transfer, but it allows you to transfer large data in exchange for the transmission speed (advantage: it is possible to transfer very large amounts of data, high delivery guarantee, weak connectivity of integrated systems, greater control, broadcast mode, disadvantages: transmission speed, possibility of desynchronization, high security requirements). Communication protocols are CIFS (Common Internet File System), NFS (Network File System extends the local file system) and S3 (Simple Storage Service provides access to object storage such as Minio and Ceph) and transfer protocols HTTPS (HTTP + SSL), SFTP (SSH + SSL) and FTPS (FTP + SSL). From the point of view, records can be divided into block (disk) and object (writing to the key-value database: Bucket).
Systems can communicate in various ways:
* integration request (normal synchronous request-response),
* remote procedure call (RPC),
* sending a command to the queue (from the supplier to the consumer directly through the event queue),
* publish-subscribe, Push-Sub (sending events to a common queue, from which groups of events are retrieved from the system in advance, undefined by the provider),
* packet data transmission,
* transferring files to storage,
* streaming data.
The interactions themselves should be described, and preferably unified. To describe functional or non-functional parameters (response time, availability, message size, bandwidth) of interactions between the supplier and the consumer, a Contract is used, which the supplier undertakes to fulfill. Functional parameters are described using the Application Programming Interface (API). Service APIs can be divided into groups based on message format (DTO, JSON, XML, binary) or protocol (HTTP, REST, SOAP). It is important to specify in the API contract: ID, name, version, purpose, template, specification of input and output parameters. The API itself will contain methods (encouraging the consumer to take data, change, allocate, etc.). Parameters passed in a method are described by a method specification, for example, using OpenAPI or Swagger. For many languages, and primarily for the Java language, you can automatically generate a specification for OpenAPI using Swagger by Javadoc annotations (by special comments) in the code. The specification will be displayed in both text formats (JSON and YAML) and graphical. For ease of design, you can use the Swagger Editor (https://swagger.io/tools/swagger-editor/). This helps to organize automated contract testing. In general, the presence of the specification helps to organize API-first development, when the API specification is first written, and already the application code is developed for it, implementing it.