Download b(2) c(3)

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:http://store.com/api”>
...
<xsl:value-of
select=“store:getPrice(‘shoes’)”/>
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:
http://your.server/example.xsl?WSDL
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
f(a(1), b(2), c(3))
Host 1
Host 2
Host 3
a(1)
b(2)
c(3)
f
Host 4
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)
c(3)
Host 3
f
Host 4
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
<xsl:call-template name=''foo''>
<xsl:with-param name=''a'' select=''12''/>
<xsl:with-param name=''b'' select=''3''/>
</xsl:call-template>
foo(a=12,b=3);
Compare: hand-written WSDL
<?xml version="1.0"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:matrix"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:matrix">
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:matrix">
<complexType name="matrix">
<sequence>
<element name="row" minOccurs="3" maxOccurs="3">
<complexType>
<sequence>
<element name="col" minOccurs="3" maxOccurs="3" type="xsd:int"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</schema>
</types>
<message name="mmulResponse">
<part name="mmulReturn" type="tns:matrix"/>
</message>
<message name="mmulRequest">
Compare: hand-written WSDL
<part name="a" type="tns:matrix"/>
<part name="b" type="tns:matrix"/>
</message>
<portType name="MatrixPortType">
<operation name="mmul" parameterOrder="a b">
<input message="tns:mmulRequest" name="mmulRequest"/>
<output message="tns:mmulResponse" name="mmulResponse"/>
</operation>
</portType>
<binding name="MatrixBinding" type="tns:MatrixPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="mmul">
<soap:operation soapAction=""/>
<input name="mmulRequest">
<soap:body use="literal"/>
</input>
<output name="mmulResponse">
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="MatrixService">
<port binding="tns:MatrixBinding" name="MatrixPort">
<soap:address location="http://localhost:8080/matrix"/>
</port>
</service>
</definitions>
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?
pmk@cs.adelaide.edu.au
http://gridxslt.sourceforge.net