The following sections describe concepts to operate the E2E Bridge in a reliable and scalable manner. How to do this depends on the use case. The two most common use cases are online services and batch processes. Both scenarios must take into account different requirements since online services may come under heavy load depending on the number of parallel running clients whereas batch processes are normally not run in parallel but frequently process big files.

High Availability

High availability is a main point for integration systems. The E2E Bridge addresses high availability on different layers:

Robustness of the Service

Service developers should address the topic of reaction on “expected” errors (e.g. non-validation inputs) or temporary application outages at design time already. Approaches to achieve this are:

Self-recovery of the E2E Bridge

The E2E Bridge has the built-in capability to recover itself in case of unexpected errors:

Load Balancing

The E2E Bridge can be integrated into any existing load-balancing infrastructure.

Refer to Load Balancing for a detailed description of a load balancing scenario.

Database Management System

The E2E Bridge persists any business data in an external database. For each service, the developer can decide on whether he wants to use a central fully-fledged RDBMS system or to rely on a small footprint, file based SQlite DB. SQlite provides for very high performance and scalability, but – as it is file-based - does not allow parallel access by different processes or threads.

In scenarios that include high availability and disaster recovery concerns, the way to go is to use a full RDBMS system. We fully support Oracle®, MySQL® and MS SQL® databases. With Oracle, we even support clustered database setup and cluster failover handling as described on Persistent State Using Clustered Oracle Database.
For separation of concerns, a dedicated DB schema per process is recommended. Within this schema, the E2E Bridge will basically create tables and manage their contents.

For more information on supported databases and how to install them, refer to Installing and Configuring Database Access.

Disaster Recovery

The E2E Bridge uses an external RDBMS to store any application-relevant dynamic data, e.g. data retrieved by external applications, data calculated or collected by the services, status information about current process instances that are being handled
Considering that the E2E Bridge supports implicit and explicit transaction handling, this way all important business data is persisted in the database at any time. Business data recovery and continuity therefore is a question of the database’s disaster recovery routine, which the E2E Bridge neatly integrates into.

Besides the database, the E2E Bridge also uses the file system to persist data (e.g. log files, infrastructural settings). The replication of this data is usually not business critical and thus irrelevant for disaster recovery, however an integration into the customers file backup mechanisms is recommended.

In general, for disaster recovery, a mirrored counterpart of the active productive system is recommended. For detailed information regarding high availability see above.
Refer to Bridge Backup for more information on how to take a Backup of an E2E Bridge installation and all deployed services.

Additional Topics


Refer to Monitoring Load Balanced Nodes for more information on the monitoring concept of the E2E Bridge.


Security requirements can apply to the E2E Bridge itself, or to services running on the E2E Bridge.

Configuration Management

Concerning service development, we recommend to deploy service repositories in a development, test, and productive environment. This development scenario is explained on Configuration Management.