a simplified approach to web service development peter kelly paul coddington andrew wendelborn
TRANSCRIPT
A Simplified Approach to Web A Simplified Approach to Web Service DevelopmentService Development
Peter Kelly
Paul Coddington
Andrew Wendelborn
Development of Web ServicesDevelopment 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 languagesObject-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 LanguagesScripting 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 Web service composition languageslanguages
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 WS Composition – desirable featuresfeatures
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 approachOur 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 servicesAccessing 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 Exposing XSLT programs as web servicesservices
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 parallelisationAutomatic parallelisation
a(1) b(2) c(3)
Host 1 Host 2 Host 3
Host 4
f
f(a(1), b(2), c(3))
Fault toleranceFault 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
Host 4
f
Condensed language syntaxCondensed 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 WSDLCompare: 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 WSDLCompare: 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 Compare: XSLT w/condensed syntaxsyntax
type matrix { { int col[3]; } row[3]; };
matrix mmul(matrix $a, matrix $b) {
. . .
}
ConclusionConclusion
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
