A Method for Providing Program Interoperability for End–Users Roderick Moten Department of Computer Science Colgate University, Hamilton, NY
[email protected]
Abstract In this paper, we present an overview of a method for providing program interoperability at the end–user level. Using our method, developers can make their applications capable of supporting end–user program interoperability independently of any operating platform or implementation language.
1. Introduction Program interoperability is the capability of one program to utilize the features of another program. Program interoperability can be achieved at two levels, the programmer level or the end–user level. Program interoperability at the programmer level is achieved by integrating the runtime environments of a program under development and an existing program. Program interoperability at the end–user level allows an end-user to configure a collection of server applications into a new application by using a mechanism to automatically supply input to the server applications. Therefore, end–user program interoperability is achieved by integrating the end–user interfaces of one or more applications to be controlled by an agent, a script, or some other user interface. CORBA [7] and COM [11] are two popular technologies that facilitate program interoperability at the programmer level. However, we believe that they are too technical to be used for interoperability at the end–user level. If designers of an application made all the end–user commands of the application methods accessible through CORBA and COM, in order to invoke those commands, one would have to write a program in a language that supported CORBA or COM object model. This sort of programming does not constitute end–user programming. To make easier to write programs that invoked routines in external applications via COM, Microsoft developed Visual Basic. Programming in This work was supported in part by NSF grant CCR-9912349
Visual Basic, however, does not constitute end–user programming either. To achieve end–user program interoperability, a facility is needed that provides a common interface by which a client application can send commands to server applications. AIDE [10] and AppleScript [1] provide environments in which client applications can issue commands to server applications as high–level events. In addition to a facility for client applications to issue command to server applications, applications have to be implemented in a manner that allows them to receive commands according to the representation and protocol specified by the facility. In this paper, we give an overview of the applications– as–interpreters paradigm, a methdod for designing applications to enable them to support end–user program interoperability that is independent of the facility for providing end–user program interoperability, the platform on which the applications run, or the programming languages in which the applications are implemented. The applications– as–interpreters paradigm involves constructing a domain– specific language (DSL) from a subset of commands and objects of the application using the approached specified in [4]. Therefore, the DSL would be designed to consist of two sets of constructs. One set of constructs would represent the commands and objects that the application wants to make accessible to clients. The other set of constructs would represent operations that combine several operations into a single operation, such as a generic conditional or a construct that performs iteration in a manner unique to the application. Under the applications–as–interpreters paradigm, all clients of an application would use programs to issue commands to the application. A client could be a script developed by an end–user, an agent, or a UI. The programs sent from a client to the application and the data sent to the client from the application would be encoded symbolically. The program and data would be expressed in the abstract syntax of the DSL. An application can either define the language for representing the abstract syntax itself or use a meta-language, such as XML, the Nuprl term lan-
guage [3], or higher–order abstract syntax [9]. In any case, the application has to make known the definition of its language to its clients. This can be done informally by posting its language definition on the Web or some other publicly accessible place. Alternatively, we can use a systematic method similar to the approached used in [6]. An application also has to specify a means of communicating with its clients. An application could device its own protocol built on top of TCP/IP or it can use an existing protocol, such as HTTP or AppleScript, and device a scheme for encoding DSL programs within these protocols. The application will also need to contain an interpreter for evaluating programs sent to it from clients. The interpreter could be implemented using the various methods for implementing DSL interpreters, such as the technique described in [2]. A client is any program that is capable of generating programs in a server application’s DSL, sending the programs to the server application, and receiving feedback from the server application. Therefore, a client could be an agent, such as a program–by–demonstration system [5, 8]; a script processor which generates application specific programs as the result of executing scripts; or directly manipulated interface that generate programs instead of invoking callbacks for handling high–level events. As an example of how the applications–as–interpreters paradigm facilitates end–user program interoperability consider the following. Suppose a lawyer uses two applications that have been designed as interpreters of DSLs. The DSLs consist of constructs representing the commands users invoke on the applications and the data elements used as arguments of the commands and the data elements that are responses to invoking a command. Suppose the first application helps the lawyer maintain a household budget. The budget application organizes household expenses into accounts. Each account represents a category of household expenses, such as utilities, rent, and automobile fuel. The budget application has a built–in account that represents the available cash a household may have that could be transferred to other accounts. The budget application has commands for transferring an amount from one account to another account, crediting all the accounts their monthly allotments, and printing the balances of all the accounts. The second application allows bank customers to access their accounts online. The bank application has commands for logging onto the bank server, determining whether a specific check was paid, and obtaining the deposits made during a specific time period. Suppose a lawyer gets paid by his law firm once a month. His monthly pay consists of a flat salary plus bonuses. Therefore, his monthly pay varies from month to month. The lawyer is paid by direct deposit and is paid on the 25 th of each month. Suppose the lawyer wants to create an application to automatically obtain the amount he was paid for the month, add that amount to the built–in
available cash account in the budget application, and automatically credit all the accounts their monthly allotments. If the applications are implemented to function as interpreters as DSLs, then the lawyer could use the following script to perform the above. send bank app login prog send bank app prog to list deposits for 25th of current month [user provides the month] receive list of deposits [result list looks as follows (). only one deposit on the 25th of a month] get the amount of deposit send budget app a prog that - adds amount of deposit to cash fund - credits accounts with monthly allotment - prints balances of each account We envision end–users creating scripts or agents with the assistance of a proof–by–demonstration (PBD) system. The PBD will act as a liaison between the UIs and the applications: The transmission of programs and data would be routed through the PBD (see Figure 1). As a result, the PBD will know all the commands a user issues to an application and will be able to examine data produced from executing a command. With the applications–as–interpreters paradigm, developers can make existing applications defined to support programmer–level program interoperability capable of supporting end–user program interoperability. To achieve end– user program interoperability, a DSL is created that represents the commands and objects that the application wants to make accessible to clients. The routines that implement these commands are accessible from another program via the facility that provides programmer–level program interoperability, such as COM or CORBA. An interpreter is built as a separate program to evaluate programs of the DSL sent to it from clients. The interpreter uses the facility that provides programmer–level program interoperability to invoke the necessary routines in the application when evaluating a program sent to the interpreter by a client. A similar technique can be used to make existing facilities for end– user program interoperability platform independent and language independent. A drawback of the applications–as–interpreters paradigm is language bloat. Each application can define its own language. Thereby, each client would have to know a different language to interact with each application. This problem is also prevalent in existing environments that provide end–user program interoperability. In existing environments, however, language bloat is reduced by requiring that all commands be expressed in a common
User
UI UI
UI
here to the rules determined by AppleScript for representing data and commands to a client. We envision a less restrictive method for encoding data using an untyped meta–language, such as XML or the Nuprl term language, in which an application has the freedom to determine how data will be represented symbolically.
References
data
prog
PBD data
App
prog
App
Figure 1. Pictorial Overview of The Role of PBD Systems in Applications–as– Interpreters Paradigm
syntax. Language bloat can be minimized by using a meta–language for the syntax. As a result, all DSLs would use the same language for encoding programs and data. However, using a common syntax for all DSLs does not rectify requiring the client to know the semantics of the language of each application. Because each application has its own set of features unique to the application, there is no way we can use a single semantics for all applications. In addition to language bloat, the performance of an application can be negatively affected by implementing it as a DSL interpreter. Performance could be affected by performing symbolic computation to carry out commands and marshaling and unmarshaling data to and from its symbolic representation and its internal representation. We can minimize the need for marshaling by using a technique in which large data structures are represented as raw data or as unique identifiers inside DSL programs. The DSL can contain constructs for manipulating instances of these data structures. AppleScript uses a similar technique. In AppleScript, however, an application does not have the freedom to determine how it will represent its objects. An application has to ad-
[1] Apple, Inc. Applescript . http://www.apple.com/applescript. [2] C. Consel and R. Marlet. Architecturing software using a methodology for language development. In Proceedings of the 10th International Symposium on Programming Languages, Implementations, Logics and Programs PLILP/ALP ’98, Sept. 1998. Invited paper. [3] R. Constable. The structure of Nuprl’s type theory. In H. Schwichtenberg, editor, Logic of Computation, pages 123–156. Springer, 1997. [4] P. J. Landin. The next 700 programming languages. Communications of the ACM, 9(3):157–166, 1966. [5] H. Lieberman. Integrating user interface agents with conventional applications. Knowledge–Based Systems Journal, 11(1):15–24, 1998. ACM Conference on Intelligent User Interfaces. [6] R. Moten. ConXsys: A framework for a federation of electronic product catalogs. In Proceedings of the Second International Conference on Internet Computing (Vol II), pages 1021–1027, 2001. [7] R. Otte, P. Patrick, and M. Roy. Understanding CORBA: The Common Object Request Broker Architecture. Prentice Hall PTR, Upper Saddle River, NJ, 1996. [8] G. W. Paynter and I. H. Witten. Domain–independent programming by demonstration in existing applications. In H. Lieberman, editor, Your Wish is My Command: Programming by Example, pages 298–320. Morgan Kaufmann, 2001. [9] F. Pfenning and C. Elliott. Higher-order abstract syntax. In Proceedings of the ACM SIGPLAN ’88 Symposium on Language Design and Implementation, pages 199–208, June 1988. [10] P. P. Piernot and M. P. Yvon. The AIDE project: An application–independent demonstrational environment. In A. Cypher, editor, Watch What I Do: Programming by Demonstration, pages 383–401. MIT Press, 1993. [11] R. Sessions. COM and DCOM : Microsoft’s Vision for Distributed Objects. Wiley Computer Publishers, New York, 1998.
