Using Java Applets and CORBA for Distributed Application Development

Transcription

1 Using Java Applets and CORBA for Distributed Application Development Eric Evans Daniel Rogers Summary December 10, 1996 The Java language environment, the World-Wide Web (WWW), and the Common Object Request Broker Architecture (CORBA) are complementary software technologies. When used together they provide a powerful set of tools for developing and deploying user-oriented distributed applications. We set out to establish whether we could develop reasonably sophisticated client software as WWW-downloadable Java Applets, which would use CORBA to interact effectively with remote server software to coordinate and control access to a set of shared resources. Our approach was to re-implement a subset of the functions of an existing distributed application using the Java language, a Java-enabled WWW browser, and a CORBA product. We demonstrated that this implementation correctly performed its functions, and evaluated the new approach with respect to design and development, maintainability, configuration, deployment, user interface attributes, and the use of standards. We concluded that this approach to building distributed applications is not only practical, but is in some ways superior to the widely used Common Gateway Interface approach, as well as conventional client/server approaches that do not exploit the WWW. Background CORBA [1] is the key member of a set of distributed system standards promoted by the Object Management Group (OMG), an industry standards body. CORBA defines the Object Request Broker (ORB), a standard mechanism through which distributed software objects and their clients may interact. Using an ORB, an object and its clients may reside in the same process, or in different processes, which themselves may execute on different hosts connected by a network. CORBA also provides the Interface Definition Language (IDL), a declarative language which can be used to specify the operations that a client may invoke upon an object. The ORB provides the software necessary to convey operation requests from client to object, and responses back from object to client. In the common approach, some of this software is automatically generated as source code from the IDL interface description by an ORB product s IDL compiler tool. Parts of this source code are then compiled and linked with the object, and other parts with its clients. IDL may be mapped to various source languages. CORBA standards currently include mappings to C and C++; the OMG is in the process of standardizing the IDL mappings to Ada, COBOL, Java, and others. Since the ORB software takes care of the details of conveying operation requests and responses, objects and their clients may interact without regard to their respective locations, host or compiler data representations, source languages, host/operating system specifics, or underlying communication mechanisms. This enables distributed applications to incorporate components that are written in different

2 source languages and are executable on different host and operating system platforms. This flexibility allows such applications to be composed out of legacy or third-party software as well as newly developed software. One problem that CORBA does not solve is that of deploying a distributed application s component programs - i.e., installing them on the hosts where they are to be executed. This task is part of maintenance as well as initial setup, since software upgrades may require replacing components with new versions. The problem is further complicated by platform heterogeneity - the same component software may be required to execute properly on a range of different host architectures and operating systems. However, the evolution of WWW technology has provided one potential solution to this problem. Java [2] is a new object-oriented programming language gaining rapid acceptance among WWW developers. Among its many interesting features, there are two in particular that make it attractive for use in distributed applications. One is that Java source code can be compiled into a machine-independent format consisting of virtual machine instructions and symbolic data, called the bytecode format. Upon execution this bytecode must be interpreted by a special Java interpreter, part of a Java runtime which itself must be ported to any required host and operating system platforms. The interpreter converts the bytecode to the actual addresses and machine instructions for the given platform. This approach is a trade-off: bytecode execution is slower than that for fully-compiled software, but faster than that for fully-interpreted software, while still achieving the platform independence of runtime interpretation. The other feature is not in the Java language itself, but in an extension to the Hypertext Markup Language (HTML). HTML [3] is the formatting language that describes how to display the contents of WWW documents. It includes a syntax for embedding links to other documents, which a WWW browser will automatically download when the user selects its link. The extension allows the embedding of such links to special Java programs called Applets. If a WWW browser has been extended to incorporate a Java runtime, then it can automatically download an Applet to the user's host computer and execute it there. This feature provides a simple and flexible mechanism for transferring executable software to users when it is actually needed, instead of installing it at their host or site ahead of time. Therefore WWW infrastructure and Java Applets can simplify the job of deploying the user client components of a distributed application. Java itself does not currently provide any mechanism to support remote operations among distributed application components. However, the features of CORBA and Java Applets complement each other well. Together they provide a more comprehensive approach to developing and deploying distributed applications than either technology does by itself. This approach appears to be particularly suitable for user-oriented distributed applications, the focus of this paper. Applications of this class are driven by users, who invoke operations that are implemented by server software residing on remote host computers. The user is typically not logged into the server host, but interacts with client software running on another host, such as the user s desktop computer. The client software may provide a user interface (UI) for accepting user requests and displaying information. The server software provides the bulk of the application services based on data, executable resources, or devices that are shared among the users. It may support operations such as information retrieval or resource management. Examples of user-oriented applications include interactive database 2

