Architecture overview

Global overview

Holodeck B2B is a standalone application that provides the messaging capability to your solution. The Holodeck B2B gateway takes care of all complexity related to messaging protocol used for the message exchange with your trading partner, the business application only needs to provide the business documents and some meta-data telling Holodeck B2B who to send the data to.
The default distribution available for download provides the AS4 messaging capability and has an easy to use file based integration method with the business application.
Using Holodeck B2B’s extension mechanism additional functionality, like for example AS2 messaging capability or REST back-end integration can be easily plugged into the gateway. This allows you to create a gateway tailored to the specific requirements of your environment.

Modular architecture

The Holodeck B2B gateway uses a modular architecture as shown in the picture. It implements the separation of concerns principle to enable easy adaption to the needs of the target environment. The main module is the Core which handles the message processing.
Around the Core module is an interface layer (the API) operating in two directions:

  • Defining functionality offered by the Core that can be used by connectors and extensions.
  • Defining the functionality needed by the Core which can be provided by extensions.

Using this interface layer, Connectors realise the integration with the business application and Extensions implement the functions needed by the Core, for example the storage of message meta-data.
The open source distribution includes default implementations of the Extensions for the functionality needed by the Core and a file based Connector to integrate the gateway with the business application.

Holodeck B2B layers

Main components

The Archimate model below shows an overview of the main application components that exist in every Holodeck B2B gateway implementation and the functionality they provide. These components are:

  • Message handlers: these perform the actual message protocol processing and implement the actual exchange with the partner gateway. There are two “kinds” of message handlers, one responsible for the protocol specific processing like parsing the messages and processing message level security. The other kind are message handlers for more generic functionality as processing receipts, error and delivery of business data to the business application.
  • Security Provider: is responsible for the processing of the WS-Security headers in ebMS3/AS4 messages. In feature releases the interface of this component may be generalised to handle the message level security of other messaging protocols as well so there could be a security provider per protocol (or type of message level security).
  • Certificate Manager: handles the storage of key pairs and certificates used for message level security. Also provides a function to validate the trust in a certificate to allow only registering the trusted certificate authority for a domain without the need to register all partner certificates. By replacing the default implementation it is possible to implement specific certificate and/or trust policies.
  • Persistency Provider: stores the meta-data of the messages processed by the gateway. Besides the meta-data included in the messages, like the Sender and Receiver, this also includes Holodeck B2B specific meta-data like the P-Mode and processing state of the message.
  • Message Submitter: the Core component that accepts the business documents and meta-data for sending them to the trading partner. It checks whether the documents can be sent before triggering the sending process. This includes checking that enough meta-data has been provided and may also include custom validations.
  • Delivery Methods: are components part of Connectors and responsible for the delivery of business documents in received User Messages and notification on Signal Messages to the business application.
  • Workers: these components act as services and handle recurring tasks like triggering pull requests and watching for configuration changes.