WO1999044140A2

WO1999044140A2 - An interactive design tool for shared memory spaces

Info

Publication number: WO1999044140A2
Application number: PCT/US1999/003397
Authority: WO
Inventors: Kenneth C. R. C. Arnold
Original assignee: Sun Microsystems, Inc.
Priority date: 1998-02-26
Filing date: 1999-02-17
Publication date: 1999-09-02
Also published as: KR20010040980A; JP2002505479A; AU2770399A; WO1999044140A3; CN1292113A; EP1057114A2

Abstract

An interactive design tool allows a designer to visually define object flow between computing resources and shared memory spaces in a distributed computing system. The design tool automatically converts the visual depiction of the object flow to computer code implementing the depicted object flow.

Description

AN INTERACTIVE DESIGN TOOL FOR SHARED MEMORY SPACES

Related Applications

The following identified U.S. patent applications are relied upon and are incorporated by reference in this application.

Provisional U.S. Patent Application No. 60/076,048, entitled "Distributed Computing System," filed on February 26, 1998.

U.S. Patent Application No. 09/044,923, entitled "Method and System for Leasing Storage," bearing attorney docket no. 06502.0011-01000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,838, entitled "Method, Apparatus and Product for Leasing of Delegation Certificates in a Distributed System," bearing attorney docket no. 06502.0011-02000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,834, entitled "Method, Apparatus and Product for Leasing of Group Membership in a Distributed System," bearing attorney docket no. 06502.0011-03000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,933, entitled "Method for Transporting Behavior in Event Based System," bearing attorney docket no. 06502.0054-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,919, entitled "Deferred Reconstruction of Objects and Remote Loading for Event Notification in a Distributed System," bearing attorney docket no. 06502.0062-01000, and filed on the same date herewith.

U.S. Patent Application No. 09/045,652, entitled "Method and System for Deterministic Hashes to Identify Remote Methods," bearing attorney docket no. 06502.0103-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,790, entitled "Method and Apparatus for Detern ining Status of Remote Objects in a Distributed System," bearing attorney docket no. 06502.0104-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,930, entitled "Downloadable Smart Proxies for Performing Processing Associated with a Remote Procedure Call in a Distributed System," bearing attorney docket no. 06502.0105-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,917, entitled "Suspension and Continuation of Remote Methods," bearing attorney docket no. 06502.0106-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,835, entitled "Method and System for Multi-Entry and Multi-Template Matching in a Database," bearing attorney docket no. 06502.0107-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,839, entitled "Method and System for In-Place Modifications in a Database," bearing attorney docket no. 06502.0108, and filed on the same date herewith.

U.S. Patent Application No. 09/044,945, entitled "Method and System for Typesafe Attribute Matching in a Database," bearing attorney docket no. 06502.0109-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,931, entitled "Dynamic Lookup Service in a Distributed System," bearing attorney docket no. 06502.0110-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,939, entitled "Apparatus and Method for Providing Downloadable Code for Use in Communicating with a Device in a Distributed System," bearing attorney docket no. 06502.0112-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,826, entitled "Method and System for Facilitating Access to a Lookup Service," bearing attorney docket no. 06502.0113-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,932, entitled "Apparatus and Method for Dynamically Verifying Information in a Distributed System," bearing attorney docket no. 06502.0114-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/030,840, entitled "Method and Apparatus for Dynamic Distributed Computing Over a Network," and filed on February 26, 1998.

U.S. Patent Application No. 09/044,934, entitled "Polymorphic Token-Based Control," bearing attorney docket no. 06502.0117-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044.915, entitled "Stack-Based Access Control," bearing attorney docket no. 06502.0118-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,944, entitled "Stack-Based Security Requirements," bearing attorney docket no. 06502.0119-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/044,837, entitled "Per-Method Designation of Security Requirements," bearing attorney docket no. 06502.0120-00000, and filed on the same date herewith. Field of the Invention

