B2B, Are Microservices a bad integration solution?

Question

Is it bad idea to base business to business (B2B) type of integration projects on the microservices architecture?

By Microservices we mean autonomous services directly interfacing with each other by loosely coupled interfaces, typically REST. Dump pipes and smart endpoints. Could this lightweight principle work in the large scale B2B integration? Or is this where the more heavyweight SOA solutions are still more justified?

Consider the X-Road, national service portal of Estonia for example.

According to their web page, "The X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. The X-Road is a centrally managed distributed integration layer between Information Systems that provides a standardized and secure way to produce and consume services. The X-Road ensures confidentiality, integrity and interoperability between data exchange parties.

How would the microservices approach adapt to the integration project of this scale if we ignore juristic requirements for centrally managed gateway? Would it end up as unmanageable without central integration provider and well-defined WSDL contracts? Also, important thing to consider is the identity management and access control across the autonomous systems.

Answer 1

No, Microservices is an absolutely fine and cool way of building B2B integration systems because it showcases a lot of qualities that you want to have when building such systems:

1. Higher fault tolerance via circuit breakers
2. No domino effect if other systems are down
3. Eventual consistency
4. High availability via CRQS and event sourcing.
5. Ease of maintenance and disposability of sync systems.

Answer 2

X-Road is the software that is used nationwide in the Estonian data exchange layer X-tee and in the Suomi.fi Data Exchange Layer service in Finland. X-Road is the data exchange layer between the national service portals (eesti.ee , suomi.fi) and various data sources, registries and information systems. Therefore, X-Road and a national service portal are two different, independent information systems.

I think that a contract, an agreement between a service provider and service consumers, is a must have requirement in both SOA and microservice-based solutions. One of the key aspects of both approaches is the ability to deploy services independent of one another. The independence is achieved using versioned and well-defined contracts. The underlying technology and implementation of a service can be changed as long the contract does not change.

X-Road can be used as a data exchange layer for solutions based on both SOA and microservices. Compared to direct point-to-point integrations X-Road implements a set of common features to support and facilitate data exchange. X-Road provides the following features out of the box:

• address management
• message routing
• access rights management
• organization level authentication
• machine level authentication
• transportation layer encryption
• time-stamping
• digital signature of messages
• logging
• error handling.

The identity of each organization and technical entry point (Security Server) is verified using certificates that are issued by a trusted Certification Authority (CA) when an organization joins an X-Road ecosystem. The identities are maintained centrally, but all the data is exchanged directly between a consumer and provider. Message routing is based on organization and service level identifiers that are mapped to physical network locations of the services by X-Road. All the evidence regarding data exchange is stored locally by the data exchange parties, and no third parties have access to the data. Time-stamping and digital signature together guarantee non-repudiation of the data sent via X-Road.

In addition, each service published on X-Road must provide a service description, currently a WSDL description. However, a native REST support will be available in 2019 and then OpenAPI service descriptions will be supported too.