Tangled in the Threads

Jon Udell, November 1, 2000

Are servers obselete?

Reactions to a proposal for a global e-commerce filesystem

Just because you can eliminate server-based control doesn't mean you always should. P2P is really about maximum choice.

Last week Todd Boyle, who is an accountant deeply interested in how the Internet can empower small businesses, posted this proposal to my newsgroup under the provocative title "Servers are obselete":

Webservers, mail servers, and RDBMS-based business systems and ecommerce are obsolete on grounds of cost, complexity, performance and security. They can be replaced by a pure, flat, public filespace where participants post XML messages and transactions that are encrypted, but publicly visible. Key points:

  • Users control all access by controlling encryption keys.

  • No system or database administrator.

  • No unencrypted data on the server to steal.

The need for transactions that span company boundaries breaks server-based control of security. Within the global filesystem, pure information would be stored, in standard XML vocabularies. A user could select a new best-of-breed provider for various business services by simply providing indexes and encryption keys he controls, without begging permissions and paying fees for additional logins to complex, centralized hosts and banks.

If today's networks and storages were available 30 years ago, SMTP, POP3, and HTTP would never have been invented. If today's XML standards had existed, SQL RDBMSs would have never happened, in their present forms. Certainly, their markets would have been much smaller.

Hub-and-spoke transaction architectures with human-supervised security are a cultural artifact. If you trust the individual and the free marketplace, you would build a common filespace with intelligent nodes and a common vocabulary.

I'm tapping my fingers impatiently for a wide-open free architecture where we can send and receive orders, invoices and payments directly to each other, for free. Point-to-point, and free.

This proposal was, Todd noted, a trial balloon floated in order to attract potshots. BYTE newsgroup participants aren't shy, and they were happy to oblige.

Alan Shutko:

This is like saying that cars, trains, and planes are obsolete because you could replace them with walking, well-programmed robots.

First, where is this filespace now? Does it just float in the air, or is it run on servers of any sort? If it's run on peer-to-peer servers, how do you find things and how do you avoid the scaling problems that Gnutella is facing? What _kind_ of XML messages will be passed, and what DTDs will you be using for what tasks? What kind of namespace will you use on your flat, public filespace, and why will it be immune to problems in namespaces we see today?

Laurent Szyster:

Achieving "total interoperability" for business applications will require universal interfaces. Who's going to design them? How? With what money? And what tools will be used to do implementation?

Have a look at previous attempt to deliver "universal interfaces". See EDIFACT or X12 directories (the EDI equivalent of XML namespaces). With what result? Byzantine specifications, expensive implementation with proprietary tools and restricted interoperability.

That's exactly the path all the XML attempts are going down now. If you want evidences, subscribe to the ebXML mailing lists or try to install and use Microsoft BizTalk.

Bjørn Borud:

Picture a simple database consisting of a few tables. The tables are scattered across a network. Imagine that you are now going to perform a query that will require you to perform a join on 3 different tables -- each table on a different node. It is easy enough to imagine how this can be tricky to do efficiently. Now imagine that you want referential integrity and transactions as well. Suddenly your problem became an order of a magnitude harder -- and it wasn't trivial to begin with.

My point is that some problems are not easily distributable and require some form of centralized processing. RDBMSes would have appeared no matter if the Internet had been available to the masses 30 years ago -- not because they are particularly clever, but because of the nature of the problem they are often used to solve. 

| Todd:
|
| Security alone is a sufficient reason to reject *every architecture* 
| containing unencrypted data or user permissions on central servers,
| outside of private LANs.

This sounds a bit like Bruce Schneier a few years ago, when he believed that public key cryptosystems would solve everything. Now, a few years later, he has changed his mind because he has realized exactly how hard it was to realize his perfect world. :-)

What if someone posts a list of all your secret keys in cleartext? *Kaboom* all the information you ever posted is suddenly available to everyone and you can never rectify it. 

| Todd:
|
| Imagine if Exodus or other ASP provided a new, global file service. It 
| could be open to the whole wide world, or members only. It could be 
| a cluster of anonymous P2P filesystems (Freenet, Publius, or Mojonation) 
| or a more traditional SAN or other file space.  I do not underestimate
| the technical challenges of this-- but I assume they are manageable.

Assuming is dangerous. Very dangerous. If my professional career has taught me anything it is that even problems that look simple at first can be hard or even impossible to solve. Never ever assume that a problem is manageable before you have analyzed it and know of a working solution. Innocent-looking problems can turn out to be monsters. 

| Todd:
|
| Let anybody in the universe create files or directories. Make the 
| service writable but then read-only, and all files globally visible. 
| The ASP might limit sizes, charge for uploads, or expire all content 
| over 90 days, etc.  The best solution requires users to specify file 
| expiration date upon each upload, and charges micropayments accordingly.
| The micropayments entries are an application in the filespace.

How does this differ from HTTP with WebDAV and a huge headache about how to ensure uniformity and how to manage access control? For some problems it is hard to eliminate centralized processing of locally stored information and replace it with completely distributed information that will be managed by a series of "agents".

Mark Wilcox:

Even if we can come up with some way to share information on a massive scale via P2P or some similar technology, this won't replace our existing technologies. Newspapers, books and magazines are still with us, even flourishing because of the Internet.

