Heinemann, Marty Humphrey, William G. Griswold, David. Notkin and his students, John Knight and, especially,. Michael Gorlick and the anonymous conference ...
A Web-Oriented Architectural Aspect for the Emerging Computational Tapestry Kevin Sullivan Department of Computer Science Thornton Hall University of Virginia Charlottesville VA 22903 USA.
Avneesh Saxena Department of Computer Science Thornton Hall University of Virginia, CharlottesviUe VA 22903, USA.
Tel: +1 (804) 982 2206, FAX: +1(804) 982 2214
Tel: +1 (804) 982 2048, FAX: +1 (804) 982 2214
sulli van @ virginia.ed u
avneesh @cs.virg.inia.edu
Abstract
become outdated snapshots. Second, the constituent computations, interconnections, and defining software will not be under central control, Rather, they will be designed, instantiated, integrated, updated and abandoned by many different enterprises, each trying to maximize its own utility, sometimes at the expense of others. The explosion in the number, variety, coupling and evolution of embedded computations will not abate unless societal conditions change dramatically. The problem that we address in this paper is that we lack even rudimentary mechanisms to maintain control in such an environment. In this paper we investigate one possible solution approach. The designer of such an approach has to respect several constraints and realities. First, there is no silver bullet. No solution can apply across the range of systems that will be built. Second, the ability to access and manipulate a wide variety of computations with one mechanism requires the computations to follow shared architectural design rules. The design of such rules is itself a challenge [14]. If the cost of conforming to certain rules is high, or if the rules are incompatible with other key design choices, designers will opt out. One way to reduce the cost and to increase the value of such a new design is to leverage existing infrastructure. Another way is to minimize the imposition on designers. Yet, light-weight design rules cannot provide strong guarantees. One way to mitigate this conflict is to organize rules in layers, with conformance to lower layers providing minimal guarantees to broad constituencies and additional layers providing stronger guarantees to narrower groups [14]. We propose and investigate one such foundation and some extensions and variants. Our chief functional goal is to make distributed systems of independently developed objects accessible to automated discovery, monitoring and control: of object existence, meta-data, state, behavior, and design parameter bindings.
A n emerging tapestry of computations will soon integrate
systems around the globe. It will evolve without central control. Its complexity will be vast. We need new ideas, tools and methods to help map, understand and manage this tapestry. We contribute a light-weight architectural aspect that designers can use without compromising their own architectural preferences. Widespread use could help. The idea is for objects to provide web-based integaces to object-specijic meta-data, state, and monitoring and control services. We discuss applications, implementation, scalability, pegormanee, tradeoffs, and related work.
Keywords Noosphere, architectural aspect, web interface, software
1
TheProblem
Enabled by the sustained exponential growth in the performance of processors and communications networks, networks of computations are rapidly infiltrating and integrating our technological systems. Maintaining intellectual and technical control over these networks is critical, but attempts will meet with enormous complexity. Legions of stand-alone systems, each itself complex enough to defy human comprehension and control, are now being coupled, vastly multiplying states and interactions. The ensuing tapestries of computation will also evolve rapidly. Complexity will grow in both space and time. Several factors will complicate attempts to maintain control. First, what matters most are the computations that are actually running our systems; but, unless steps are taken, they are invisible. As such, they escape our view and our grasp. Design documents, while helpful, quickly
2
An Architectural Approach We propose an approach to meeting these goals based
on one simple design rule: Each conforming runtime object must support a web-based interface identified by a Universal Resource Locator (URL) through which a web-based service for accessing that object is provided.
485 0-7695-1050-7/01 $10.00 0 2001 EEE
Extending this model with one additional design rule yields
3.2
an object-oriented architectural aspect that appears well matched to modern design practices: Each conforming runtime object must support an operation for obtaining the corresponding URL for that object.
Having objects provide meta-data and runtime state to clients is straightforward. The implementation is not novel. We encode requests for meta-data from a given object as an extension of the object’s URL. The receiving web server delivers the URL to a handler routine of the targeted object based on the HTTP request received. The object decodes the request, and encodes the requested information in a response that the server then returns to the client. We have encoded replies in HTML and XML. The choice of encoding is limited mainly by the set of protocols that clients can be expected to support. We have used this strategy to deliver several kinds of data, including runtime instance variable values, source code, and interface definitions. We used Java’s introspection APIs to return accurate interface definitions. We have also defined services that permit clients to change the values of object instance variables and to invoke member functions. Of course, in practice, such services would have to be supported, exposed and used judiciously.
In the abstract, our architecture comprises three realms: Object, URL, and Webservice; and two functions: a partial injection, GetURL, from Object to URL, and a partial function, Getservice, from URL to Webservice. An Object conforms to our rules if it is in the domain of GefURL(has a unique URL) and its image (its URL) is in the domain of Getservice (there is a service implemented at the URL): that is, if the object is in the domain of the composition of GetURL and Getservice. Our model makes URLr unique, but it allows multiple URLs to map to the same service. Many kinds of real-world objects can be mapped to our Objects: object-oriented class instances, COM, CORBA or Java Beans components, etc. Small objects having one-bit states to complex objects providing rich web services can expose web interfaces. In practice, pragmatic concerns will constrain the objects that can employ our approach profitably. We discuss scalability issues in Section 5.2. In the rest of this paper we develop and evaluate our basic architectural idea. Several questions come to mind immediately. Can it be implemented efficiently and what tradeoffs are involved? Does the approach scale well, e.g., as the number of web-enabled objects grows? Does it promise to help to address the need to manage future systems of rapidly increasing complexity? Is it useful?
3
3.3
Object-SpecificSecurity Policies
We used HTTP to provide unrestricted access to objects. In practice, administrators will often have to impose access controls. We have used HTTPS and public-key methods to support object-specific access control. We developed a simple application in which clients are authenticated and requests denied if the right credentials are not presented. With credentials, a client has to log in, and access to the object’s web services is based on an access control list. For these prototype applications, we used a commercial server implementation.
Potential utility
The most important question is whether the approach is useful. In this section, we briefly describe infrastructure support for exploring and evaluating our approach, and a number of applications that we have demonstrated using it. Our applications appear to support the claim that the approach has the potential to be useful relative to our goal.
3.1
Accessing Object Meta-Data and Runtime State
3.4
Monitoring and Control of Object Behaviors
Visibility to object state can be useful, but monitoring of ongoing behavior will be even more important in some cases. We have demonstrated a monitoring capability based on Java applets. An object can provide an applet to a client for this purpose. Such an applet registers through the web interface of the object that supplied it for event notifications. The applet updates its state in response to notifications. We have also used this approach to control objects. An object supplies an interactive applet that sends client commands back to the object for execution. We have implemented this approach for a simple system using authenticated and cryptographically secure communication throughout.
Prototype Supporting Infrastructure
To explore and evaluate our idea, we designed a Javabased instance of our architecture. Java class instances are our Objects. Each implements an interface supporting a method GetURL(). Object-specific services are available at each such URL. Services are brokered by web server implementations. We implemented several designs to assess performance and scalability. The designs vary in the placement of servers relative to objects, how objects interact with their servers, and the threading models used. Each object handles all web-based (e.g., HTTP) requests sent to its URL. In our particular implementation, each object does this by implementing an interface that its server uses to invoke handler methods for supported request types.
3.5
Control of Object ImplementationStrategies
Any service that can be provided by a web connection can be supported within our architecture. The burden falls on the object designer to decide what services to provide. For example, we demonstrated the ability to support an open implementation [7] capability, permitting web clients
486
on a particular port or allow the server to find an available port. A server instance can also support the web interfaces of multiple objects on the same port, assigning unique URLs to objects at registration time, and storing the URLobject associations for subsequent lookups. Several design parameters influence the performance, cost, scalability, and function of web servers in our model. In our initial work, we have explored two: multi-threading and the organization of servers relative to the objects whose web interfaces are served. The design of our server allowed us to explore this space quite easily.
to dynamically change object implementations. This capability could support dynamic reconfiguration of systems in response to faults or changes in load or versions. Each of the capabilities described so far permits webbased clients to access and control individual objects using standard Internet protocols. An especially interesting application of our idea is to support discovery and mapping of objects in distributed systems. A system is organized as a network of objects each holding links to other objects. Objects can be object-oriented type instances, processes, etc. Links are inter-object references. We need to be able to discover and traverse such topologies. A simple extension of our architecture can support this requirement. We add a new design rule: Each conforming object in the extended architecture must provide a webbased service that lists the URLs of (Le., hyperlinks to) all of and only the conforming objects that it references. What follows from adherence to this design rule is that a system’s overall topology will be fully represented in a decentralized way as a network of hyperlinks. Details of actual interconnection mechanisms remain appropriately hidden behind the web interfaces. With this structure in place it becomes possible to use a web crawler to discover the actual topology of a running system, including both the existence of its objects and any additional information and control that the objects make available through their web interfaces. We have implemented this idea and have found it to work. Using a standard crawler produces a searchable index of objects and textual information exposed on the pages that they export. Such indices might be useful, for example, for finding all objects of a given type for updating in a system. One possible use of this technique is to map global state. State information encoded in XML or in richer forms has the potential to support useful global systems analyses, e.g., for intrusion detection and survivability control [15][16]. The approach can clearly scale to many components, as web crawlers are already used to index large numbers of sites. Of course, the approach also has fundamental limits. There are no quality-of-service guarantees on the Internet today and no way to map state or to commit updates with guaranteed consistency unless objects follow demanding additional design rules.
4
4.1
Multithreading
Multi-threading allows a server to handle requests to one or more objects concurrently. When an object registers with one of our servers, it chooses how H” requests will be handled: sequentially,using single-threaded handling, or concurrently, with either a thread-pool model or a threadper connection model. The number of threads per pool is configurable. Whenever a request is received for a URL corresponding to a given object, a thread is dispatched to the appropriate callback of that object. Multithreadedobjects generally define synchronized callback functions.
4.2
Server organization
We implemented three different designs, all supporting the same basic architectural aspect, to assess associated cost, performance and tradeoffs. Server per object: Each conforming object has its own Webserver as an instance variable. Each object thus consumes a network port on the host machine. That port number is then the distinguished aspect of the object’s URL. 0 Server per Process: Each process (in our case Java Virtual Machine) has a single server that supports the web interfaces of all conforming objects in the process. When objects register, the server assigris unique identifiers that distinguish their URLs. We used locally unique ids, created using a Java MI, appended to the host name to construct system wide unique ids. One alternative would be globally unique identifiers (GUIDS), as used in CORBA and DCOM. Server per type: Each type has a Webserver that supports the web interfaces of conforming objects of that type in a given process. There are other possible models that we did not explore. For example, one could use one server per system to support all conforming objects in the system, with serverobject communications based on remote procedure call. An interesting possibility given the need for an approach that permits independent vendors to make their own server design decisions is one server per vendor, to serve all objects of that vendor in a given system or part thereof (e.g., process).
A Design Space for Implementations
To help us to explore our approach and evaluate costs, performance, scalabilityand tradeoffs we designed a simple supporting web server in JDK1.2 on SunOS 5.6. A server is implemented as an object of type Webserver. The server can only handle H”P Get and Head requests. We used a commercial component to explore secure access. Our server routes HTTP requests to object-specific callback functions and delivers the results to clients. To use the server an object implements a callback interface for handling HTTP requests and registers itself with the server. An object can request its server to expose its web interface
487
5
to the worker threads. However, as expected the average queue length of pending requests was far higher with the no thread model. Increasing the request rate while keeping other things constant, for all architectures and threading models, resulted in very little change in the latencies. A more surprising result was that the average queue length didn't increase appreciably with the increase in the request rate. However, the error rate for connections did go up, which probably explains the relatively constant queue lengths. Latencies tended to increase with the number of objects. We do not yet have a solid explanation for this result. Paging is a possibility. A surprising and as yet unexplained observation was a rise in latencies and queue length at 300 objects and a fall at 500 objects. One would have expected latency and queue length to rise monotonically with the number of objects.
Cost, Scalability, and Design Tradeoffs
We have observed tradmffs in four dimensions: cost, scalability, function, and independence. In this section, we briefly characterize our data and draw some inferences.
5.1
Basic runtime costs
Runtime costs follow from the number and distribution
of web servers and clients in a system. Space requirements increase additively with the number of servers and objects registered, and with the sizes of the thread pools that the servers maintain for objects. With one server per process the amortized space cost per object was about 250 bytes, with 1000 objects. With one server per type and 10 types it was about 550 bytes per object. The cost for the server per object model was sensitive to the server configuration: 1800 bytes for the single-threaded model, and 6000, 15000 and 24000 bytes for multi-threaded servers with tread pools of size 1, 3 and 5, respectively. These figures are estimates based on overall process sizes. Server-object communication costs correspond to the communication mechanisms used and the functions that the objects actually implement. All of our designs used local procedure calls only. A server-per-machine or server-perdistributed-system or similar model would have to use remote calls. The bounds on client-server latency and throughput follow from the costs of using Java mechanisms to implement HTl'", load, network delays, callback execution time, concurrency and other factors. We measured latency using an automated ffITp request generator to create an exponentially distributed request load on web interfaces. Our objects were configured to return null responses to the requesting client. We carried out this experiment for each of the threading models: no threads, thread pool and thread-per-connection. We made observations for both intra-machine and inter-machine requests. Intra-machine experiments were carried out on a 360MHz UltraSPARC I1 system with 1548Mb RAM and 2G of swap. The machine was under a reasonable interactive service load. Inter-machine requests were carried out by running the request generator on a 167MHz UltraSPARC with 192Mb RAM and 2Gb of swap, with the objects on another machine having the same configuration, connected on a 100 Mb/sec local area network. Per access latencies were ranged from 50 to 65 ms for local accesses and from 150 to 270 ms for remote accesses. Inter-machine latencies were worse then intra-machine latencies in all cases, because of network delays. For the same architecture, latencies were higher for the thread-perconnection model than for the other models. We believe the result is due to the time needed to create and start threads. A surprising observation was that the no-thread model outperformed the thread-pool model. We attribute this to the small size of the web pages being served. In the thread-pool model, time is spent in handing off the request
5.2
Scalability
In terms of scalability, we saw several discontinuities. First, each server running on a machine consumes one of the machine's 216 network ports. Thus, in the server-perobject model, no more that 216 conforming objects can run on any given machine. However, we ran into the operating system's compile-time er process limit on file descriptors long before we hit 2' ports. Our Solaris configuration limited us to about 1000 file descriptors per process, which translated into about 500 servers. We still could have exhausted the available ports with a reasonable number of processes each at its file descriptor limit. The port and file descriptor limits are made nearly moot by the server-per process and server-per-type models, as long as on average there are many objects per process or type. We created over 100,000 conforming objects in a process with the server per process model, and about half that with the server per type model. The limiting factor was the default memory usage limit set by our Java Virtual Machine. We could'have raised that limit if necessary. These performance and scalability figures are rough. We plan more rigorous and extensive measurements in future work. For example, we took our measurements in quite abstract settings: objects implemented null HTTP interfaces, clients produced loads that might not be realistic, etc. Furthermore, our Java implementation is just one of many possible implementations of our architecture. Others will surely give different results. Nevertheless, the figures suggest that the approach is workable. They show, for example, that the server-perobject model can work for hundreds of objects per process and thousands per machine. It could be a reasonable choice for providing already large (multi-kilobyte) objects with web interfaces. The server per type and per process models can support many more modest-sized (kilobyte) objects per process, and almost certainly millions per machine. Finally, the approach can link millions of machines, as the current Internet amply demonstrates.
B
488
5.3
A Performance-IndependenceTradeoff
Table 1 Crawling times
One of our chief concerns is to enable independent designers to use our architecture without compromising their architectural preferences. No solution that requires all objects use a common server infrastructure can attain the level of adoption needed for discovery and management in a global, heterogeneous tapestry of computations. Yet, the shared server approach is the current state of the art. Examples include CGI, Servlets, Active Server Pages, Enterprise Java Beans. Not all of our own implementations are equally good in this dimension. In particular, the one that is best for space, a server per process, sacrifices independence entirely. This design is just a simplistic clone of state of the art systems. Conversely, the design that is worst for space, a server per object, is best for independence. Not only are all web server design decisions left to independent object designers, but each instance can make different choices. This design shows that designers can adopt our model without incurring other externally imposed design constraints. Unfortunately, the server per object model is costly and it does not scale well with the number of objects per process or machine. The server per type model largely resolves this dilemma. In Java, we implement this design by making a web server a static instance variable of a given type, One server is shared by all instances of a given type. The type designer thus makes all server design decisions but without paying the runtime cost for a server per object. The space cost is still linear in the number of objects, because the server keeps a record per object; but these records are typically smaller than servers. Furthermore, the ratio will improve as servers provide more function (such as HTTPS support). Another possibility is a server per vendor. Component designers make server design decisions, but with yet lower costs, since components of all types from that vendor share a server. There is a range of such intermediate forms.
5.4
.
I
Linear Topology
Tree Topology
1
O : ~ Omin
0:03 min
1024
3:02 min
1:13 min
5120
14:48 min
6:31 min
10240
28:30 min
15:49 min
#Of
Objects
50
At least on standard Solaris configurations, file descriptor limits will constrain the approach to hundreds of secure objects er process, and the network will limit it to no more than 2l per machine. Of course, small numbers of secure objects could easily be combined with large numbers of insecure objects on a given machine, the latter using space, file descriptors and port numbers efficiently.
r
Performance of Crawler-Based Mapping A final set of measurements gave us a sense of the rate
5.5
at which we can map distributed systems of interacting objects using a web crawler. We created systems of several different sizes and topologies distributed across three machines on our LAN. The objects were configured in either a temary tree or linear topology. In a tree, the children of a given node were placed on separate machines. Similarly, in the linear topology, the nth node ran on machine n mod 3. The objects interacted with their neighbors using Java remote method invocation (RMI). We measured performance using both server per object and -per type designs. Each object maintained a list of its neighbors and exposed this data as HTML hyperlinks. We used Inktomi’s (Ultraseek) [20] web crawler. Ultraseek can spider networks at configurable intervals starting at any URL. It builds a database of accessible URLs. We configured the crawler with 10 threads and an HTTP timeout interval of 15 seconds. We ran the crawler on a IGHz, 1Gb RAM,x86 AMD machine connected to the object-hosting machines by our LAN. Table 1 summarizes our data. The figures are in rninutes:seconds format. We could index no more than 250 objects in the server-per-object design because our evaluation web crawler was limited to visiting 250 server sites. A few observations are in order. First, the time required to index the web interface of a simple object was about 115 second. Of course this action is more involved than just visiting the object. The object has to generate and return an HTML-encoded representation of its neighbors, and the crawler has to index the returned links by the surrounding text. Therefore, second, mapping and indexing large systems takes time: almost half an hour to map a system of
A Security-PerformanceTradeoff
Given that the server per type and related models solve the independence versus cost conflict, is there ever a reason to employ a server per object approach? The answer is yes for reasons having to do with security. The problem occurs when clients require objects to authenticate themselves using HTTPS. The underlying SSL layer requires that a handshake occur between client and server for session key exchange and client authentication of the server before the client sends the desired URL to the server. It is not possible to combine per-object authentication over HTTPS with a shared server design that uses URLs to identify target objects. Using HTTPS, clients authenticate servers, not the services they provide. If clients demand authentication of individual objects-a natural and realistic possibility-then objects need their own HTTPS servers. We now have enough information to deduce the scalability of the HTTPS-secure version of our architecture.
489
is used for configuration, for example. However, such work has focused on web enabling single application programs, not on ubiquitously web-extending components. Gorlick’s Joist debugger [5] is closer to our work. Joist runs in an embedded Python language runtime and exposes Python objects using HTTP. Joist is close to mapping Python onto our approach in that it associates URLs with objects-almost following our first design rule. However, a Joist U l U actually resolves to a proxy that knows how to display and debug the target object, not to the object itself. It is useful to compare and contrast our two approaches. First, Joist is a real, industrial-strength debugger. It is not a goal of the present work to compete with Joist in this area. Second, a key contribution of Joist was a specific server system designed for the demanding resource limitations of an embedded computer. By contrast, our approach does not imply the use of any particular server technology. Gorlick’s server could be adapted to support our approach for objects running within embedded systems. Third, and perhaps most important, Joist is committed to its server design: a shared server-per-Python-runtimemodel with specific interfaces for object-server interaction. For the reasons we have discussed, it cannot be extended for HTTPS authenticated access to objects. Joist is more closely related to CGI, servlets, active server pages and such models than it is to our architecture. Like them, it cannot solve the problem we have identified.
10,000 objects. Greater concurrency would have helped. Nevertheless, it is clear that it makes sense to apply our approach only to relatively enduring objects. Third, performance depends on topology, because branching in creases concurrency.
6
Related Work
We now situate our work in the context of related efforts.
6.1
Component models for distributed systems
Our work is related to but not analogous to models of modularity for component-based software. Object-oriented programming languages and models such CORBA [12] and DCOM [ 191 are examples. We are not proposing another such model. Rather, our contribution is a new architectural aspect: a dimension of architecture orthogonal to and freely combinable with other models. This characteristic-that it can be used independent of other dominant architectural choices-is the key to its potential to improve our ability to manage heterogeneous, component-based systems.
6.2
Web-based network & service management
SNMP [3] is a widely used standard supporting the management of network elements. Web-based service [13] and network management [6][8] mechanisms provide webbased interfaces to services such as SNMP. To date, this approach has been limited to managing networks and specific services. There have been related efforts to develop analogous management information bases (MIB) for web servers, E-commerce services and other entities. By contrast, our approach is designed to support web access to arbitrary software components. Thus, unlike these approaches, ours does not make any assumptions about an underlying management infrastructure. It could, of course, be extended to use any mechanisms that do emerge.
6.3
6.5
SOAP and XML-RPC
SOAP [2] and XML-RPC [21] define message passing and
RPC mechanisms that use XML to encode messages. HTTP-based transport is an option. These mechanisms enable objects to expose services and communicate on the Internet. Such approaches really attempt to define new component object models or architectural styles. The styles are fundamentally object-oriented in nature but they use XML messages to encode messages and remote procedure calls. Our architectural aspect, by contrast, is orthogonal to the native architectural style that designers employ in their own systems. Ours is not a component model whose adoption is exclusive of other component models. Rather, it can be combined with other models, including SOAP-like models. This property of being an orthogonal architectural aspecr is what gives it the potential to be adopted across many styles.
Components embedded in web servers
CGI scripts [ll], servlets [18], dynamically loaded Apache modules [l] and ASP scripts [9] are essentially objects embedded inside web servers. Our approach inverts the traditional precedence relation between servers and objects, making objects dominant and servers subordinate. Our approach can be implemented using a traditional server per process or per machine model, but this is not required.
Lightweight servers for embedded system It is becoming possible to place computers supporting web servers into many kinds of devices, from toasters to satellites. In these cases, there is often a premium on
6.4
6.6 Open Implementations Our approach is related to Kiczales’s concept of open implementations [7]-that clients can benefit from having controlled access to otherwise black box implementations. Our work differs from the 01 work in important ways. First, 01 focused on providing access for performance tuning, in particular. Our approach is much broader in its intent and applications. Second, Kiczales did not envision webbased access. Nevertheless, our work provides a good mechanism for implementing the 01concept.
making servers small. Researchers are thus developing low cost servers. This work focuses on hardware-based servers that are meant to be embedded in hardware devices. By contrast, we seek component-level, information hiding web interfaces for software components. Designers have embedded web servers in software systems before [22]. The Jigsaw web server embeds an HTTP engine that
490
7
Conclusion
[3] Case J, Fedor M, Schoffstall M, Davin C. The Simple Network Management Protocol (SNMP), RFC-I 157, May 1990.
We are headed rapidly toward a world of machines integrated across time and space by an invisible, pervasive tapestry of computation. The complexity of this computation will be vast. Moreover, it will be designed and it will evolve without central control, using heterogeneous software and hardware mechanisms. Human abilities to understand and manage the resulting computation will be severely stressed. We need concepts, tool and techniques that can help us to gain and maintain intellectual and managerial control in this emerging world. We have presented the design of a web-based architectural aspect that appears to have some potential to serve as a platform for useful solutions. We characterized the aspect in terms of one design rule, and we discussed several design extensions. We demonstrated the feasibility of implementing the aspect and we presented data and early results on scalability, performance and design tradeoffs. We plan future work in several areas. We have begun to evaluate the potential for the approach to aid survivability management of complex distributed systems [15]. We are also likely to follow Gorlick's lead by developing webbased support for remote debugging. Our target will not be resource-limited embedded systems, however, but supercomputing distributed meta-systems, with Legion [4] as an initial case study. We will consider having objects support a broader range of services to aid in the understanding, automated analysis, management and evolution of the emerging computational tapestry. Services that we have in mind go beyond web protocol infrastructure to include per-object, on the fly recompilation and dynamic instrumentation. Such functions could of course be made available through web interfaces. Finally, we will explore additional extensions of our architectural aspect, keeping in mind that less is more in a world of independent designers who already operate under demanding local constraints and who will thus have to reject approaches that impose too many added constraints.
[4] Grimshaw AS, Wulf WA. Legion - A view from 50,000 feet. Proceedings of the Fifth IEEE International Svmposium on High Perj'iormance Distributed Computing (Cat. No.TB100069). IEEE Comput. Soc. Press. 1996, pp.89-99. Los Alamitos, CA, USA. [5] Gorlick MM, Distributed Debugging and Monitoring on $5 a Day, Proceedings of California Software Symposium, Univ. of California, Irvine, California, 1997, pp. 31-39.
[6] Jong-Tae P, Jong-Wook B. Web-based Intranet/Intemet Service Management with QoS Support, IEICE Transactions on Communications, Vol.E82-B, No.11, 1808-1816, November 1999. [7] Kiczales G, Lamping J, Lopes CV, Maeda C, Mendhekar A, Mnrphy G. Open implementation design guidelines. Proceedings of the I997 International Conference on Software Engineering, ICSE 97. ACM. 1997, pp.481-90. New York, NY, USA. [8] Leidigh C. Web-based Management of Network devices, Proceedings of the -Embedded Systems Conference (Spring), Miller Freeman. Vol.1, 1998, 117 vol.1. San Francisco, CA, USA. Microsoft Corp. Active Server Pages (ASP). [Online document]. (h tte:l/www.microsoft.corn/workshodserver). 1c Murugesan S, Deshpande Y, Hansen S, On Exploiting the Internet and Web for Software Development and Distribution, Proceedings of IEEE International
Conference on Networking India and the World, Ahmedabad, India, December, 1998.
ACKNOWLEDGEMENTS
11 Nackerud SA. The potential of CGI: using pre-built CGI scripts to make interactive Web pages. Information Technology & Libraries, vol. 17, no.4, Dec.1998, pp.222-9. Publisher: Libr. & Inf. Techno]. Assoc, USA.
This work was supported by National Science Foundation grants CCR-9804078 and ITR-0086003. We thank George Heinemann, Marty Humphrey, William G. Griswold, David Notkin and his students, John Knight and, especially, Michael Gorlick and the anonymous conference reviewers for detailed and very constructive and helpful criticisms of an earlier version of this paper.
[12]Object Management Group Inc. (OMG). CORBA 2.3. llIIOP Specifications. [Online document]. October 1999. (httD://www.oma.ore/technoloLrv/documentdformali).
References
[13]Qinzheng K, Chen G, Hussain R Y, A Management framework for Internet Services, IEEE Network Operations and Management Symposium, Conference Proceedings, IEEE. Part vol.1, 1998,21-30 vol.1. New York, NY, USA.
[l] Apache Software Foundation. Apache modules. [OnI i ne document]. 01t tp://www .amch e.or ddws). [2] Box D. SOAP:Simple Object Access Protocol. H l T P Working Group Internet Draft, September 1999.
491
[14]Sullivan KJ, Designing Models of Modularity for Component Software, in Heineman and Councill, eds., Component-Based Software Engineering: Putting the Pieces Together, Addison Wesley, 2001, forthcoming. [lS]Sullivan KJ, Saxena A, A Web-Based Approach to Survivability Control, Third Information Survivability Workshop, Boston, MA, 2000. [16]Sullivan KJ, Knight KC, Du X, Geist S, Information Survivability Control Systems, Proceedings of the 21" International Conference on Software Engineering, May 1999, pp. 184-193. [17] Sun Microsystems Inc., Java Language Specification, 2nd Edition, OlttD://iava.sun.comlaboutJa\lan.
[IS] Sun Microsystems Inc., Java Servlet Technology, (h tt p://iava.sun.coi~~roductdser\~let/index. h t ml). [19]Thompson D, Watkins D. Comparisons between CORBA and DCOM: architecture.. for distributed computing. Proceedings. Technology of ObjectTOOLS 24 (Cat. Oriented Languages. No.97TB100240). IEEE Comput. Soc. 1998, pp.27883. Los Alamitos, CA, USA. [20] Ultraseek, Ultraseek Server, [Online document], (http://ww. ultraseek. com). [21] Userland Software Inc. XML-RPC Specification. [Online document]. (htt~://\4~~~w.userZarid.co~s~ec). [22] Welch B, Uhler S. Web enabling applications. Proceedings of the Fifth Annual Tcl/Tk Workshop. USENIX Assoc. 1997, pp.189-90. Berkeley, CA, USA.
492
