Combing architectural differences

The architecture of the Internet is different from that of the public telephone network in the same way that the architecture of Internet applications can be quite different from that of like applications that run over telephony networks. Two examples of such applications come to mind: PBX-based telephony and electronic data interchange.

A traditional PBX consists of a small number of interconnected core systems, only one of which local telephones typically need to connect with. Placing a call involves making a connection from one phone to the PBX and sending a command (a series of digits to select the target of the call) to the PBX, which then connects to the target phone.

In a traditional EDI environment, one customer connects to a server at an EDI service provider, typically over a dial-up or dedicated line, and deposits a specially formatted message on the server addressed to another customer of the same EDI service provider. The message transfer is completed when the other company calls in, or initiates contact over a dedicated line.

Both of these examples involve a user connecting to a core server which then controls the transaction with a second user. This model is considerably different from that used by most Internet-based applications, which tend to be peer-to-peer.

When sending e-mail using the traditional Internet model, an e-mail client on my local computer connects to an e-mail server on the target machine to transfer the message. This model has been augmented somewhat by the addition of local post office protocol servers at many locations, but even so, the network does not need dedicated servers that act as exchange points. The communication is end-to-end rather than end-to-middle and then middle-to-end.

Both PBX and EDI services are now moving to the Internet and vendors are proposing two very different strategies for offering such services. One strategy is to just replace the dial-up and dedicated lines with Internet connections.

In this model all of the communication still goes through a core server. In the case

of a PBX-oriented telephony service, this means that Internet-enabled phones would connect to a PBX server in the local network and request a connection through the server to a target Internet phone.

But there is no requirement to do this over the Internet. An Internet-enabled phone could connect directly to another Internet phone over the 'Net. The only infrastructure components needed besides the network itself are some simple name resolution services.

In some cases, such as with EDI, the central server can perform auditing functions. But even here, if the correspondents trusted each other, no core server would be needed.

I expect to see Internet-oriented PBX telephony and EDI offerings based on central-server and peer-to-peer architectures. But I anticipate that the peer-to-peer model will, like the distributed architecture of the Internet itself, be the successful long-term model. Those who think they are going to make money running or building core servers for these functions will have a hard time because these people do not understand the 'Net's underlying architecture.

Disclaimer: As an aggressively decentralized institution Harvard rarely encounters the problems of centralized services, but in any case, the above observations are my own.

Bradner is a consultant with Harvard University's University Information Systems. He can be reached at sob@harvard.edu.