Distributed, parallel web service orchestration using

XSLT

Peter Kelly

Paul Coddington

Andrew Wendelborn

Clusters vs. Grids

What is the difference?

Clusters vs. Grids

What is the difference?

Conceptually… none!

Programming models

Clusters – Parallel programming Typically use message passing libraries e.g. MPI Goal is to parallelise program to gain improved performance Work to be done is split up into different tasks which

communicate with each other

Grids – Service composition Service Oriented Architecture (SOA) – collection of machines on

a grid each providing a set of services High-level programs are written by composing the functionality of

different services together Multiple service calls can be in process at one time - parallelism

Service Composition Approaches

Mainstream languages – Java, C++ etc. Imperative programming style. Parallelism using threads Written as text-based source code Very powerful

BPEL (Business Process Execution Language) Imperative language. Parallelism using “flow” statements. Limited expressiveness; cannot develop complex application logic XML-based syntax is verbose and awkward to work with

Workflow languages Based on a graph notation Constructed using a graphical tool Parallelism is implicit in the model Difficult to write large/complex programs in

Our goals

We wanted to develop a language implementation that:

Allows web services to be easily accessed, developed, and composed

Supports the full range of abstraction/granularity – can develop lightweight service compositions or large scale, data intensive, high performance parallel programs

Allows complex workflows to be developed using various control constructs

Provides automatic parallelisation of code Integrates well with the web services technology stack Is suitable for use on both clusters and grids, and in fact makes

no distinction between them

XSLT

Instead of creating a new language, we chose to develop a new implementation of an existing one – XSLT.

XSLT (Extensible Stylesheet Language Transformation) Designed for processing XML data Uses XML schema as its type system; fits in well with format used

for web service request and response types Functional language – side effect free, single assignment, which

lends itself to automatic parallelisation Sizable existing developer community W3C standard

http://www.w3.org/Style/XSL/

Dataflow computation

We achieve parallelism by using the dataflow model of computation to execute programs

Before execution, the XSLT source code is parsed and compiled into a dataflow graph which represents the operations and flow of data within the program

A graph consists of nodes corresponding to operations, and edges connecting the operations together

When a node receives input tokens on each of its edges, it fires, producing a result which is sent to subsequent nodes in the graph

3

4

* +

5

Distributed execution

There are two types of graph nodes

Built-in operations Correspond to internal functions within the interpreter Can only be executed on a machine running the GridXSLT engine Examples: add/subtract, substring, if, map, create element

Web service calls Correspond to operations provided by a web service Actual call is executed on the remote machine Host running the GridXSLT engine acts as a “client” to invoke the

service Associate a namespace with a WSDL URL to designate certain

function calls as web service requests

Distributed execution

Service

Execution host

Execution host Execution host

Service host

Other features

Exposing XSLT programs as web services Similar to use of Perl or PHP for web applications Just place the file on the server; it will take care of on-the-fly

interface generation (WSDL) and argument/result serialization XML Schema types defined within the XSLT program are

included in the WSDL; no type system mismatch present with other languages

Much simpler than Java; no need for complex procedure for packaging/deploying services

Condensed language syntax Like BPEL, XSLT uses an XML-based syntax; awkward and

cumbersome to write code in We provide an alternative syntax which maintains the same

language features but in a more concise manner

Language syntax

<xsl:function name="f:calcprice" as="xs:float"> <xsl:param name="cost" as="xs:float"/> <xsl:param name="tax" as="xs:float"/> <xsl:param name="customer" as="xs:string"/> <xsl:choose> <xsl:when test="$customer = ’exempt’"> <xsl:value-of select="$cost"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="$cost * (1 + $tax)"/> </xsl:otherwise> </xsl:choose></xsl:function>

float calcprice(float cost, float tax, string customer){ if ($customer = ’exempt’) $cost; else $cost * (1 + $tax);}

StandardXSLT

CondensedSyntax (“XSLiTe”)

Service composition - example

function doSearch(var $searchterms)

{

namespace ri "reverse_index.wsdl";

namespace fi "forward_index.wsdl";

var $matches =

for $t in $searchterms

return ri:lookup($t);

var $distinct =

distinct-values($matches);

%resultset {

#size(count($distinct));

for-each ($distinct) {

%result {

#uri(.);

fi:getmetadata(.);

%abstract {

substring(fi:getcontent(.), 0,1000);

} } } }

loop

loop

Service composition - example

0fi:getcontent

substring

1000

fi:getmetadata

mkelem(abstract)

mkelem(result)

mkelem(resultset)

mkattr(size)

count

distinct-values

searchterms

ri:lookup

loop

loop

Project status – work to date

Most of the infrastructure for the language support is in place Parsing of XML Schema, XSLT, and XPath/XSLiTe code Compilation of XSLT into dataflow graphs Dataflow execution engine (sequential implementation only) Most major language constructs Many built-in functions and operators Regression testing and development tracking systems Basic HTTP support Capable of executing simple XSLT programs

Main aspects still remaining to be implemented (still in the design phase) Distributed execution Web services support

These both rely on a working implementation of the language, which is what most of the effort has gone into so far. The compiler and execution model have been designed around the dataflow model to enable this to be extended for distributed execution.

Conclusion

GridXSLT is an implementation of XSLT which provides support for distributed execution and web services development

Additional functionality done at implementation level – no changes to language required

Lack of side effects allows automatic parallelisation We have also provided the additional option of using a condensed

version of the language syntax, to ease the task of writing large programs

Supports development of applications for clusters and grids

For further info: http://gridxslt.sourceforge.net pmk@cs.adelaide.edu.au