1 / 17

A Simplified Approach to Web Service Development

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

chaney
Download Presentation

A Simplified Approach to Web Service Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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)

  4. 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

  5. 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

  6. 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

  7. 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”

  8. 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’)”/>

  9. 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!

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

  11. 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

  12. 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);

  13. 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">

  14. 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>

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

  16. 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

  17. Questions/comments? pmk@cs.adelaide.edu.au http://gridxslt.sourceforge.net

More Related