JXPL: An XML-based Scripting Language for Workflow Execution in a Grid Environment

1. Networking and Distributed Systems Carla S. Hunt and Clayton S. Ferner Department of Computer Science Jeffrey L. Brown Department of Mathematics University of North Carolina at Wilmington JXPL: An XML-based Scripting Language for Workflow Execution in a Grid Environment

2. Presentation Contents: • Introduction • Motivation for JXPL • Characteristics from the Lisp language that influenced JXPL's design • The role of XML • Syntax including a grammar for JXPL in Extended Backus-Naur Form (EBNF) • Specifics about some of JXPL's functions • Conclusions, current and future work

3. Introduction: Grid Computing • Offers users access to computing resources such as processing cycles, software, data storage, etc., in a seamless environment • Also offers universities,corporations and other organizations a way to make better use of under-utilized resources • Grid computing technologies are still emerging; one area of research is user interface development including grid portals and workflow editors

4. Introduction: GridNexus • An example of a workflow editor • A graphical user interface capable of integrating web and grid services into a workflow • Generates JXPL scripts to describe graphical workflows, which can then be executed by a JXPL interpreter

5. Introduction: JXPL • A new functional scripting language • Uses XML syntax; Lisp-like design • A workflow language designed to interact easily with web and grid services • Has built in web and grid service clients that can communicate with a variety of web and grid services • Not intended to be written by programmers, but generated by applications

6. Introduction: Purpose of the paper • To encourage developers to create applications that generate JXPL as a means of executing scientific workflows capable of interacting with web and grid services • To serve as a reference to anyone desiring to create new applications that can produce JXPL

7. Motivation for JXPL: • To separate the graphical component of a workflow editor from both the representation of the workflow as well as the execution of the workflow • This separation simplifies the implementation of the GUI • Allows workflows to be executed on processors other than the local processor • Makes it possible for other tools besides GridNexus to create JXPL

8. Motivation for JXPL (Cont): • Ability to shield the user from much of the complexity associated with using web and grid services • The JXPL interpreter can be invoked via a URI, which allows users to decide where units of work are computed • JXPL can manage the interaction between Grid Data Services, which are a special type of Globus Toolkit 3 (GT3) service

9. JXPL is a functional scripting language with a Lisp-like design In both languages: • Everything is either an Atom or a List • Lists contain Atoms or other Lists, which allows for nesting of data structures • The list data object can be used to define programs, data structures, and functions

10. JXPL scripts are written in XML • The parentheses of Lisp are replaced by more descriptive XML tags • Being written in XML, JXPL is compatible with XML-aware programs, protocols and parsers • The XML format makes it easy for programs to generate JXPL • Representing JXPL objects as XML elements facilitates a high level of abstraction

11. JXPL scripts are written in XML (Cont) Removing object typing concerns from the programming model is analogous to a pure Lisp implementation providing advantages such as: • Ability to nest and evaluate recursively • Making it possible to accurately depict dependencies between tasks in a workflow • Especially useful in a graphical workflow environment where workflows are naturally nested

12. JXPL scripts must be well-formed XML documents: • Must contain a root element, the JXPL expression • Use the namespace, http://www.jxpl.org/script • All elements must have closing tags, are case sensitive, must be properly nested, and attribute values must be quoted

13. Extended Backus-Naur Form (EBNF) for the JXPL language We use the following conventions in the JXPL grammar: x|y means one of either x or y, {x} indicates zero or more occurrences, [x] indicates zero or one occurrence, terminals are underlined and non-terminals are capitalized.

14. Simple JXPL example to demonstrate the grammar • The primitive construct is used to describe a function call • This example uses the function named Arithmetic • The function is called with one property named operation with a value of multiply and two operands which are the rational numbers 7/5 and 3/11

15. JXPL Simple Types • Correspond to Lisp Atoms and include symbols, strings, integers, rationals, decimals and function names • No explicit Boolean type; false is an empty list and everything else is true • A JXPL symbol (like the Lisp symbol) is a multipurpose element that can legally represent the number ten, the string value “ten”, a function named “ten” or a variable named “ten” • There are three defined numeric types: integer, decimal and rational

16. JXPL Primitives • The JXPL primitive is analogous to a function • The primitive tag is used to call a function • The syntax of a function call with a primitive tag is: <list> <primitive name=”function name”> properties </primitive> arguments </list>

17. JXPL Primitives: Defun • Defun is a predefined function that allows users to define their own functions • The syntax of Defun is: <list> <primitive name=”Defun”/> <symbol value=”function name”/> <list> parameters </list> function body </list>

18. Using Defun to define the Myadd function

19. JXPL Primitives: WS Client • This function is designed to be a generic function for a web service • To use the Web Service Client, the Web-Services Description Language (WSDL) is needed to generate a call to the appropriate method of the web service • The arguments to the WS Client are the WSDL, the name of the method of the service to be called, and any arguments needed to call that method

20. WS Client Example • Below is the JXPL script that is produced for a simple web service called MyMath <list> <primitive name=”.ws.WSClient”/> <string value=”http://server.domain:port/MyMath.jws”/> <string value=”squared”/> <integer value=”2”/> </list> • In this example, the client requests the squared method with an argument of 2 from the MyMath web service, a result of 4 is returned

21. JXPL Primitives: Prog • XML files have a single root element restricting JXPL scripts to a single workflow • The Prog function was created so that multiple workflows could be combined into one script • The Prog function accepts a list of lists, evaluates each sublist in order and returns the result of evaluating the last list

22. JXPL Primitives: Prog properties (Cont) • A name property identifies the URI of the JXPL interpreter that should execute its sublists • A fork property indicates that the current interpreter should create a new thread to execute its sublists • In order to synchronize multiple threads, a waitfor property takes the URI name of another Prog whose termination must precede the evaluation of the current Prog

23. Conclusions • JXPL is an XML-based scripting language inspired by Lisp • JXPL is currently used by GridNexus, a graphical workflow editor developed at UNCW • Our paper was written to provide a specification for JXPL • We wish to encourage others to use JXPL and to create applications that can use JXPL

24. Conclusions (Cont) JXPL has several nice features: • Execution is separate from the graphical interface allowing for batch mode and parallel execution • JXPL is based on Lisp making it elegantly simple and easily extensible • JXPL uses XML so that it can easily be transmitted using SOAP • Different parts of a workflow can be executed by different processors using different communication protocols (OGSA, RMI, or HTTP) • The JXPL interpreter is written in Java making it easily portable to other platforms

25. Current and Future Work • Each of JXPL's features lead up to another feature, JXPL's ability to make use of available and idle processors • We are in the process of experimenting with this, using JXPL to run a primality prover based on a deterministic polynomial time algorithm by Agrawal, Kayal and Saxena • Using 34 idle machines running XP, we have been able to prove the primality of a 25 digit number in 1 minute, a 50 digit number in 15 minutes, and an 80 digit number in 5 hrs and 40 minutes

26. Current and Future Work (Cont) • Changes to WSRF? • Getting ready for open source?

27. Acknowledgements • This work is supported in part by the University of North Carolina Office of the President, UNC Wilmington's Information Technology Systems Division, and the National Science Foundation under Grant No. DBI0234520. • Questions?