This invention relates generally to distributed computer systems, and more specifically, to the modeling of object flow in a distributed computer system. Background of the Invention

Distributed computer systems are systems in which the programming and data that the computer operates on are spread out over more than one computer, usually over a network with many computers. One conventional method for organizing a distributed system uses the client-server model, in which one part of the distributed system (the client) asks for some service from another part of the distributed system (the server). The server responds and then handles the client's request appropriately.

Under the client-server model, when the client encounters a procedure located at the server, the procedure may be implemented using some form of a Remote Procedure Call (RPC): the client informs the server that it would like the procedure executed using certain parameters, the server executes the procedure, and the server returns the results of the execution to the client.

The client-server distributed system model implements a "method-invocation-style" protocol, in which the client and server directly cooperate with one another to execute the desired methods. Many distributed algorithms, however, could be better modeled using a flow-of-objects approach, in which the distributed systems protocols are based on the movement of objects into and out of "spaces" (virtual shared memories) designated to hold objects. Persistent, shared memory spaces, such as in the Linda programming model, are known in the art. See, for example, "Generative Computing in Linda", David Gelemter, ACM Transactions on Programming Languages and Systems, Vol. 7, No. 1, pp. 80-112 (January 1995); "Persistent Linda: Linda + Transactions + Query Processing", Brian G. Anderson, Dennis Shasha; and "Adding Fault-tolerant Transaction Processing to LINDA", Scott R. Cannon, David Dunn, Software— Practice and Experience, Vol. 24(5), pp. 446-449 (May 1994).

Fig. 1 is a diagram illustrating an exemplary distributed "book ordering system" 100 using the flow of objects approach to model distributed algorithms. In this system, objects (i.e., data structures that contain behavior and/or data) are manipulated by computers 110-115 to "flow" into and out of spaces 102-105. Distributed system 100 includes buyer computer 110, broker computer 111, and seller computers 112-114 . Spaces 102-105 may be hosted on one of computers 110-115 or on another computer not shown in Fig. 1.

Assume that book buyer 110 would like to buy fifty copies of a particular book. Buyer 110 submits an object to space 102 that includes a request for bids on the desired book. Broker 111 removes the bid request from space 102 and writes the bid request, or an appropriately modified version of the bid request, into spaces 103-105, which correspond to spaces of particular book wholesalers 112-114 that are registered with broker 111. A server at each wholesaler 112-114 removes the bid request from its designated space 103-105, respectively, and presents the request to a human. The human prepares the bid and then writes the bid back into the wholesalers space for forwarding by broker 111 to space 102 (alternatively, the bid may be written by wholesalers 112-114 straight into public space 102). When the bidding period closes, buyer 110 removes the bids from space 102 and presents them to a human to select the winning bid.

Book ordering system 100 implements a distributed book ordering algorithm using only a single interface, the shared memory space interface, through which computers 110-114 interact.

Although the shared memory space interface described above presents a powerful methodology for organizing distributed computing resources, current tools for designing the organization of spaces with their associated objects and computing resources are crude, as they require the programmer to manually code all remote procedure calls and manually specify the operation on the shared memory spaces, including the types of objects used by the memory spaces. Thus, there is a need in the art for a more sophisticated, user friendly tool for designing distributed algorithms using spaces and the flow-of-objects model. Summary of the Invention

Objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

To achieve the objects and in accordance with the purpose of the invention, as embodied and broadly described herein, a first aspect consistent with the present invention includes a method of generating computer code defining object flow in a shared memory, the method comprising the steps of: (1) displaying a graphical interface in which images representing computing resources and images representing the shared memory spaces are placed; (2) storing information, entered via the graphical interface, that describes object flow between the computing resources and the shared memory spaces; and (3) generating computer code that implements the object flow described between the shared memory spaces and the computing resources.

