Beryllium is clearly not the first solution to offer automated passing of messages. A handful of solutions are based on open standards, namely XML over HTTP, FTP and SMTP that can be used, with considerable additional effort, to pass messages among computing environments across public networks.
The following table shows that Beryl overcomes shortcomings of rest of the open transport protocols.
| 8-bit |
Latency |
Overhead |
Decoupling |
Session encryption |
Endpoint status |
Streams |
Public key authentication |
Event driven |
Peer-to-peer |
|
| http |
N |
low |
high |
n |
y |
n |
n |
y |
y |
n |
| ftp* |
y* |
med |
low |
n |
n* |
n |
n |
n |
n |
n |
| smtp |
N |
high |
high |
y |
n |
n |
n |
n |
y* |
y |
| beryl |
Y |
v. low |
low |
y |
y |
y |
y* |
y |
y |
y |
* Please refer to explanations at the end of this paper.
Table 1. Data interchange protocol comparison.
The combination of XML over HTTP resulting in Simple Object Access Protocol (SOAP) requires significant customization before it can be deployed into a production environment. Additionally, there is considerable processing and bandwidth overhead in the use of SOAP technology. HTTP-based mechanisms, as RFC3117 clearly points out their collective flaws -- HTTP was never designed to be a peer-to-peer protocol, which forces applications into a client-server model; and for those applications requiring bi-directional message passing, both parties must implement both clients and servers and two connections are required. SOAP and a host of modern technologies suffer being forced to sit on top of HTTP. FTP does not generally provide session encryption; it has been around for a long time without any improvements; it has complicated in that it uses multiple negotiated ports; there is no standard mechanism for automatically processing files. Most implementations of FTP also suffer from high latency issues. SMTP, a store-and-forward protocol also has significant processing and bandwidth overhead. Most implementations impose arbitrary file size limitations as well as suffer from high latency problems.
EDI is not a transport protocol; it is a standard pertaining to format of commercial documents. Clearly, EDI is restricted to only certain kind of purely commercial communications and other specific applications; it is antiquated and provides practical value only when expensive proprietary transport mechanisms are utilized, including VANs over private communications networks or over VPNs. In fact Beryllium can be used to securely transfer EDI/XML messages in a peer-to-peer manner, without having to employ a VAN.
There are also a limited number of commercial products that are not based on open standards. The leader among these products has serious limitations in file sizes in most of its implementations and is primarily designed for internal networks. All of the commercial products are very expensive and require significant resources to implement.
On the other hand Beryllium will be based on open standards and will be available without licensing costs or restrictions.
Due to its open and standards based architecture, Beryllium will be considerably easier to implement.