3 access, document management, and group scheduling calendars. However, other applications such as automated process control and distributed simulation may not necessarily fit this user-driven model. We chose the Version and Integration Control System (VICS) as the guinea pig application for testing the combined use of Java and CORBA. Developed and used at the University of Texas Applied Research Laboratory, VICS is a good example of a user-oriented distributed application. It provides a multi-user, distributed software configuration management capability. Most VICS operations are invoked through a graphical UI, which users access from their own host machines. Its database and file version control capabilities are implemented in software that only executes on the VICS server host. Therefore most operations require communication across a network, between the user client and server software. Since the user hosts may be geographically distributed among different sites, this communication may traverse the Internet. Approach The current VICS implementation is WWW-based, employing a combination of HTML forms and the Common Gateway Interface (CGI) [4]. In this approach, the client/server interface operations are defined using HTML forms. For a particular operation, a HTML FORM tag specifies the CGI program that implements that operation on the WWW server host. The operation s arguments are specified by the HTML INPUT tags attached to that FORM, each of which also represents a simple GUI input component. When the user submits the operation request, the argument values are taken from the INPUT components and passed to the WWW server. The server spawns the CGI program and provides the arguments as environment variables. When the program is done, it provides the operation result to the WWW server, as a document in a format that the WWW browser can display (usually HTML). HTML forms and CGI allow developers to add simple user interactivity to WWW sites. User Host WWW Browser Display WWW pages to user on request Download and execute Java Applets on request Request WWW page (via HTTP) Download WWW page (via HTTP) Request Java Applet (via HTTP) Download Java Applet (via HTTP) Server Host WWW Server Maintain WWW pages for download to users Maintain Java Applets for download to users Execute Java Applet under control of WWW browser Client Java Applet Provide interface to user Invoke operations on remote server Operation request (via CORBA) Operation response (via CORBA) Remote Object Server Perform applicationspecific operations on request (such as version control) Figure 1 3