A second aspect consistent with the present invention includes a method of generating computer code defining object flow in a shared memory, the method comprising the steps of: (1) placing graphical representations of computing resources on a graphical display area; (2) placing graphical representations of shared memory spaces on the graphical display area; (3) entering information describing data flow between the graphical representations of the computing resources and the graphical representations of the shared memory spaces; and (4) automatically generating computer code that implements the object flow between shared memory spaces corresponding to the graphical representation of the shared memory spaces and between computing resources corresponding to the graphical representations of the computing resources.

Additional aspects of the present invention, related to the first aspect, are directed to a computer readable medium and a computer system. Brief Description of the Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments consistent with this invention and, together with the description, help explain the principles of the invention. In the drawings,

Fig. 1 is a diagram illustrating an exemplary distributed system using the flow of objects approach to model distributed algorithms;

Fig. 2 is a diagram of an exemplary distributed system;

Fig. 3 is a diagram of an exemplary computer within the exemplary distributed system;

Figs. 4A-4D are diagrams illustrating an exemplary graphical interface of the interactive design tool consistent with the present invention;

Fig. 5 is a flowchart illustrating methods consistent with the present invention for generating computer; and

Fig. 6 is a diagram illustrating an exemplary section of generated computer code. Detailed Description

Referring to the accompanying drawings, a detailed description of the preferred embodiment will now be described.

System Overview

Methods and systems consistent with the present invention operate in a distributed system ("the exemplary distributed system") with various components, including both hardware and software. The exemplary distributed system (1) allows users of the system to share services and resources over a network of many devices; (2) provides programmers with tools and programming patterns that allow development of robust, secured distributed systems; and (3) simplifies the task of administering the distributed system. To accomplish these goals, the exemplary distributed system utilizes the Java™ programming environment to allow both code and data to be moved from device to device in a seamless manner. Accordingly, the exemplary distributed system is layered on top of the Java programming environment and exploits the characteristics of this environment, including the security offered by it and the strong typing provided by it. The Java programming environment is more clearly described in Jaworski, Java 1.1 Developer's Guide. Sams.net (1997), which is incorporated herein by reference.

In the exemplary distributed system, different computers and devices are federated into what appears to the user to be a single system. By appearing as a single system, the exemplary distributed system provides the simphcity of access and the power of sharing that can be provided by a single system without giving up the flexibility and personalized response of a personal computer or workstation. The exemplary distributed system may contain thousands of devices operated by users who are geographically disperse, but who agree on basic notions of trust, administration, and policy.

Within the exemplary distributed system are various logical groupings of services provided by one or more devices, and each such logical grouping is known as a Djinn. A "service" refers to a resource, data, or functionality that can be accessed by a user, program, device, or another service and that can be computational, storage related, communication related, or related to providing access to another user. Examples of services provided as part of a Djinn include devices, such as printers, displays, and disks; software, such as applications or utilities; information, such as databases and files; and users of the system.

Both users and devices may join a Djinn. When joining a Djinn, the user or device adds zero or more services to the Djinn and may access, subject to security constraints, any one of the services it contains. Thus, devices and users federate into a Djinn to share access to its services. The services of the Djinn appear programmatically as objects of the Java programming environment, which may include other objects, software components written in different programming languages, or hardware devices. A service has an interface defining the operations that can be requested of that service, and the type of the service determines the interfaces that make up that service.

Fig. 2 depicts the exemplary distributed system 200 containing computer 202, computer 204, and device 206 interconnected by a network 208. The device 206 may be any of a number of devices, such as a printer, fax machine, storage device, or other devices. The network 208 may be a local area network, wide area network, or the Internet. Although only two computers and one device are depicted as comprising the exemplary distributed system 200, one skilled in the art will appreciate that the exemplary distributed system 200 may include additional computers or devices.

