|Publication number||US6779172 B1|
|Application number||US 09/425,726|
|Publication date||Aug 17, 2004|
|Filing date||Oct 22, 1999|
|Priority date||Oct 22, 1999|
|Also published as||DE10050401A1|
|Publication number||09425726, 425726, US 6779172 B1, US 6779172B1, US-B1-6779172, US6779172 B1, US6779172B1|
|Inventors||Sanjiva Weerawarana, Matthew J. Duftler|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (6), Non-Patent Citations (2), Referenced by (16), Classifications (9), Legal Events (5)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention generally relates to Computer Aided Software Engineering (CASE) and, more particularly, a method for incorporating scripting into object oriented programming (OOP) applications and small programs called applets.
2. Background Description
OOP is the preferred environment for building user-friendly, intelligent computer software. Key elements of OOP are data encapsulation, inheritance and polymorphism. These elements may be used to generate a graphical user interface (GUI), typically characterized by a windowing environment having icons, mouse cursors and menus. While these three key elements are common to OOP languages, most OOP languages implement the three key elements differently.
Examples of OOP languages are Smalltalk, Object Pascal, C++, and Java. Smalltalk is actually more than a language; it might more accurately be characterized as a programming environment. Smalltalk was developed in the Learning Research Group at Xerox's Palo Alto Research Center (PARC) in the early 1970s. In Smalltalk, a message is sent to an object to evaluate the object itself Messages perform a task similar to that of function calls in conventional programming languages. The programmer does not need to be concerned with the type of data; rather, the programmer need only be concerned with creating the right order of a message and using the right message. Object Pascal is the language used for Apple's Macintosh® computers. Apple developed Object Pascal with the collaboration of Niklaus Wirth, the designer of Pascal. C++ was developed by Bjame Stroustrup at the AT&T Bell Laboratories in 1983 as an extension of C. Java, which was modeled after C++, was originally developed in 1991 as a language for embedded applications such as those used in set-top boxes and other consumer-oriented devices. In 1994, Sun Corp. transitioned Java to the World Wide Web. The key concept of Java and C++ is class, which is a user-defined type. Classes provide object oriented programming features. C++ modules are compatible with C modules and can be linked freely so that existing C libraries may be used with C++ programs. The most widely used object based and object oriented programming languages trace their heritage to Simula developed in the 1960s by O-J. Dahl, B. Myhrhaug and K. Nygard of Norway. Further information on the subject of OOP may be had by reference to Object Oriented Design with Applications by Grady Booch, The Benjamin/Cummings Publishing Co., Inc., Redwood City, Calif. (1991).
The Java platform currently does not have a well-defined scripting architecture that allows Java applications to incorporate scripting easily and in a uniform manner. The use of scripting will become even more important as scripting is fast becoming the next wave of software development. There are many advantages of having a standard scripting architecture. First, adopting a scripting architecture instead of an ad hoc approach to script integration and enabling allows applications to quickly and easily support many scripting languages. Script enabling products allows extensions to be written by a wider audience that includes non-programmers. Second, having a single scripting architecture for the platform enables scripting language developers to conform to the architecture once and be universally available to all applications. Finally, common services such as debugging services, which support all scripting languages can be developed.
It is therefore an object of the present invention to provide a method and system for incorporating scripting into Java applications and applets.
It is yet another object of the present invention to provide a method and system that allows the functionality of an application to be modified or enhanced.
The Bean Scripting Framework (BSF) is an architecture for incorporating scripting into Java applications and applets. The BSF provides a set of interfaces that let developers add language-independent scripting to their applications. The invention incorporates scripting into Java applications by using two main components, the BSFManager, and scripting engines.
The BSFManager lets end users write scripts in the scripting languages they like best without burdening the application with language specific knowledge. The BSFManager supports both directions of scripting; that is, when the Java-side is in charge and runs and evaluates scripts at will, as well as cases where the script runs and controls Java beans.
The BSF works with any Java object, and not just a true bean. Script enabling Java applications enables those applications to be customized and managed further downstream than previously possible. That is, currently, once a Java application is built and delivered to an end-user or an Independent Software Vendor (ISV), they cannot modify or add to the functionality of the application conveniently. Some applications allow this by having precise extensiblity Application Programming Interfaces (APIs) which ISVs may use. However, ISVs must also use Java in that case to customize the applications. If the application used BSF, then it can expose the appropriate functionality for extensiblity via BSF. ISVs and others may then configure and modify the application using any BSF-supported scripting language. There are two significant advantages with this approach. First, application customization can be done with the customizer's language of choice (assuming it is supported by BSF). Second, the application does not need to do any additional work to support all the BSF-enabled languages. That is, the application becomes scriptable from all the BSF languages without any application burden.
The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
FIG. 1 is a block diagram illustrating the principal components of the preferred embodiment of the present invention when the scripting engine is implemented in Java;
FIG. 2 is a block diagram illustrating the interaction between the implementation of the BSFEngine interface and a scripting engine when the scripting language is not implemented in Java;
FIG. 3 is a logical flow diagram illustrating the process of integrating a new scripting language to BSF;
FIG. 4 is a logical flow diagram illustrating the process of making application components available for scripting by BSF supported languages;
FIG. 5 is a logical flow diagram illustrating the process of loading a scripting language to the BSF;
FIG. 6 is a logical flow diagram illustrating the process of running scripts from an application by loading specific engines;
FIG. 7 is a logical flow diagram illustrating the process of running scripts from an application via the BSFManager;
FIG. 8 is a logical flow diagram illustrating the process of interacting with Java from scripts for Java-based scripting engines; and
FIG. 9 is a logical flow diagram illustrating the process of interacting with Java from scripts for non-Java based scripting engines.
The detailed description is provided in terms of an implementation in the Java programming language. However, the invention can also be practiced using other suitable programming languages.
Scripting engines 103 must implement the BSFEngine interface 104 to become part of the BSF architecture. The BSFEngine interface 104 is the abstraction that the BSF architecture uses to interact with the scripting engines 103, 200. The interaction between the scripting engine and the BSFManager 102 consists of calls from the BSFManager 102 to the BSFEngine interface 104 to evaluate and execute scripts and calls from the BSFEngine interface 104 to the BSFManager 102 to look up, register and unregister application objects. If the scripting engine 200 itself is not implemented in Java, then the implementation of the BSFEngine interface 104 interacts with the scripting engines 200 using the Java Native Interface (JNI). FIG. 2 illustrates this case.
The application 101, consisting of the collection of objects (107, 108, 109, 110, 111) interacts with the BSFManager 102 or with the BSFEngine objects directly.
FIG. 2 is a block diagram illustrating the principal components of the preferred embodiment of the present invention when the scripting engine is not implemented in Java. FIG. 2 is almost the same as FIG. 1, except that the scripting engines 200 run outside of the JVM 100.
FIG. 3 is a logical flow diagram illustrating the process of integrating a new scripting language to the BSF. The first step is to implement the BSFEngine interface 104, as shown in block 301. Specifically, the BSFEngine interface 104 enables each scripting engine 103, 200 to interact with the BSFManager 102 and the application 101. In step 302, the BSFEngine interface 104 must implement functionality in the language to interact with Java, primarily to allow the script author to access the object registry 106 and then to perform operations on objects (107, 108, 109, 110, 111) accessed via the object registry 106. In step 303, the implementation of the BSFEngine 104 must be registered with the scripting engine registry 105 of the BSFManager 102, thus completing the process of integrating a new engine to BSF.
FIG. 4 is a logical flow diagram illustrating the process of making application objects (or components) 107, 108, 109, 110, 111 available for scripting. As shown in block 401, the first step is to identify the application components (beans) that are to be made available for scripting. The components are typically identified manually by deciding what functionality of the application is to be made available for scripting. This process is similar to designing the external application programming interfaces (APIs) of an application. In decision block 402, a test is made to decide whether this bean is to be made available in scripting languages as a pre-loaded bean (i.e., one where the user does not have to explicitly load it) or simply as a registered bean. If the bean is not already registered, the bean is registered into object registry 106, as shown in block 403. If the bean is already registered, then the bean is inserted into the BSFManager's vector of declared beans to be forwarded to each scripting engine 103, 200 when they are loaded, as shown in block 404. In step 405, the process terminates.
FIG. 5 is a logical flow diagram illustrating the process of loading a scripting language to the BSF. In decision block 501, a test is made to determine whether the language is already loaded to the requestor. If so, that engine is returned to the requester in block 502. If not, another test is made in decision block 503 to determine whether the language is registered with the scripting engine registry 105 of the BSFManager 102. If not an error is returned in block 508. If yes, the scripting engine for that language is loaded in step 504, and subsequently initialized in block 505. Initializing a scripting engine consists of informing the engine of all the declared application objects from vector 112. In decision block 506, a test is made to determine whether the initialization was successful. If the initialization was not successful, an error is returned in 508. If yes, the fact that the engine was loaded is recorded in the scripting engine registry 105 of the BSFManager 102 in block 507. Then, in block 502 that engine is returned to the application program.
FIG. 6 is a logical flow diagram illustrating the process of loading a scripting engine and running a script from an application. First, in block 601, an instance of a BSFManager 102 is created. In block 602, any application components (107, 108, 109, 110 and 111) that are to be made available for scripting are made available using the process illustrated in FIG. 4. In block 603, the desired scripting language is loaded into the BSFManager 120 using process illustrated in FIG. 5. In block 604, the desired scripts are executed using the appropriate method of the BSFEngine 104, Finally, in block 605 the result, if any, of executing the script is returned to the requestor.
FIG. 7 is a logical flow diagram illustrating the process of running scripts from an application directly using the BSFManager. First, an instance of a BSFManager 102 is created by the application program in block 701. In block 702, any application components (107, 108, 109, 110 and 111) that are to be made available for scripting are made available using the process illustrated in FIG. 4. In block 703, the desired scripts are executed using the appropriate method of the BSFManager 102. In decision block 704, a test is made to determine whether the script language has been specified. If not, the language is determined in 705. If yes, or after block 705, the scripting engine 103, 200 is loaded into the BSFManager 102, as shown in block 706. In block 707, the desired scripts are executed using the appropriate method of the BSFEngine interface 104, Finally, in block 708 the result, if any of executing the script is returned.
FIG. 8 is a logical flow diagram illustrating the process of interacting with Java from scripts for Java-based scripting engines. In decision block 801, a test is made to determine whether the interaction is with an existing object (107, 108, 109, 110, 111). If yes, the object is looked up from object registry 106 of the BSFManager 102, as shown in block 802. If not, a new object is created in block 803. The appropriate bean operation is performed by the application program in block 804, where the valid operations arc setting and getting properties, calling methods and binding events to scripts. The result, if any, of the operation is returned in 805.
FIG. 9 is a logical flow diagram illustrating the process of interacting with Java from scripts for non-Java based scripting engines. In decision block 901, a test is made to determine whether the interaction is with an existing object (107, 108, 109, 110, 111). If yes the object is looked up from object registry 106 of the BSFManager 102, as shown in block 902, and a reference to the object is returned to the scripting engine 200. If no, a new object is created in block 903, and a reference to the new object is returned to the scripting engine 200. In a preferred embodiment, the object references returned to non-Java scripting engines 200 are opaque handles, that are of a valid type and value for the scripting language, and which bean operation functions can identify as being references to actual Java objects. The appropriate bean operation is performed in block 904 using the Java Native Interface (JNI), where the valid operations are setting and getting properties, calling methods and binding events to scripts. The result, if any, of the operation is wrappered up into a type that is acceptable to the scripting engine 200, as shown in block 905 and returned in block 906.
The following code samples show the steps involved with incorporating the BSF into an application:
Lines 1-5 above declare and create a BSF manager.
Lines 6-9 above register any new scripting language.
Lines 10-12 above register or declare any beans to be made available to scripting engines with appropriate names. Note that any Java object (i.e. any bean) can be made available for scripting. There is no need for the object to implement any specific interface.
Line 13 may be used to load any desired scripting engine.
Lines 14-16 call functions in the script or evaluate/execute arbitrary scripts.
Lines 17-18 show an example where the BSF manager can run any script directly.
While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6078743 *||Nov 24, 1997||Jun 20, 2000||International Business Machines Corporation||Generic IDE interface support for scripting|
|US6237135 *||Sep 11, 1998||May 22, 2001||Borland Software Corporation||Development system with visual design tools for creating and maintaining Java Beans components|
|US6256772||Nov 24, 1997||Jul 3, 2001||International Business Machines Corporation||Multilingual hierarchial scripting environment|
|US6289395 *||Nov 24, 1997||Sep 11, 2001||International Business Machines Corporation||Generic Java-based event processor for scripting Java beans|
|US6292936 *||Nov 12, 1998||Sep 18, 2001||International Business Machines Corporation||Enabling multiple runtime processors in an interpreter-based embedded scripting system|
|US6662236 *||Jun 29, 1998||Dec 9, 2003||International Business Machines Corporation||Runtime object binding in scripting|
|1||*||Herbal-T Enabling Integration, Interoperability, and Reusability of Internet Components, Israel Hilerio and Weidong Chen, (C) 1999 pp. 49-58.|
|2||Herbal-T Enabling Integration, Interoperability, and Reusability of Internet Components, Israel Hilerio and Weidong Chen, © 1999 pp. 49-58.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7000221 *||Jul 31, 2002||Feb 14, 2006||International Business Machines Corporation||Script evaluator|
|US7152222 *||Jan 8, 2002||Dec 19, 2006||International Business Machines Corporation||Method and system for localizing Java™ JAR files|
|US7885950||Dec 22, 2009||Feb 8, 2011||Microsoft Corporation||Creating search enabled web pages|
|US7945849||Mar 20, 2007||May 17, 2011||Microsoft Corporation||Identifying appropriate client-side script references|
|US7971194 *||Jun 16, 2006||Jun 28, 2011||Sap Portals Israel Ltd.||Programming language techniques for client-side development and execution|
|US7992130 *||May 7, 2007||Aug 2, 2011||Microsoft Corporation||Class-based object-oriented features in class-less script language|
|US8316347||Dec 5, 2008||Nov 20, 2012||International Business Machines Corporation||Architecture view generation method and system|
|US8332813 *||Dec 11, 2008||Dec 11, 2012||International Business Machines Corporation||Service re-factoring method and system|
|US8490117||Jul 5, 2007||Jul 16, 2013||Adobe Systems Incorporated||Bridging script engines|
|US8627216 *||Oct 5, 2009||Jan 7, 2014||Adobe Systems Incorporated||Rendering hypertext markup language content|
|US8762976 *||Mar 9, 2007||Jun 24, 2014||Microsoft Corporation||Static extensibility models with dynamic languages and scripts|
|US8775481||Apr 17, 2012||Jul 8, 2014||International Business Machines Corporation||Re-establishing traceability|
|US20050138643 *||Dec 18, 2003||Jun 23, 2005||Denny Jaeger||System and method for controlling a computer operating environment using a scripting language-based computer program|
|US20050235258 *||Apr 20, 2004||Oct 20, 2005||International Business Machines Corporation||Method, plug-in and program product for customizing java bean properties|
|US20100153914 *||Dec 11, 2008||Jun 17, 2010||Arsanjani Ali P||Service re-factoring method and system|
|US20130227532 *||Nov 21, 2012||Aug 29, 2013||Pantech Co., Ltd.||Application generation system and method for generating an application|
|U.S. Classification||717/115, 719/320, 717/108, 717/118, 717/107|
|Cooperative Classification||G06F9/45504, G06F9/44526|
|Oct 22, 1999||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WEERAWARANA, SANJIVA;DUFTLER, MATTHEW J.;REEL/FRAME:010337/0917
Effective date: 19991021
|Sep 19, 2007||FPAY||Fee payment|
Year of fee payment: 4
|Apr 2, 2012||REMI||Maintenance fee reminder mailed|
|Aug 16, 2012||FPAY||Fee payment|
Year of fee payment: 8
|Aug 16, 2012||SULP||Surcharge for late payment|
Year of fee payment: 7