Beryllium is designed to be an open and modular solution to interconnect disparate applications across different security domains. It allows for a decoupled implementation to enable disparate applications to share messages without any temporal dependencies. Within the Beryllium framework Beryl controls the actual transfer of messages along with providing its own message transport. Beryllium includes a facility to manage Beryl processes as well as provide for interfaces to high-level applications, through a set of APIs.

The Beryllium architecture can be depicted as a layered model as follows:

Figure 1. A layered model for Beryllium architecture.

In this layered model Beryllium has two Beryl servers each at Organization A and B. A Beryl Master Server resides within the security perimeter of these organizations. A Beryl Slave Server resides outside the respective security perimeter at each location, typically in a DMZ network. For messages to flow between these organizations, the Beryl Master Server would accept messages from the applications layer above it and place them in queues to be transferred over to the Beryl Slave Server at that location. The Beryl Slave Server in turn initiates a secure session to Beryl Slave Server at the destination for delivery of messages. The Beryl Master Server at the destination is set up to poll, at a predetermined interval, respective Beryl Slave Server for arrival of new messages. When new messages arrive at the destination Beryl Slave Server, they are pulled in by the Beryl Master Server to be handed over to applications for processing.

Beryllium uses SSL or OpenSSH for establishing encrypted sessions. Should the message interchange take place within an organization, Beryllium provides an option for session encryption to be turned off.

Beryllium does not impose any file formats or size limitations; instead it works within the limits exerted by the underlying operating systems.