Peter Hess:

Key management is a huge obstacle to creating secure systems like you propose. In a large P2P network, I assume that every source of transactions needs a key for each transaction sink it deals with. The number of keys for any particular source grows linearly with the number of sinks that source deals with.

Public key protocols which are used in SSL and PGP for key exchange certainly work well, but as has been debated in this group before, getting people to use them is another matter.

Centralization and decentralization: yin and yang

Everyone who responded to Todd made good points, with which I agree. There are lots of problems with the notion of a global P2P network and, arising from it, a primordial soup of XML objects in which online business can flourish. There are also, however, good reasons to reassess the ways in which we should, and shouldn't, continue to rely on central-server-based architectures.

Let's try a thought experiment. Suppose we have reasonably standard ways to represent business objects such as orders, invoices, payments. And suppose these representations take the form of XML. I'm a small business, and so are you. I want to order something from you, so I use my business software to send an order object to your business software. Consider two scenarios:

It's tempting to characterize the first scenario as being "point-to-point, and free," and the second as being subject to the control of, and taxation by, a central authority. But the first scenario isn't really free. We have to acquire, install on our PCs, and maintain the business logic that enables us to perform this transaction without a mediator. That's what we do now, with QuickBooks and the like, albeit non-electronically. A P2P-enabled QuickBooks won't be any freer than regular QuickBooks is today. It will, though, enable the kind of spontaneity that we enjoy today. If I do some work for you and then invoice you for it, I don't have to join the business hub you subscribe to, or ask you to join the business hub I subscribe to, we just communicate directly (albeit inefficiently). There's a lot to be said for letting my QuickBooks talk directly to your QuickBooks. And by extension, for enabling us to spontaneously invite other parties (accountants, the government) into this QuickBooks-oriented conversation, without having to ask an administrator to grant permissions and manage access. Last week I wrote about Groove. Its administratorless, secure, by-invitation-only shared spaces could potentially be used for the kinds of spontaneous small-business-to-small-business interactions that Todd envisions.

Now let's consider the second scenario. There are good reasons why we might want to locate some of our data out in the cloud: anywhere/anytime access, redundant storage. As Todd notes, we should expect to pay something for these storage and access services. There are also good reasons why we might want to locate some of our business logic out in the cloud. The Internet tax holiday, for example, won't last forever. Once we're forced to charge sales tax for e-commerce, the rules are going to be complex and fluid. Sure, I can frequently update my P2P-enabled QuickBooks to stay current, but why should I have to? Knowing that my business software uses canonical business logic, resident in the cloud and not needing to replicate to my PC, saves me time and worry and is another of those services I'd be willing to pay something for.

Ultimately, to the extent that I regard storage and processing that lives out in the cloud as an extension of storage and processing that lives down here on my PC, there is not any hard distinction between the two scenarios. Nor should there be. Some storage and some processing wants to be local -- for reasons of performance, offline access, or just because it doesn't need to be anywhere else. Part of the P2P movement, after all, is about recognizing, as Clay Shirky has so eloquently said, "The PC is more than just a life support system for the browser." But some storage and some processing wants to live in the cloud -- for reasons of universal access, guaranteed consistency, redundancy, or just because even though I could manage these things myself, I'd rather pay somebody else to take care of them.

What P2P means, to me, is maximum choice. Just because my PC can behave like a server doesn't mean it has to. Just because I can use storage in the cloud doesn't mean I have to. These are options that extend my range of choice.

I'd welcome a P2P-enabled QuickBooks that enables me to deal directly with my clients, eliminating paperwork and delay. Of course, my clients run much larger businesses than mine. It's never QuickBooks that I'm dealing with on the other end, it's a weightier -- and sometimes homegrown -- accounting system. Some of these, in the coming years, will evolve XML interfaces to existing storage and processing. Others will present the same XML interfaces, while migrating storage and processing to the cloud. Neither model will, typically, occur in its pure form, because every business runs a complicated mix of legacy systems that are evolving on different schedules. What matters, finally, is that we get the interfaces right. And on that point, Andrew Ducker is more optimistic than Laurent Szyster:

Andrew Ducker:

Our latest system has three basic interfaces, Web, COM and SOAP. The COM and SOAP interfaces are both XML-based, and anyone who wants to access our data simply has to read the specification (which is very simple) and send us info in the format we specify.

Should another specification arise we can either use XSL to do a transform (or our clients can do the same) or we can simply add another set of calls to produce it in a different format.

So long as interfaces are kept open, anyone can write to any specification they like. Over time, specifications will accrete users until one becomes the defacto standard.

How easy was it to write to EDIFACT or X12? I knocked up a simple XML converter in three days and can reconfigure it to another standard in the same or less time. Debugging is incredibly simple because (a) it's all human readable and (b) IE5 displays XML and tells me where any errors are.

The great thing about XML is it's _really_ easy to work with.

Andrew went on to cite, as evidence that XML does work, an article on HR-XML, a new standard that a bevy of job-posting and recruiting services have agreed to. XML may or may not emerge as a dominant storage technology, but XML as a dominant interface technology has arrived.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

Creative Commons License
This work is licensed under a Creative Commons License.