A Simplified Approach to Web Service Development Peter Kelly Paul Coddington Andrew Wendelborn

Development of Web Services Most popular languages used today really aren’t suited to network programming Why? Designed originally for standalone machines Remote method invocation treated as a “special case” and not built in to the language implementation Data structures don’t translate well to pass-by-value semantics used by web services Programmers have to deal with network errors themselves Little in the way of abstraction

Object-oriented languages Examples: Java, C++, C# Features Powerful languages for implementing application logic Widespread usage – today’s dominant programming model Drawbacks Pass by reference not supported in WS (pass by value only) XML represents data as trees, not graphs Stateful objects like threads, file handles can’t be sent to WS Member field representation differs between OO and XML Need proxy classes - RPC not built in to language Many complex steps required to deploy a WS (esp. in Java)

Scripting Languages Examples: Perl, PHP, Python, JavaScript Features Simple and easy to use Rapid development cycle No need for compilation Proxy objects simpler to use, can be generated at runtime Drawbacks No explicit typing makes automatic WSDL generation impossible Poor or no support for concurrency

Web service composition languages Examples: BPEL Features Designed specifically for WS development Type system (XML) matches that of WS interfaces Many easy to use graphical tools available Drawbacks Very limited programming model, can only write simple programs XML-based syntax verbose and awkward to code in directly

WS Composition – desirable features Static typing All data serializable as XML Rapid development cycle (like Perl/PHP) WSDL files auto-generated - w/o programmer intervention Same semantics for local & remote function calls Fault tolerance & load balancing And most importantly… Network transparency – It’s there but you can’t see it – Programmer should not have to deal with low-level details such as WSDL syntax

Our proposed approach XSLT as a web service composition language Specifically designed for dealing with XML data – Which all web services use for exchanging data – Type system is XML Schema – no mismatch between service interfaces and implementation language Functional language – side-effect free functions allow for automatic parallelisation and transparent fault tolerance Mature language – around 6 years old, now in V2 (almost) W3C standard, sizeable existing developer community Currently being implemented in our project, “GridXSLT”

Accessing other web services All user-defined and extension functions in XSLT are associated with a namespace Our implementation recognizes namespaces corresponding to WSDL service definitions Function calls in these namespaces are mapped to web service calls These are handled internally by the language implementation – proxy classes are unnecessary <xsl:transform xmlns:foo=“wsdl:

Exposing XSLT programs as web services The GridXSLT engine acts as a web server Simply place an XSLT program within the document root, just like a Perl script or PHP file Clients can access the WSDL definition as follows: WSDL file is auto-generated from the function signatures No type system conversion necessary; XML Schema used in XSLT is simply copied to WSDL definition No compilation, manual WSDL generation, jar packaging, XML configuration files, or deployment scripts necessary – just copy the file to the server!

Automatic parallelisation a(1)b(2)c(3) Host 1 Host 2Host 3 Host 4 f f(a(1), b(2), c(3))

Fault tolerance Host 3 fails after executing c(3) but before transmitting result Function is re-executed on Host 2 As c(3) causes no side-effects, this is safe to do a(1) b(2) c(3) Host 3 Host 4 f

Condensed language syntax WSDL, BPEL, XSLT all use an XML based syntax Very verbose to work with - 2x-10x the amount of code required vs. “standard” language syntax e.g. Java & C Writing large programs in XSLT can be very tedious We support an alternative language syntax Same semantics, but expressed more concisely foo(a=12,b=3);

Compare: hand-written WSDL <definitions xmlns=" xmlns:tns="urn:matrix" xmlns:soap=" xmlns:xsd=" targetNamespace="urn:matrix">

Compare: hand-written WSDL

Compare: XSLT w/condensed syntax type matrix { { int col[3]; } row[3]; }; matrix mmul(matrix $a, matrix $b) {... }

Conclusion Advantages over other WS development languages Type system match Automatic & transparent WSDL generation – without semantic inconsistencies Rapid service deployment – just copy a file (or edit in-place) No need to generate proxy classes Support for complex application logic Transparent fault tolerance & load balancing Advantages over other XSLT implementations Automatic parallelisation Support for web services (both client and server) Condensed language syntax

Questions/comments?