Web-Services Networks

A Preliminary Report

[As of December 2009 all three of the companies mentioned below have disappeared, as far as I can tell. Grand Central just died. Flamenco Networks was acquired by Digital Evolution. (And what happened to them?) Talking Blocks was acquired by H.P. I've kept this essay on line to retain that perspective.
    -- 7 December 2009]

I began my research into web-services networks (WSNs) wondering why anyone would need one. Aren't they just like EDI value-added networks (VANs), and aren't web services supposed to make VANs unnecessary?

In fact, if you're not implementing commercial-grade web services that require, for instance, guaranteed once-and-only-once delivery, management services or third-party auditing or non-repudiation, then you don't need a WSN. However, if you're trying to build web services to automate real-world inter-company business processes, one of the three vendors described below can probably save you time or money.

Grand Central Communications (GC) operates a WSN that looks like a traditional VAN except that it's based on the Internet rather than on dedicated lines. In GC's model, you create your web services using existing tools, but rather than send messages directly between consumers and producers, everything passes through GC's hub. Within that hub, GC can perform a variety of transport-, session- and presentation-layer transformations and resolve incompatibilities. For instance, a producer and consumer may use different authentication or encryption schemes, or one party may use SOAP over HTTP while the other might send and receive using SMTP or even FTP. GC's hub is based on IBM's MQ Series software, thereby providing QoS (reliable delivery), non-repudiation and other management features.

GC's primary advantages are its transformations. Its disadvantages are the requirement that all parties use the GC network in order to communicate, and that the hub/spoke model reduces reliability and increases latency. To counter the latter disadvantages, GC points out (rightly so) that reliability risks are partially mitigated by the addition of message queuing, and that network latency isn't an issue for the asynchronous web services typically deployed over a WSN. It is yet to be seen what scalability challenges GC may encounter due to its centralized architecture.

Flamenco Networks takes a different approach. All parties using the FN network install a proprietary software web-services proxy software that runs on any Java VM, dedicated or shared with other functions such as on an HTTP server. The producer's and consumer's proxies communicate directly with one another over the public Internet, not through a hub, but similar to a VPN. The traffic is compressed, encrypted and the proxies provide message queuing. Additionally, there's a management server that handles authentication, non-repudiation and management of the proxy servers. You can either license the management server or outsource this functionality to FN.

A WSN built using web-services proxies is transparent to the end points, so no FN-specific development is required. Installation of the proxy software is simple, and all configurations can be done via a web browser. FN doesn't provide any of the transformations offered by GC's hub, but FN's end-to-end encryption is more secure since data is never decrypted outside the producer's and consumers's firewalls. A FN WSN can only be used to link to other partners that use identical proxy software.

Talking Blocks delivers the software you need to build your own commercial-grade web services based on the public Internet. TB isn't a WSN (and probably belongs in a separate report), but it provides an alternative to using a WSN. (Actually, one could benefit from using the TB's software and a WSN.) TB's software creates wrappers that expose existing systems (with CORBA or RMI interfaces, for instance) as web services. Put another way, TB's software creates a service-oriented architecture (SOA) from one that is object oriented. If it sounds like this is nothing more than what you'd get from the app-server vendors (IBM, BEA, HP, etc.), that's not the case. TB's software supports the higher-level features such as encryption, message queuing and web-services management that are functionally similar to those from GC or FN.

TB is the only one of these three solutions that reduces the cost of developing web services based on legacy applications, and the only one that provides a solution that supports partners (producers or consumers) who are not running the same system. On the other hand, because TB doesn't operate its own hub, it doesn't provide third-party (independent) management services such as auditing and monitoring.

Note that none of these vendors are involved at the application layer. They don't deal with business semantics such as orders or invoices. You still need to look elsewhere for those standards and solutions. So, in a sense, they're not like VANs. Furthermore, none of them address the requirements for transactions using either two-phase commit (ACID) or based on compensating transactions. Until a protocol such as BTP, (the Business Transaction Procotol) is adopted and implemented, transactions must be managed within the applications.

In a nutshell, TB provides the most help in exposing legacy applications and in communicating with partners who aren't using the same solution. FN is the simplest to deploy when the partners have already implemented standardized and compatible web services. GC is somewhere in between, since it requires that all parties use its network, but it provides transformation between disparate protocols in exchange for increased complexity.

Doug Kaye, 7 April 2002
Updated 8 April 2002