1 / 17

Compilation of XSLT into Dataflow Graphs for Web Service Composition

Compilation of XSLT into Dataflow Graphs for Web Service Composition. Peter Kelly Paul Coddington Andrew Wendelborn. Web Service Composition. Composition programs invoke operations on multiple web services to build “higher level” functionality

sacha-conrad
Télécharger la présentation

Compilation of XSLT into Dataflow Graphs for Web Service Composition

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. Compilation of XSLT into Dataflow Graphs for Web Service Composition Peter Kelly Paul Coddington Andrew Wendelborn

  2. Web Service Composition • Composition programs invoke operations on multiple web services to build “higher level” functionality • Complex application logic implemented within individual services, not composition program • Languages available designed specifically for this purpose • Examples: BPEL, SCUFL

  3. Why XSLT? • Designed to deal natively with XML data • Compatibility with WSDL type system (XML Schema) - no “impedance mismatch” • Functional language - can be automatically parallelised • Easier to use and more powerful than other WS composition languages • Particularly for writing application logic • Existing, standardized, popular language

  4. Distributed XSLT processing We are targeting two types of distribution: Within the program • Automatically parallelising the code • Executing different function calls, loop iterations, etc. across different processors or machines Outside of the program • Invoking multiple web service operations asynchronously and in parallel

  5. Why distributed processing? • Better performance • Parallelism enables different CPUs or machines to cooperate on the program • Reduces execution time • Benefit of similar nature to that of MPI, OpenMP • Distribution through WS composition • Enables parallelism using existing services • Division of responsibility - parts of your program leverage others’ servers

  6. Execution Model • Based on the dataflow concept • Program represented as a directed acyclic graph • Nodes represent operations, edges represent the flow of data between them • Each node can be a built-in operation, user-defined function, or web service operation

  7. Execution Model - Benefits • Parallelism possible for independent segments of the graph • By partitioning the graph, each segment can be assigned to a different processor or machine • Similar to the workflow concept used by many graphical WS development tools • But our model is more fine-grained • Aimed at parallel programming as well as WS composition • Text-based source code more appropriate than GUIs for large programs

  8. Execution Model • Each XSLT program represented as a collection of graphs • A graph corresponds to a piece of code that could be executed more than once • e.g. functions, templates, loop bodies • These graphs are generated during the compilation phase

  9. Execution Model • At runtime, a copy of each graph is created on demand when it needs to be executed • Multiple copies may be created in certain cases such as loops • These copies consist of activities (nodes), which represent operations that are waiting to execute • When an activity receives all of the inputs it needs, it “fires” and produces an output value • This output value is passed on to other nodes in the graph

  10. Distributed Execution(not yet implemented) • Assign new activities to different machines when they are created • Activities without data dependencies between them can execute in parallel • Other language implementations have done this successfully; we are applying it to XSLT Host 1 Host 2

  11. Compilation Process • Constants c c

  12. Compilation Process • Binary operators - +, *, =, < etc. left DUP op right left op right

  13. Compilation Process • Conditionals - xsl:if, xsl:chose, XPath if condition true branch DUP SPLIT MERGE false branch if (condition) then true branch else false branch

  14. Compilation Process • Loops - xsl:for-each MAP g items body Sub-graph g <xsl:for-each select=“items”>body</xsl:for-each>

  15. Current Progress • Prototype implementation • Parsing/verification of XSLT code • Compilation to dataflow graphs • Sequential interpreter

  16. Future Work • Distributed execution • Activity scheduling/distribution • Instruction clustering • Lazy evaluation • Streaming processing • Formal definition of compilation process • JIT compilation • Performance analysis and optimisation

  17. Conclusion • XSLT is a suitable language for web service composition • Dataflow model permits parallel execution of functional code • Increasing popularity of web services & XML necessitates more powerful and easy to use tools • Especially for web service composition • Our compiler demonstrates the viability of dataflow as an approach to executing XSLT

More Related