9703-web-apps-essay.html
8.37 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
<HTML>
<HEAD>
<TITLE>From the Editor -- Web Apps, Issue 2 Mar/Apr 1997</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<P>
<EM>This is a draft of the editorial of the Mar/Apr 1997 issue of
<CITE>Web Apps Magazine</CITE>, ISSN #1090-2287. See also:
<A HREF="9701webapps.html">Jan/Feb 1997 Languages Issue</A>
<A HREF="9705web-apps-db.html">May/Jun 1997 Databases Issue</A> editorials,
<A HREF="WebApps/Overview.html">more about WebApps</A>.</EM>
<ADDRESS>
<A href="./">Dan Connolly</A><BR>
Austin, TX<BR>
Created Thu Feb 13 08:52:55 CST
</ADDRESS>
<P>
<HR>
<P>
I must take this opportunity to dispell a myth that is all to pervasive in
the scientific and product literature surrounding the Web: that distributed
objects are something that can be, or some day will be, <EM>added to</EM>
the Web. Distributed objects are the very heart of the Web, and have been
since its invention.
<P>
HTTP was design as a distributed realization of the Objective C (originally
Smalltalk) message passing infrastructure: the first few bytes of every HTTP
message are a method name: <TT>GET</TT> or <TT>POST</TT>. <I>Uniform Resource
Locator</I> is just the result of squeezing the term <I>object reference</I>
through the IETF standardization process.
<P>
The notion that some web resources are 'static' while others are 'dynamic'
or 'computed on the fly' is an unfortunately limited understanding of the
system, based on the very common experience of studying the CERN and NCSA
httpd implementations. The distinction between 'static' and 'dynamic' web
pages is not in any of the HTTP, HTML, or URL specifications at all. By
definition, all web resources are opaque objects that respond to a
<TT>GET</TT> method.
<P>
So much for the notion that the time when the Web becomes a distributed object
system has not come yet...
<P>
Don't get me wrong: I won't pretend that the Web is a highly advanced distributed
object system. Quite the contrary: it's the minimum amount of distributed
object technology necessary to get the job done.
<P>
Well... some jobs anyway.
<P>
The Web we see today is a tribute to the power of opaque objects: some resources
are implemented by simple file servers, some by perl scripts, some by expert
systems, some by three-tiered database systems, and for all I know, some
by COBOL programs. And some of them are powered by advanced object technology
applications. The power is that the same clients interoperate with them all
through the same simple interface consisting of <TT>GET</TT> and
<TT>POST</TT>.
<P>
But are there some jobs that just can't be done through that interface? More
to the point, are there some jobs that are so impeded by this simple object
technology that they aren't feasible, whereas they would be feasible with
a bit more advance object technology integrated into the Web?
<P>
The lowest-common-denominator is so low that a lot of time and energy is
spent dumbing down the service interface of systems to this level; meanwhile,
even more energy is spent injecting smarts back into the interface on the
client side. It would seem much more cheap and efficient to conduct the
communication at a higher level.
<P>
But how often does the server's notion of "higher level" coincide with the
client's notion of "higher level"? Clearly there is a wide variety of higher
level interfaces, and we need some sort of interface discovery and negotiation.
What language should we express these interfaces in? Or should we pass them
by reference, with an option to dereference the interface identifier, ala
some sort of interface repository?
<P>
What are the odds that the client and the server share any richer interface
than HTTP and forms? For parties with a manually established relationship,
the odds are quite high. But such situations don't call for any new
infrastructure -- just creative applications design. In order for dynamic
interface discovery and negotiation to be useful, we need to see a marketplace
of interfaces, from commonly used interfaces and frameworks to highly specialized
but widely known interfaces.
<P>
The fascinating question that comes to mind is: does this commerce in rich
interface have an overall positive or negative impact on the robustness of
the system? As the richness of an interface increases, so does its complexity,
and down go the odds that the two parties have implemented the subtleties
in a compatible way. And I haven't even raised the specter of lifecycle issues.
The Web is in continuous operation after all: the old clients and servers
never completely go away; any deployment is a commitment to essentially eternal
backwards compatibility.
<P>
What fascinates me is the tension between classical and chaotic systems.
Object technology reminds me of classical mathematics: complexity management
by the use of formal systems built from primitives axioms (ala an object
system), with inference rules structured on top (ala classes). The whole
thing is very left-brain and anal. Very much my style, I have to admit.
<P>
But it's also very fagile: one goof, and suddenly you've got both P=true
and P=false and the whole thing comes crumbling down. A distributed object
system is subject to the same sort of catastrophic failure, if parties blindly
assume that other parties adhere strictly to the stated interfaces and protocols.
Fault tolerance is essential to robustness.
<P>
OK, so that's no great revelation: we all know that there is no such thing
as a free lunch, and that distribution doesn't come for free.
<P>
But richer interfaces only compound the cost of fault tolerance. For each
interface, the possible failures have to be enumerated (usually through painful
experience) and addressed. The HTTP interface is shared by the whole community,
and that community shares the burden of building this knowledge about fault
tolerance. The cost of developing this knowledge seems like a damper on the
marketplace of interfaces.
<P>
Achieving fault tolerance takes much longer than achieving plain correctness
with respect to the interface specification -- I routinely hear reports of
two or three three times as much, and even ten times is not terribly rare.
So one step forward in complexity management from richer interface description
is two, three, or ten steps backward in total development cost.
<P>
It's no wonder that a lot of developers choose the quick-and-dirty, organic,
chaotic approach to applications development. They simply accept the complexity
of distributed applications development as a fact and deal with it as a craftsman
or artist, feeling their way around. Given the rapid pace of change in the
Web, they shy away from development tools and methodologies, expecting the
next application to be sufficiently different that the investment will not
pay off.
<P>
But what will be the trend as distributed objects go global, as developers
can collaborate from across the planet almost as easily as across the hall,
echanging software components without even echanging names, and as applications
have the total resources of the network at their disposal?
<P>
The whole Web is clearly a chaotic system -- predicting its behaviour is
more like predicting the weather than predicting the path of a bullet. But
the benefits of classical complexity management in the small, i.e. the use
of object technology within applications and within software development
organizations, is beyond doubt.
<P>
It seems to me that the part of the world that's changing too fast for object
technology and tools to help is the small fraction of the 80/20 rule. The
bulk of most applications is not novel, and while rich interface description
may be costly to develop initially, reuse justifies the cost.
<P>
The Web is an information system designed to help people exchange information,
which means that it is designed to model the real world of ideas, communication,
relationships, and social systems. The real world seems to be a system composed
of objects with well-defined boundaries: cells with cell walls, organisms,
families, companies, and nations. The economies of scale in this system clearly
rely on well-defined interfaces: social norms between people in families,
policies in companies, laws in nations.
<P>
If this analogy is at all useful for charting the evolution of the Web, I
see a lot of unexploited territory in the application of object technology
to the Web. It seems the Web is still in a primitive state of formation:
loose bands of individuals hunting and gathering. I look forward to great
nations in this new medium.
</BODY></HTML>