Figure 1. Designing network applications using traditional programming environments
In response to societal demand, computer networks have been proliferating rapidly in recent years. Such networks include local area networks (LANS) and wide area networks (WANS) comprising a number of computers that may communicate with one another. Apart from sending messages, this communication between networked computers allows programs to be run on more than one computer in a network. For example, an airline reservation service may present a user interface on a client computer while data input to the interface is transmitted to a server computer where a reservation database is accessed. This type of program execution, known as distributed programming, may be much more complicated than the above example but is nonetheless extremely common and efficient.
Distributed programs, however, are often written, developed and tested on different computers with different tools which are tightly bound to the particular machine upon which they operate and are integrated around language, computing platform or type of application.
This problem is illustrated in Figure 1.
Figure 1. Designing network applications using traditional programming environments
Thus, distributed programs present substantial difficulties to programmers since they must learn to operate the tool set that was used to develop each distributed program segment. These tool sets are usually quite detailed and require days, weeks and even months to master. Further, to edit, view or debug the distributed program currently requires performing these functions under one tool set for a particular program segment, exiting the tool set, locating the tool set for a different program segment, which may be on a different computer, and entering that tool set. This type of operation is extremely time consuming, especially where a program has a large number of segments, each developed with a different tool set.
By employing a particular protocol, the World Wide Web has met the challenge of allowing users, through a single front end tool, to browse documents that reside on a large number of different platforms. The World Wide Web, however, which has been in existence for a number of years, does not provide for any other types of functions apart from browsing and the previously described problems presented by distributed programs remain.
So, there is a need for a system that provides the capability to develop distributed programs that operate on different computers, operating systems and communication protocols, while requiring only one set of tools. Further, there is a need for a system that allows such integration for programs that have already been partially developed or completely developed under a variety of tool environments and that require modification. More broadly, there is a need for a system that allows a single front end tool to perform operations on a plurality of files that reside on different platforms without requiring a user to separately access each separate platform specific piece on that platform.
The Constellation Framework answers these and many other needs.
The Constellation Framework provides methods and mechanisms for a front end navigating tool (the "NAVIGATOR") that may access and manipulate files distributed across different platforms. Figure 2
Figure 2. Cone model of a distributed programming environment
Debugging is one example of a function that may involve distributed files. To service a debugging request, the navigator issues a request according to the URL protocol. Thus, a request is of the form: <server_type://<machine/<request, where server type is a protocol such as, for example, http or process, machine is the actual server address and request is the program or file that is requested. The appropriate machine and server process is then contacted by the navigator and provided with the name of the file, file A. The server process in turn selects the appropriate gateway process to perform the desired function. The gateway process attaches to the desired program, which is subsequently debugged. If the program calls a program on a different machine, the Constellation Framework provides a variety of mechanisms, transparent to the user, for allowing debugging to continue on the called program. In a preferred embodiment, the gateway process provides the server process with the address of the called program, file B. The server process notifies the navigator which then automatically assembles a request to the server process on the different host. The request is sent and the server process selects the appropriate gateway process which then attaches to the target program, file B. If file B returns to file A, then control is again passed to the navigator which calls file A as before except that the gateway process has maintained the appropriate address of the instruction after the call instruction to file B. Debugging then continues on file A.
Browsing, editing and any other function requests are similarly serviced through the front end navigator. A URL link contacts an appropriate server process resident on a target machine and the server process in turn selects the proper gateway process, which performs the desired function on the target file. The target file may include hypertext links to other files and functions may easily be performed on these files by clicking on the file names and then indicating a desired function. In this manner, users may efficiently access and manipulate distributed files through a single front end tool.
Figure 3 is an overview of the architecture of the Constellation
Figure 3. Architecture of the Constellation design framework
As will be described more fully below, each of the server processes procd, httpd and progd illustrated in Figure 3 may reside on a plurality of physical machines. The architecture of the Constellation Framework provides for the integration of a variety of tools, including debugging, document and source code browsing and editing, source code management and program development and building. The implementation of these tools according to the architecture of the Constellation Framework will be described in the following sections of this paper. The architecture of the Constellation Framework as illustrated in Figure 3 may be applied to many other types of tools, including user defined tools.
The Navigator is a browser and at the same time an editor and an interactive shell. Browser capabilities are similar to those of Web browsers such as Mosaic or HOTJava. As editor, it has basic text editing functionality of point and click editors, such as Textedit with command bindings for Emacs and Vi. Editor's capabilities are augmented to support hyper-text (i.e. HTML) program annotations. Interactive shell capability allows users direct interactions with browser's interpreter engines as well as with interactive programs with which the Navigator has established links (e.g. gateway debug engines such as dbx).
Architecture of the Navigator is shown in Figure 4.
Figure 4. An architecture of the Navigator frontend tool
The GUI module creates control panel for the Navigator and maps content of user's searches into a graphic domain. The novel feature of the Navigator is capability to dynamically reconfigure its control panel based on the type of the request and the domain in which browsing is performed. For example.when user makes a request to debug a program, a debug server that services browsing requests in process domain will be contacted and appropriate protocol policy module in Navigator will be downloaded (if not already present) and activated. In debugging example this would result in debugging menu to be created and attached to the Navigator's command panel. Debugging menu will stay attached for duration of a debugging session.Upon completion of a debugging session, debugging menu will be automatically removed from the Navigator's control panel.
The Navigator can operate in stateless or statefull mode. Stateless mode is utilized in events such as directory browsing or information retrieval. Statefull mode is utilized during distributed debugging sessions. The statefull sessions are characterized by long-live connections into a browsing domain. The Navigator keeps track of all long-live connections for all active statefull sessions. The long-live connection represents a bidirectional communication channel into a browsing domain. User can post request to the server which is servicing given domain. Also, server can generate events and send it back to the Navigator.
There are no limits on a number of the concurrent long-live connections. The Navigator allows all long-live connections to be active at the same time. It is a responsibility of policy modules to coordinate events received from domain servers.
Constellation Service layer consists of collection of domain servers and gateway tools. Gateway tools are either interface to service providers (e.g. database access) or service providers. Following list is a sample of domain servers and related gateway tools:
Figure 5 is a block diagram showing how the architecture
Figure 5. Communication sequence when servicing a debugging request
First, the Navigator issues a request according to the Universal Resource Locator (URL) protocol. Thus, a request is of the form: <server_type://<machine/<request, where server type is a protocol such as, for example, http or process, machine is the actual server address and request is the program or file that is requested. The appropriate server process procd resident on a host 1 is then contacted by the Navigator and provided with the name of the file of a running client process, file A. The server process procd in turn selects the appropriate gateway tool PC-debug to perform the desired function.
The gateway tool PC-debug attaches to the target program (application's client process), which is subsequently debugged. If the target program calls a program (application's server process) on a different machine, the Constellation Framework provides a variety of mechanisms, transparent to the user, for allowing debugging to continue on the called program. In Figure 5 the gateway tool PC-debug provides the server process procd with the address of the called program, file B. The server process procd notifies the Navigator which then automatically assembles a URL request to a server process procd on the different host. The request is sent and the server process procd selects the appropriate gateway process dbx which then attaches to the target program (application's server process), file B. If file B returns to file A, then control is again passed to the navigator which calls file A as before except that the gateway process PC-debug has maintained the appropriate address of the instruction after the call instruction to file B. Debugging then continues on file A. In this manner, programs that are debugged by two different tools, for example dbx and PC-debug, may be debugged through a single front end Navigator.
Constellation Framework supports groupware functions such as group debugging sessions and teleconferencing. Figure 6 is a block diagram showing
First, the Navigator on host 1 issues a request according to the Universal Resource Locator (URL) protocol. Thus, a request is of the form: process://<machine/pid=<pid_number, where machine is the actual server address and pid number is the process identification number of a running program. The appropriate server process procd resident on a host1 is then contacted by the Navigator and provided with the pid of a running server process. The server process procd in turn selects the appropriate gateway tool dbx to perform the desired function. The gateway tool dbx attaches to the target program which is subsequently debugged.
Request to clone The Navigator is then sent to host 1. After cloning navigator on host 2 is connected to the server process procd on host 1, thus establishing joint debugging session of the application server program. Further, during the cloning process, navigator on host 1 issued a talk request to showmed conference manager. After accepting talk request, audio gateway tools are launched on both hosts enabling navigators to concurrently have voice communications and group debugging session.
Figure 7 illustrates one possible block diagram for browsing
Figure 7. Editing and source code browsing functions of the Constellation Framework
In addition to browsing editing and saving files the Constellation Framework dynamically generates information concerning the content of retrieved files. For example, a user may desire to analyze a program according to its data structures, function calls and other characteristics. To perform such an operation on a file, the navigator issues a request according to the URL protocol, as previously described. An appropriate server process progd on the target machine is provided with the request and an appropriate gateway tool (e.g. cscope) analyzes the file and provides the results of the analysis to the navigator.
The Constellation Framework provides methods and mechanisms for a front end navigating tool that may access and manipulate files distributed across different physical machines and platforms. The front end navigating tool communicates with a multitude of server processes, resident on networked servers, to perform all types of file manipulations such as such as debugging, source code management and editing. The server processes communicate with gateway processes resident on the same machine as the calling server process that perform the desired function on any of a multitude of program segments that may distributed across a network of computers. The Constellation Framework supports number of function, such as debugging, source code management, source code browsing, multi-platform builds, editing as well as document browsing.
The Constellation Framework prototype has been developed mostly in Tcl7.4/Tk4.0 with approximately one full time and one part time engineer in 6 months period. It works on Solaris and Windows NT platforms.
Thanks to John Ousterhout for early release of Tcl7.4/Tk4.0. Thanks to DOE debugger team, Jon Masamitsu and Andrew Davidson for bearing with me while installing DOE and integrating DOE debugging support, DevPro's Ivan Soleimanipour for volunteering to extend dbx's API with yet another call and Achut Reddy for sharing his experience and code for program browsing. Special thanks go to Steven Li for porting Constellation to Windows environment.
1. The World Wide Web, a global information initiative , http://www.w3.org
2. Ousterhout, J.K., Tcl and the Tk Toolkit ,Addison-Wesley, 1994
Nino Vidovic
AT&T - Business Communication Services [*]
Dr. Vidovic recently joined AT&T as Advanced Network Clients Technology Director in the BCS Operations group. His responsabilities include architecture development and implementation of next generation network client systems.
Prior to joining AT&T, Dr. Vidovic served as the Senior Staff Engineer in Advance Techology Group Sun Microsystems, Inc. While at Sun Microsystems,
he was responsible for identification of new technologies for development of netork enabled applications. He holds a doctorate in computer science from the University of Zagreb, Croatia, and M.S. in computer engineering from Carnegie Mellon.
Dalibor F. Vrsalovic
AT&T - Business Communication Services [*]
Dr. Vrsalovic recently joined AT&T as Advanced Technology Vice President in the BCS Operations group. His responsabilities include providing leadership to the architectural development effort for host platforms to be used in the next generation of network based services as well as establishing AT&T's long-term leadership in global services and distributed computing. Prior to joining AT&T, Dr. Vrsalovic served as the Chief Scientist for Sun Microsystems, Inc. While at Sun Microsystems, he was responsible for the architecture development and implementation of softare products. In addition to R&D, he has held leadership roles in bringing new technologies to general business use and product quality assurance. He holds a doctorate in computer science and M.S. in computer engineering from the University of Zagreb, Croatia