Fig. 3 depicts computer 202 in greater detail to show a number of the software and hardware components of the distributed system 200. One skilled in the art will appreciate that computer 204 or device 206 may be similarly configured. Computer 202 includes a memory 302, a secondary storage device 304, a central processing unit (CPU) 306, an input device 308, and a video display or monitor 310. The memory 302 includes a lookup service 312, a discovery server 314, and a Java runtime system 316. The Java runtime system 316 includes the Java™ remote method invocation system (RMI) 318 and a Java virtual machine 320. The secondary storage device 304 includes a JavaSpace 322.

As mentioned above, the exemplary distributed system 200 is based on the Java programming environment and thus makes use of the Java runtime system 316. The Java runtime system 316 includes the Java API, allowing programs running on top of the Java runtime system to access, in a platform-independent manner, various system functions, including windowing capabilities and networking capabilities of the host operating system. Since the Java API provides a single common API across all operating systems to which the Java runtime system is ported, the programs running on top of a Java runtime system run in a platform-independent manner, regardless of the operating system or hardware configuration of the host platform. The Java runtime system 316 is provided as part of the Java software development kit available from Sun Microsystems of Mountain View, CA.

The Java virtual machine 320 also facilitates platform independence. The Java virtual machine 320 acts like an abstract computing machine receiving instructions from programs in the form of byte codes and interpreting these byte codes by dynamically converting them into a form for execution, such as object code, and executing them. RMI 318 facilitates remote method invocation by allowing objects executing on one computer or device to invoke methods of an object on another computer or device. Both RMI and the Java virtual machine are also provided as part of the Java software development kit.

The lookup service 312 defines the services that are available for a particular Djinn. That is, there may be more than one Djinn and, consequently, more than one lookup service within the exemplary distributed system 200. The lookup service 312 contains one object for each service within the Djinn, and each object contains various methods that facilitate access to the corresponding service. The lookup service 312 and its access are described in greater detail in co-pending U.S. Patent Application No. , entitled "Method and System for Facilitating Access to a Lookup Service," which has previously been incorporated by reference.

The discovery server 314 detects when a new device is added to the exemplary distributed system 200, during a process known as boot and join or discovery, and when such a new device is detected, the discovery server passes a reference to the lookup service 312 to the new device, so that the new device may register its services with the lookup service and become a member of the Djinn. After registration, the new device becomes a member of the Djinn, and as a result, it may access all the services contained in the lookup service 312. The process of boot and join is described in greater detail in co-pending U.S. Patent Application

No. , entitled "Apparatus and Method for providing Downloadable Code for Use in Communicating with a Device in a Distributed System," which has previously been incorporated by reference.

One skilled in the art will appreciate that the exemplary distributed system 200 may contain many lookup services, discovery servers, and JavaSpaces.

Although systems and methods consistent with the present invention are described as operating in the exemplary distributed system and the Java programming environment, one skilled in the art will appreciate that the present invention can be practiced in other systems and other programming environments. Additionally, although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet; or other forms of RAM or ROM. Sun, Sun Microsystems, the SunLogo, Java, and Java-based trademarks are trademarks or registered trademarks of Sun Microsystems Inc. in the United States and other countries.

The JavaSpace Model and Terms

An interactive design tool consistent with the present invention assists a designer in developing distributed programs using shared memory spaces in a flow-of-objects approach to modeling a distributed computing system. As used throughout this disclosure, "shared memory space" refers to any memory that can be viewed or modified by more than one process.

Although the concepts of the present invention apply equally well to any type of shared memory space implementing the flow-of-objects approach to modeling a distributed system, in the embodiments described herein, JavaSpaces, such as JavaSpace 322, are used.

The JavaSpace 322 is an object repository used by programs within distributed system 200 to store objects. Programs use the JavaSpace 322 to store objects persistently as well as to make them accessible to other devices within the Java distributed system. JavaSpaces are described in greater detail in co-pending U.S. Patent Application No. 08/971,529, entitled "Database System Employing Polymorphic Entry and Entry Matching," assigned to a common assignee, filed on November 17, 1997, which is incorporated herein by reference. A brief review of JavaSpaces follow.

