1 / 21

Ben Butchart Wolfgang Emmerich University College London b.butchart@cs.ucl.ac.uk

Orchestration of an OGSI-enabled scientific      application using the Business Process Execution Language. Grids and Applied Language Theory (GAL2003). Ben Butchart Wolfgang Emmerich University College London b.butchart@cs.ucl.ac.uk w.emmerich@cs.ucl.ac.uk. Overview.

adila
Download Presentation

Ben Butchart Wolfgang Emmerich University College London b.butchart@cs.ucl.ac.uk

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. Orchestration of an OGSI-enabled scientific     application using the Business Process Execution Language Grids and Applied Language Theory (GAL2003) Ben Butchart Wolfgang Emmerich University College London b.butchart@cs.ucl.ac.uk w.emmerich@cs.ucl.ac.uk

  2. Overview • How we became interested in workflow • Why we chose BPEL • A BPEL appetizer • Shortcomings of existing BPEL implementations • Shortcomings of BPEL language itself • Overcoming some problems • Comparison with GSFL • Conclusion and future work • Discussion

  3. The Beginning… A messy but beautiful data flow diagram

  4. Control logic of the Polymorph prediction application (not distributed)

  5. Control logic of the distributed polymorph prediction application

  6. So why BPEL ? • WSFL and XLANG deprecated • Microsoft, IBM, BEA triumvirate powerful market force • Submitted to OASIS for standardization • First implementations already available for evaluation (IBM BPWS4J, Collaxa) • Do not want to diverge from standard Web Services technology set

  7. Instantiating SOAP message <soapenv:Body> <runPoly xmlns="http://poly"> <ns1:atomArray xmlns:ns1="http://www…/cml2/core"> <ns1:atom elementType="H" x="3.17" y="2.43“ z="0.02"/> <ns1:atom elementType="H" x="-1.74" y="2.61" z="-0.38"/> </ns1:atomArray> <spacegroups> <spacegroupLabel>AA</spacegroupLabel> <spacegroupLabel>AB</spacegroupLabel> </spacegroups> <ns2:crystal z="1" xmlns:ns2="http://www…/cml2/core"> <ns2:scalar title="alpha" units="deg">0</ns2:scalar> <ns2:symmetry id="" spaceGroup=""/> </ns2:crystal> </runPoly> </soapenv:Body>

  8. BPEL Example <sequence name="sequence"> <receive name="receive" partner=“user" portType="p:PolyPort" operation="runPoly" container="request“ createInstance="yes"/> <assign> <copy> <from container="request" part="atomArray"/> <to container="molpakrequest" part="atomArray"/> </copy> </assign> <assign> <copy> <from container="request" part="crystal"/> <to container="molpakrequest" part="crystal"/> </copy> </assign>

  9. BPEL Example <assign> <copy> <from container="request" part="spacegroups“ query="./spacegroupLabel[position()=1]" /> <to container="molpakrequest" part="crystal" query="./ns2:symmetry/@id" /> </copy> </assign> <invoke name="invoke1" partner="provider" portType="mpak:MolpakPort" operation="runMolpak" inputContainer="molpakrequest" outputContainer="molpakresponse"/> … </sequence>

  10. BPEL Features • Loop and control logic • XPath query assignment • Recursive Composition • Synchronous and asynchronous communication • Concurrent execution • Correlated messages • Event handling • Fault handling

  11. Shortcomings of BPEL implementations • Binding to a URL expected at deployment time • Early implementations could not cope with OGSI extensions to WSDL • Or properly handle imports • Dynamic creation of new process instances to improve scalability • Steering – change process during execution

  12. Shortcomings of BPEL language • Need placeholder objects to support some assignments • Data aggregation - No way to temporarily collate results • Cannot specify mechanism for binding (WSDL, UDDI, OGSAFactory) • Limited lifecycle interface (just receive, pick terminate) • Verbose • Does not support peer communication

  13. The scalability problem Workflow Engine Workflow Engine Compute Service Compute Service Compute Service Compute Service Compute Service Compute Service After Krishnam, Wagstrom, Laszewski GSFL: A Workflow Framework for Grid Services

  14. Late binding OGSA Registry getBindingURL(PortType) OGSA Registry OGSA Factory Binding Create instance Molpak service Abstract Binding BPEL Parser UDDI Binding <invoke name="invoke1" partner="provider" portType="mpak:MolpakPort" operation="runMolpak" inputContainer="molpakrequest" outputContainer="molpakresponse"/> UDDI Registry WSDL Binding <service name="MolpakService"> <port> <soap:address location= "http://tapas.cs.ucl.ac.uk: 8080/ogsa/services/"/> </port> </service>

  15. Workflow Engine Compute Service Compute Service Compute Service compute1 compute2 compute3 Scalability Workflow Engine Compute Service & Workflow Engine Compute Service Compute Service

  16. How we solve the problems • late binding: extra URL binding mechanisms • scalability: recursive composition • scalability: group binaries into single WS port type • scalability: dynamic deployment and delegation • steering: use BPEL event handling functionality • aggregation: use a dedicated web service • verbose: use GUI/XSLT

  17. Other Web Service Workflow Languages • WSFL and XLANG – now superseded by BPEL • GSFL – extension to WSFL to support Grid requirements • SWFL – another extension to WSFL • Scufl (taverna) / Freefluo

  18. recursive composition correlated messages separates data flow peer data flow modelling binding mechanism configurable WS standard cross vendor support fault handling and compensation concurrent control flow message part assignment Xpath assignment implementations available recursive composition correlated messages separates data flow peer data flow modelling binding mechanism configurable WS standard cross vendor support fault handling and compensation concurrent control flow message part assignment Xpath assignment implementations available Comparison with GSFL GSFL BPEL

  19. Conclusion • Can use BPEL for modelling grid applications – no real need for extensions • But we need an implementation that is Grid enabled • Might not need full implementation • We should stick with WS technology set if at all possible

  20. Integration with Scheduler (Sun Grid Engine) BPEL Engine compute node 8.invoke service molpak service isntance 9.invocation completed 1.getBindingURL (PortType) Dummy Process (blocks) 10.kill 2.getBindingURL (PortType) 6. SGEchooseMe (jobID,myURL) Trader Binding Trader 3. Run a proxy job (jobID, traderURL) 5. runDummy.sh (jobID,traderURL) 7. search for instance 4. Run a proxy job (jobID, traderURL) SGE Wrapper OGSA Registry SGE

  21. Late binding: deployment descriptor <service name="poly/PolyProviderFactoryService/poly1"> <requestFlow> <handler type="BPELRequestHandler"/> </requestFlow> <responseFlow> <handler type="BPELResponseHandler"/> </responseFlow> <parameter name="name" value="Polymorph process workflow"/> <parameter name="className" value="poly.PolyProvider“ <parameter name=“bindingMechanism" value=“Registry"/> </service>

More Related