Flow of messages, within the Beryllium s decoupled framework, facilitates disparate applications to interchange information securely. Applications intending to transfer messages to a remote system place them in designated system directories at a local Beryllium system, called the Master Server or deliver the message, through APIs, directly to a process on the Master Server. The actual transfer of messages can be routed to its destination by one of two methods.
Destination Specific Repository
An message is deposited in a destination specific system directory that has a predetermined priority associated with it.A Beryllium process monitoring the system directory, optionally encrypts one or more messages for transfer from Beryl Master Server to the Beryl Slave server on the other side of the corporate security perimeter. Communications between the Master Server and Slave Server are authenticated prior to any message transfer. Once the message arrives at the Slave server, they are stored in a system directory pre-configured for a specific destination. Another Beryllium process on the Slave Server establishes a secure session with a pre-configured destination s Slave Server for the transfer of the message. A secure session can be used for transfer of a single or multiple messages or streams.
In this mode of interchange, the message is prepended with a header containing routing and priority request information by the applications server and deposited into a general-purpose system directory on the Master Server at the originating site. All such messages are transferred to the Slave Server through an authenticated session.A Beryllium process at the originating Slave Server reads the envelope information and, after optionally stripping the routing header, places the message for transfer into an appropriate queue. Multiple queues may be configured to prioritize the transfer of messages. The routing envelope may be left intact as a file header to support multiple applications servers at the destination. Once messages arrive at the destination Slave Server a Beryllium monitoring process on the Master Server triggers their transfer by pulling them inside through the corporate security perimeter. This pull of messages from the Slave Server to the Master Server is also subject to an authentication mechanism to ensure the validity of participation in the interchange. Finally, the messages are made available to applications server(s) at the destination.To maintain the integrity of messages, acknowledgements are sent back to the originating Beryllium servers with checksum/signature information for comparison. In the event the acknowledged checksum/signature does not match with the pre-transfer derived checksum/signature the message or part thereof, is retransmitted for a pre-defined number of times. Upon reaching a retransmission threshold messages may be flagged and an alert is sent to an administrator for further investigation.