A JavaSpace holds entries, where an entry is a typed group of objects. An entry can be written into a JavaSpace, which creates a copy of that entry in the JavaSpace. Entries can be looked up in JavaSpaces using templates, which are entry objects that have some or all of its fields set to specified values that must be matched exactly. Remaining fields are left as wildcards- these fields are not used in the lookup.

JavaSpaces support two kinds of lookup operations: read and take. A read request to a JavaSpace returns either an entry that matches the template on which the read is done, or an indication that no match was found. A take request operates like a read, but if a match is found, the matching entry is removed from the JavaSpace. Standing requests may be made to the JavaSpace so that the JavaSpace will notify the requestor when an entry that matches a specified template is written.

All operations that modify a JavaSpace are preferably performed in a transactionally secure manner with respect to that space. That is, if a write operation returns successfully, that entry was written into the space. And if a take operation returns an entry, that entry has been removed from the space, and no future operation will read or take the same entry. In other words, each entry in the JavaSpace can be taken at most once, although two or more entries in a JavaSpace may have exactly the same value.

Interactive Design Tool

An interactive design tool (IDT) consistent with the present invention allows users to interactively and visually design object data flow through JavaSpaces. Users of the IDT may visually and graphically define the protocol governing the object flow. The IDT may then generate computer code implementing the protocol.

Figs. 4A-4D are diagrams illustrating an exemplary graphical interface of the IDT consistent with the present invention. The EDT is preferably a program executed by computer 202, stored in memory 302, and which presents a graphical interface on display 310.

As shown in Fig. 4A, graphical interface 400 includes a design area 402 and a tool bar 406. In design area 402, a programmer places and manipulates graphical representations of JavaSpaces and the clients that access the JavaSpaces. Representations of the JavaSpaces and the client computing resources (e.g., a computer) are displayed on tool bar 406. For example, as shown, JavaSpaces are represented by icon 408 and computing resources by icon 407. To add a JavaSpace to design area 402, the programmer may simply click on the JavaSpace icon 308 and drag it into the design area 402. Client computers may be similarly added by clicking on icon 407.

Button 409, labeled "create code," when activated, causes the IDT to generate the class files that define the entry types in the JavaSpaces and/or generate skeleton code or partial skeleton code of the clients placed in design area 402. In other words, given the information visually depicted in design area 402, the IDT generates computer code representing the functionality defined by the programmer in the design area 402, thus saving the programmer the burden of having to manually write the code. In particular, the computer code includes implementations of the remote procedure calls performed by the client to the appropriate JavaSpaces.

Although graphical user interface 400 of the IDT is illustrated as comprising a tool bar 402 having two icons and a single button, one of ordinary skill in the art will recognize that there are many possible implementations of design area 402 and tool bar 406. For example, tool bar 406 may contain additional icons representing different types of computing resources, or may be implemented as pull-down menus.

To further clarify the concepts and features consistent with the present invention, as discussed above, the creation of an exemplary distributed system using the EDT will now be explained with reference to Figs. 4B through 4D, which are illustrations of interface 400 at various points in the construction of the distributed computing system.

Fig. 4B is an illustration of design area 402 after the programmer has added JavaSpace 410 to design area 402. As an example, assume JavaSpace 410 holds entries that include a "graphics object" that stores portions of an image.

Fig. 4C is an illustration of design area 402 after the programmer has added a client computer system 412 and indicated that client computer system 412 will write the graphics object entries into JavaSpace 410 (illustrated by line 413). At this point, the IDT may display dialog box 415, in which the user may enter the name (e.g., "image segment") and the type (e.g., graphics object) of the entry that is to be written into JavaSpace 410. Similarly, additional dialog boxes may be used to enter additional information— such as allowing the programmer to define a new type of object for the JavaSpace.