4 Our basic premise was that it should be possible to design distributed applications in which all of the user-side client software is implemented as Java Applets, which use CORBA for most remote operations with the rest of the application s software components. The users would transparently download the Applets when they are needed, thus removing the need for manually distributing and installing any application-specific software (Figure 1). We took the following steps to design and develop a prototype of this new approach, with the goal of re-implementing a subset of the VICS operations. In general, one must first decide how a distributed application s capabilities should be allocated between the user client software and the server software. This may involve various trade-offs specific to the application, but in general most user interface software should run on the user s host, while shared resources and the software that controls access to them should reside at a server site. Another guiding principle is to define the client/server interface operations so as to minimize the frequency of requests and the amount of data that must be communicated across the network. We followed both of these tenets in developing our prototype. Using CORBA, the development of the client/server interaction software flowed smoothly from the client/server interface design. We first defined this interface in terms of the operations that the clients may invoke on the server. This definition was captured in an IDL file. Each server capability was modelled as a CORBA interface, and each of its operations was defined as a method with its own input and output arguments. In this prototype we only implemented one CORBA interface, corresponding to the VICS file version control service. For example, the IDL excerpt below defines one of the methods supported by the version control interface (the exception types were defined elsewhere in the IDL file): interface VersionControl { // // Get revision history of a file under version control. // Returns pathname of temporary history file on server. string getfilehistory(in string file, in string revision, in string username, in string userpassword) raises (FilenameException, RevisionException, UserVerifyException); An IDL-to-C++ compiler used this IDL definition to automatically generate some of the source code for the version control server program. This included the C++ definitions for the types defined in the IDL file, and some code for dispatching incoming requests to the corresponding methods of the object that implements the version control interface (class VersionControl_i). We then implemented the method bodies of this class, whose mapping from IDL to C++ is exemplified in the following excerpt from the VersionControl_i.cc file: 4

5 char * VersionControl_i::getFileHistory (const char * file, const char * revision, const char * username, const char * userpassword, CORBA::Environment &IT_env) { // implementation } This class was then used to build a version control server program. While there are several ways of configuring such a server using CORBA, the example below illustrates a very simple approach using the CORBA Basic Object Adapter (BOA) shared server policy ("The server is activated the first time a request is performed on any object implemented by that serverthe BOA will not activate another server for that implementation if one is actve.") [1]: main() { // Instantiate a version control object VersionControl_i vc; } // Register this object for activation with the ORB impl_is_ready("versioncontrolsvr"); Next, using an IDL-to-Java compiler, we generated the client-side proxy class that represents the remote version control service. The following excerpt from this generated class shows the Java mapping of the original IDL interface and method: package vics.corba.verscntl; public class VersionControl public String getfilehistory(string file, String revision, String username, String userpassword) { } throws vics.corba.verscntl.filenameexception, vics.corba.verscntl.revisionexception, vics.corba.verscntl.userverifyexception, IE.Iona.Orbix2.CORBA.SystemException // implementation 5

6 We then integrated calls for remote version control into the Java client software by obtaining a reference to an instance of the version control proxy class, then invoking methods on this object as if it were the real version control object: // Obtain versioncontrol object reference // Extract file revision history from remote version control try { String tempfile = versioncontrol.getfilehistory (filespec.name(), filespec.revision(), context.user().name(), context.user().password()); } catch (vics.corba.verscntl.filenameexception e) {.. // Handle all exceptions specified in the IDL definition. } // Get revision history contents via FTP Together with ORB-provided library software, the software generated by the IDL compilers handles all of the transport-level messaging and data marshalling required for conveying the remote method invocations between client and server. Configuration of the system required installing the server program on the server host, and registering it using the ORB. This registration was necessary so that client programs could look up a reference to the version control object s proxy. The compiled Java class files that made up the client Applets were installed on the WWW server host so they could be downloaded by a browser. An HTML file for each Applet was also installed on WWW server in the usual manner. Each such file refers to an Applet via the HTML APPLET tag, which specifies where the Applet executable files reside on a WWW server. The WWW browser uses this information to locate and download the Applet s class files. In the HTML excerpt below, codebase provides the URL where all of the Applet's classes can be found (in this case it is a relative URL), and code specifies the Applet class itself. This example also provides values for the Applet's initial dimensions, and some PARAMETER tags whose values can be read in by the Applet at runtime. <APPLET codebase=".." code="vics.client.viewfilehistory.class" width=550 height=500> <PARAM name="fileserverhost" value="vicsdev"> <PARAM name="versioncontrolhost" value="vicsdev"> </APPLET> 6

7 Deployment of the client software is automatic, as long as it is implemented as Applets. When the user opens a URL for an HTML file with an Applet tag, the browser downloads the Applet's executable Java class files, then runs the Applet under the control of its own Java runtime. When the Applet needs to request an operation on a server object, it invokes that operation on the object's proxy, which relays the request to the real object using CORBA protocols. In short, user sites need not install any executable or data files other than those for a Java-enabled browser. Results For our study we reimplemented a handful of different VICS operations using Java Applets and CORBA remote method invocation (referred to below as the Java/CORBA approach). In this section, we compare this approach with both the HTML forms/cgi approach and conventional client/server approaches (i.e., those that do not use WWW technology), with respect to the following criteria: Ease and flexibility of design and development Maintainability Ease and flexibility of server configuration Ease of client deployment Intuitiveness of user interface Responsiveness of user interface Use of standards vs. proprietary features Design and Development: The design and development of a Java/CORBA distributed application essentially follows the same process as for a CORBA-based client/server application. However, the design should take into account the fact that the client software is not pre-installed on the user's host. This might affect considerations such as whether the client should expect to find any context or configuration information in the user's local filesystem. On the other hand, Java/CORBA differs from the use of HTML forms and CGI (referred to below as the forms/cgi approach) in two areas: client/server interface and user interface (UI). With forms/ CGI, the client/server interface definition is coupled with the UI definition, since both are embodied in HTML tags. Each INPUT tag of a HTML FORM specifies a single argument value for the client/server operation defined by the FORM. The CGI server program that implements a FORM's operation receives these input arguments in the form of environment variables, so it must map them from strings to the actual types it needs. Another limitation is that these INPUT tag arguments cannot be structured data types. Finally, there is no way using HTML forms or CGI to invoke server operations in the background, i.e., without direct user interaction. Because of these limitations, forms/cgi applications are simple to develop as long they are only required to add simple user interaction to WWW pages. For more sophisticated operations, defining the client/server interface and developing the software is easier with the support of a CORBA ORB. The automatic source code generation provided by the ORB's IDL compiler eases development and ensures a level of consistency between a server and its clients. Since IDL has a complete set of primitive data types, there is no need for the server program to map its input arguments from strings to the needed types, and arguments may be defined as structured 7

8 types. Using CORBA also allows the client to make background requests on the server. In fact, since a Java Applet can be multithreaded, it is easy to have one thread continue to interact with the user via the UI while another thread makes a series of remote invocations on server objects. UI design and development is also more flexible using Java than with HTML forms. For one thing, the UI definition is not coupled with the client/server interface. For another, the client UI is defined in software using the Java window toolkit package java.awt. This standard set of window system component classes allows greater developer control over the UI design and layout than HTML forms, in which the WWW browser assumes many of the layout duties. Maintainability: A Java/CORBA application can be easier to maintain than a forms/cgi application for the same reasons that is it easier to design and develop. Its explicit IDL client/server interface definition makes changes to remote interactions easier to plan, and the automatic source code generation makes them easier to implement. Also, the object-oriented Java client source code is easier for developers to understand and modify than that for a large forms/cgi application, which usually consists of a combination of HTML forms and server programs (or scripts) that generate HTML forms. Since the client software is downloaded to a user s host on demand, Java/CORBA application upgrades are simpler to release than upgrades for conventional client/server applications. A new release of client software merely needs to be made available from the WWW server, instead of being manually installed. However, since some browsers cache Applet software the same way they cache HTML files, it might be wise to pass version information as operation arguments to ensure that users have up-to-date releases of the client Applets. A server detecting an old version number in an operation request could then raise an exception to the client (via CORBA), which could tell the user to download the new client Applet. Server Configuration: Traditional client/server applications often register their server programs so that they can be located (and, if necessary, executed) to serve client operation requests. Java/CORBA applications must also do this, using the mechanisms provided by the ORB. However, they differ from basic client/server applications in that the client software must also be made available at the server site so that the WWW server program can locate it and provide it to the WWW browser when requested. A Java/CORBA application must also make each Applet s HTML file available through the WWW server. In short, a Java/CORBA server configuration is like the combination of a conventional CORBA server configuration with a non- CGI WWW server configuration. Client Deployment: A Java/CORBA application exploits the traditional strength of WWW technology: all that must be installed at the user's host is a WWW browser. This makes its user interface as easy to deploy as that for a forms/cgi application. It is also considerably easier than for traditional client/server applications, since there is no need to pre-install client software or configuration files on each user s host computer. 8

9 UI Intuitiveness: As previously stated, Java/CORBA client software is developed in an object-oriented programming language with access to a standard window toolkit package. Therefore its UI can exploit traditional operating system-supported window components, such as those provided by Motif on UNIX systems, Windows on Microsoft operating systems, etc. This allows a Java Applet to provide a UI nearly as sophisticated as that a conventional client might provide, but with the added benefit of Java's platform independence. Java window toolkit classes are also much more flexible than the limited set of INPUT tags in HTML, which do not give the developer much control over component layout. For example, the Java window toolkit allows more than one window to be displayed at a time. This allowed our VICS Java/ CORBA Applets to display a base window with the same layout throughout a given operation, while pop-up windows presented the user with results, extra information, or optional input components. A forms/cgi application cannot use pop-up windows, and results or updates must be displayed by replacing the previous window in the browser. By using Java Applets as clients, we were able to provide user interfaces that were easier to understand and less frustrating to use than the HTML forms of the forms/ CGI version of VICS. Figure 2: HTML Forms Interface 9

10 Figure 3: Java Applet Interface For example, Figure 2 shows the two successive pages required for viewing an archived file s revision history using the current forms/cgi implementation of VICS. The user selects an archive file and submits the request using the first page, which is then replaced by the second page displaying the requested information (or another page displaying an error message if some problem occurred). Figure 3 shows the same operation using the Java/CORBA implementation. The Applet page still allows the user to select a file and request its history. However, the resulting file history information (or error message) is displayed in a separate pop-up window, which the user may dismiss by hitting its Close button. The Applet page remains on display as long as the user is viewing file histories. In this example, the user may display multiple simultaneous pop-up windows for different file histories, all selected using the same View File History Applet page. This page may also be used to display status messages as shown in Figure 3. UI Responsiveness: The UI of a Java/CORBA client Applet running under a browser should be comparable in responsiveness to the UI of a traditional client/server client program. However, early implementations of the Java runtime in WWW browsers make such Applets run noticeably slower than a fully-compiled client program does. Presumably this disparity will be reduced as faster Java runtime implementations are integrated into future browser releases. 10

11 Compared to the UI of a forms/cgi application, simple updates to the display are often faster since there is no need for a window to be re-generated by a CGI program and downloaded from the WWW server just to update it. Also, response messages over the network from server to client are typically more compact than in the forms/cgi approach, since they usually convey only the output argument values of an operation rather than entire HTML pages. Another problem with the forms/cgi approach is that the browser will time out and give up on an operation that takes too long to respond, leaving the user uncertain of the state of the requested operation. This is a frequent user complaint with the forms/ CGI version of VICS, especially for users at remote sites. However, the browser does not time out during a long CORBA operation from a Java Applet, since it is not involved in the request. The client Applet itself has control, and if it chooses to time out a remote invocation (or receives an exception from the ORB) it can notify the user, try to determine the state of the failed operation, and possibly even roll it back to the previous state. Another important advantage of the Java Applet client is that it may be multithreaded. A multithreaded client can be more responsive to the user than a forms/cgi page, since it can always keep one thread monitoring the UI components for user input, even while other threads are performing other duties. In the example of Figure 3, when the user submits a request by hitting the View File History button, the Applet spawns a separate thread to go retrieve the requested information from the server while the original thread goes back to waiting for user input. In this mode, only the Cancel button is enabled, and if the user hits it the main thread will stop the remote operation thread and clean up any loose ends. Standards: All three approaches rely on industry-accepted standards, such as Java, HTML, Hypertext Transfer Protocol (HTTP), CGI, CORBA Internet Inter-ORB Protocol (IIOP), and CORBA IDL. Related Issues: While implementing the new prototype VICS application using Java and CORBA, we encountered some issues that anyone considering early adoption of this approach should consider. One problem area was WWW browser support for Java Applets. As of this writing, most browsers still contain some considerable bugs in their Java runtime or Java API implementations. For example, Netscape Navigator 3.0 for Solaris does not correctly implement the standard Java GUI window component java.awt.dialog. Specifically, the call to show() on a modal Dialog instance does not properly block the calling thread. Nonetheless, we believe the strong market pressure from Java developers and users will drive browser vendors to fix such bugs promptly. Another near-term consideration is that the OMG has not yet standardized an IDL-to-Java language mapping. The current estimate for an official mapping is sometime in 1997 (formal proposals are due to the OMG by February 1997). This could force early adopters of the Java/CORBA approach to change some of their software when the standard mapping is finally approved. Nonetheless, the ORB vendors that currently support Java have each defined an IDL mapping, and their differences are relatively minor. 11

12 A thornier problem is that of Applet security. The Java language and runtime have built-in hooks for security. For example, whenever an Applet attempts certain security-sensitive actions through a Java API class, the method will first check with the Java runtime to determine whether an Applet is allowed to perform that action. Examples of such sensitive actions include accessing the filesystem of a WWW browser's host, or opening a network connection to another host. Some browsers that contain a Java runtime currently do not allow Applets to perform any of these actions, even if the browser s user may wish to allow them. These restrictions are intended to protect a browser user from unknowingly downloading a hostile Applet from an unfamiliar WWW site, which might then damage files in the user s local filesystem, attempt to break into other hosts inside the user site s firewall, and so on. While this policy may protect casual browser users who are surfing the Web, it severely limits the great potential of Java Applets for users of legitimate, trusted distributed applications. For example, it would prevent a VICS user from checking out a copy of a file from version control, because that operation requires that the client software be able to write the file copy to the local directory designated by the user. Because a VICS user must have an account before being allowed to invoke this operation, there is a trust relationship between the user and the VICS service provider. In such cases the user should be able to assume that the client Applets are not hostile. Fortunately, the upcoming 1.1 release of Java is supposed to allow users of Java-enabled browsers to specify local system access permissions for Applets from trusted sources. In this approach the supplier of an Applet, using a private key, signs its executable bytecode with a digital signature. The Applet s user may declare the supplier to be a trusted identity with a certain set of access privileges. When the user downloads the Applet, the Security Manager in the user s browser will use the supplier s public key to verify that the signed Applet is truly from that trusted identity, and allow it to perform the privileged actions. Finally, there is another approach under development that would allow the building of distributed applications using Java Applet clients: Java Remote Method Invocation (Java RMI). This is currently scheduled for the 1.1 release of Java. Its approach is basically the same as the Java/CORBA approach, with remote method invocation software being generated from an explicit client/server interface definition. However, it is not intended to support language-independent distributed objects. Both client and server software must be implemented in Java, running within Java virtual machines. This gives it some advantages over the Java/CORBA approach: There is no need for a special IDL; Java RMI merely uses the Java interface type to describe the methods of a remote object. Remote object servers needn t manage the deletion of object instances, since they can rely on Java s standard automatic garbage collection. The class software for objects passed as method arguments can be automatically downloaded to the receiver s runtime in the usual Java way, if it is not already present. Finally, the Java RMI development tools and virtual machine extensions will be part of the standard Java release, so there would be no need to license a ORB. Nonetheless, the lack of language-independence could be a drawback for applications that need to incorporate non-java legacy software. 12

13 Conclusions Based on our experience, we believe that the combination of CORBA and WWW-based Java Applets can be a good, practical framework for developing user-oriented distributed applications. Its advantages over conventional client/server approaches are that: The Java client software is installed on demand via the WWW infrastructure. The Java client software is independent of particular host architectures and operating systems; i.e., it will execute on any platform supported by a Java-enabled WWW browser. Its disadvantages with respect to conventional client/server approaches include: Client start-up may be slower, since some or all of the client Applet classes may need to be downloaded from the WWW server (though several WWW browser caching schemes are in use). Applet security restrictions won t be resolved until at least the Java 1.1 release. The client s state is at the mercy of the WWW browser, and there is no standard for what a browser does with an Applet when the user leaves the Applet s page, then returns to it later (it might pause the Applet then restart it, or it might destroy the Applet then recreate it). Its advantages over WWW applications based on HTML forms and CGI are that: The Java client software is object-oriented, with all its associated software engineering advantages. The Java client software can exploit a richer GUI toolkit, for more sophisticated UI design. Operations between client and server sides are explicitly defined in IDL. There is no need to write the software that conveys operation requests and responses between clients and servers; this is provided by the ORB. WWW servers are not involved in any operations between the Java clients and server objects. Its disadvantages with respect to forms/cgi applications include: Initial Java Applet download may be slower than that for an HTML page with forms. An ORB must be licensed and installed to support both development and execution. If you are about to embark on the development of a user-oriented distributed application, and you would like to exploit WWW infrastructure for easy deployment of the user interface, you could take either the currently popular forms/cgi approach or a distributed object approach like Java/CORBA. We recommend that you first clearly identify your application's requirements. Consider them carefully and decide whether they describe: (1) Hypertext-style information sharing, with some user input needed to support simple requests, or (2) A sophisticated set of server-based capabilities that users need to access remotely. If your requirements point more toward (1), then a forms/cgi approach may be adequate, and simpler. However, if you require something more like (2), then you should consider using a more flexible 13

14 and powerful remote invocation technology such as CORBA or Java RMI, combined with Java Applets deployed via the standard and widespread WWW. References [1] Object Management Group. The Common Object Request Broker: Architecture and Specification (OMG ), Object Management Group, Framingham, MA, [2] James Gosling, Henry McGilton. The Java Language Environment, Sun Microsystems, Mountainview, CA, [3] T. Berners-Lee, D. Connolly. Hypertext Markup Language - 2.0, Internet RFC 1866, November [4] D.R.T. Robinson. The WWW Common Gateway Interface Version 1.1, Internet Draft draft-robinson-www-interface-01.txt, IETF, February This is a working draft. Note This is a working draft. Copyright 1996, by Eric Evans and Daniel Rogers Eric Evans evans@arlut.utexas.edu Daniel Rogers drogers@arlut.utexas.edu Applied Research Laboratories The University of Texas at Austin 10,000 Burnet Road P.O. Box 8029 Austin, Texas