Fig. 4D is an illustration of design area 402 after the programmer has added second, third, and fourth client computer systems 416-418, respectively. Clients 416 and 417 take entries from JavaSpace 410 and write entries into JavaSpace 410. Clients 416 and 417, may be, for example, specialized high speed graphics workstations that perform image processing operations on the graphic object entries in JavaSpace 410. More particularly, clients 416 and 417 monitor space 410 using templates that indicate a match whenever a "graphics object" is written into space 410. The matched objects are then taken by one of clients 416 and 417 from space 410, operated on, and written back into JavaSpace 410. Client 418 takes the entries operated on by clients 416 and 417 out of JavaSpace 410.

As mentioned above, the indication of which clients will write, take, or read entries from the JavaSpaces is preferably indicated to the programmer using the lines shown in Figs. 4C and 4D, although other methods of graphically illustrating object-flow may alternatively be used.

When client code button 409 is activated by the programmer the IDT generates computer code for each client in design area 402. In the example shown in Fig. 4D, the IDT would generate computer code for clients 412, 416, 417, and 418. In general, for each client, the IDT generates code that performs a write, take, or read operation on the designated JavaSpace(s) using the entry type specified by the programmer.

Fig. 5 is a flowchart illustrating the generation of computer code by the IDT. The IDT generates code for each JavaSpace operation (i.e., for each write, read, or take operation) in each client in the design area. Generally, the IDT will write a separate program or code module for each client (steps 502, 503). In each code module, the IDT generates code corresponding to each JavaSpace operation (steps 504 and 505). Preferably, when writing code for a JavaSpace operation, the IDT also stores information correlating the code to the visual display area, (step 506), thereby allowing the IDT to appropriately update the code if the programmer changes the visual representation of the distributed system or to update the visual representation if the programmer manually changes the code. The correlation between the visual description and the computer code may be implemented using commented annotations in the computer code or by creating a database storing the correspondence between the generated code and the visual depictions. Fig. 6 is a diagram illustrating an exemplary code module generated for one of clients 416 and 417. As shown in Fig. 4D, each of clients 416 and 417 takes a graphics object and writes a graphics object. These two JavaSpace operations are illustrated as code sections 602 and 604, respectively. The programmer may add additional code, such as code sections 601, 603, and 605. For example, code section 603 may perform an image processing operation such as an image smoothing operation on the graphics object taken by code section 602. Code section 604 writes the smoothed code section back to JavaSpace 410.

The IDT generates the lines of code corresponding to each JavaSpace operation by looking up the instruction(s) required to implement the JavaSpace operation and adding the appropriate parameter data to the instructions, such as, for example, the name or address of the JavaSpace being operated on and an identification of the entry to be written, taken, or read from the JavaSpace. The list of the instructions required to implement the JavaSpace operations is predefined in the IDT.

The interactive design tool described herein allows a programmer to visually design the high-level flow through a shared memory space in a distributed system and then generate computer code implementing the design. The visual representation and the computer code are linked, so that when subsequent changes are made to either one, the other one is automatically updated. This is advantageous, as it allows the programmer to more easily design and layout the object flow in the distributed system. The programmer can then add details and additional functionality to the computer code.

While there has been illustrated and described what are at present considered to be preferred embodiments and methods of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the invention. For example, while the foregoing systems and methods have been described with reference to a Java based run-time environment using JavaSpaces, other run-time environments and shared memory could conceivably be used. Further, although the foregoing system and methods referred to the objects in the object-flow using the traditional object oriented definition of an object (i.e., a data structure with the capability of having both functionality and data), simple data-only structures, such as a C language "structure," may also be used.

In addition, many modifications may be made to adapt a particular element, technique or implementation to the teachings of the present invention without departing from the central scope of the invention. Therefore, it is intended that this invention not be limited to the particular embodiments and methods disclosed herein, but that the invention include all embodiments falling within the scope of the appended claims.

Claims

What is Claimed

1. A method of generating computer code defining object flow in a shared memory space, the method comprising the steps of: displaying a graphical interface in which images representing computing resources and images representing the shared memory spaces are placed; storing information, entered via the graphical interface, that describes object flow between the computing resources and the shared memory spaces; and generating computer code that implements the object flow described between the shared memory spaces and the computing resources.

2. The method of claim 1, wherein the shared memory spaces are JavaSpaces.

3. The method of claim 1, wherein the step of storing information describing object flow between the shared memory spaces and the computing resources includes the step of storing information describing which of the computing resources take entries from the shared memory spaces.

4. The method of claim 1, wherein the step of storing information describing object flow between the shared memory spaces and the computing resources includes the step of storing the information describing which of the computing resources write entries to the shared memory spaces.

5. The method of claim 1, wherein the step of storing information describing object flow between the shared memory spaces and the computing resources includes the step of storing information describing which of the computing resources read entries from the shared memory spaces.

6. The method of claim 1, further including the step of automatically updating the generated computer code when the images on the graphical interface are modified.

7. A method of generating computer code defining object flow in a shared memory space, comprising the steps of: placing graphical representations of computing resources on a graphical display area; placing graphical representations of shared memory spaces on the graphical display area; entering information describing data flow between the graphical representations of the computing resources and the graphical representations of the shared memory spaces; and automatically generating computer code that implements the object flow between shared memory spaces corresponding to the graphical representation of the shared memory spaces and between computing resources corresponding to the graphical representations of the computing resources.

8. The method of claim 7, wherein the shared memory spaces are JavaSpaces.

9. The method of claim 7, wherein the step of entering information describing data flow between the graphical representations of the shared memory spaces and the graphical representations of the computing resources includes the step of entering information describing which of the computing resources take entries from the graphical representations of the shared memory spaces.

10. The method of claim 7, wherein the step of entering information describing data flow between the graphical representations of the shared memory spaces and the graphical representations of the computing resources includes the step of entering information describing which of the computing resources write entries into the graphical representations of the shared memory spaces.

11. The method of claim 7, wherein the step of entering information describing data flow between the graphical representations of the shared memory spaces and the graphical representations of the computing resources includes the step of entering information describing which of the computing resources read entries from the graphical representations of the shared memory spaces.

12. The method of claim 7, further including the step of automatically updating the generated computer code when the images in the graphical display area are modified.

13. A computer readable medium containing instructions executable on a computer for generating computer code defining object flow in a shared memory space, the instructions, when executed on the computer, performing the steps of: displaying a graphical interface in which images representing computing resources and images representing the shared memory spaces are placed; storing information, entered via the graphical interface, that describes object flow between the computing resources and the shared memory spaces; and generating computer code that implements the object flow described between the shared memory spaces and the computing resources.

14. A computer system comprising: a display for displaying a graphical interface in which images representing computing resources and images representing shared memory spaces are placed; a memory including an interface design tool (IDT) program, the IDT program including means for controlling the graphical interface, means for storing information entered in the graphical interface that describes object flow between the images of the computing resources and the images of shared memory spaces; and means for generating computer code that implements the object flow described between the shared memory spaces and the computing resources; a processor configured to execute the IDT program in the memory; and an input device coupled to the processor and allowing a user to modify the images representing the computing resources, the images representing the shared memory spaces, and the information describing object flow between the images of the computing resources and the shared memories.

15. The method of claim 14, wherein the shared memories are JavaSpaces.

16. The method of claim 14, wherein the means for storing information entered in the graphical interface that describes object flow between the images of the computing resources and the images of shared memory spaces includes means for storing information describing which of the computing resources take entries from the shared memory spaces.

17. The method of claim 14, wherein the means for storing information entered in the graphical interface that describes object flow between the images of the computing resources and the images of shared memory spaces includes means for storing information describing which of the computing resources write entries to the shared memory spaces.

18. The method of claim 14, wherein the means for storing information entered in the graphical interface that describes object flow between the images of the computing resources and the images of shared memory spaces includes means for storing information describing which of the computing resources read entries from the shared memory spaces.