Hi Oliver and Palu,
@Oliver, Thanks for sharing your insights and the great idea to combine declarative and imperative workflow in term of BPMN.
I'm from a vendor and I'm also actively involved in NFV MANO open source projects(OPEN-O[1], OpenECOMP[2], ONAP[3]), so I'd like to add some points from the vendor and NFV MANO's perspective as well.
I know that both of OPEN-O and COMP are using BPMN/BPEL workflow in their current orchestration implementation. I'd like to mention that these codes are not only prototypes, they have also been used in the China Mobile testing network and AT&T production network.
These two projects are both under Linux Foundation and they are merging into a combined group Open Network Automation Platform (ONAP) right now. ONAP will no doubt become one of the most significant Orchestration open source projects in NFV&SDN industry because a dozen of the world’s leading operators and vendors are in its member list. So we might need to consider their workflow implementation in the TOSCA spec.
From my understanding, we can get the below advantages if BPMN/BPEL are kept in TOSCA:
First, relying on existing standards facilitates portability and interoperability.
* There are plentiful of workflow engines which follow BPMN/BPEL standard
* Orchestration implementations have alternative choices for workflow engines to reduce risk
Second, An open standard can attract more orchestration implementations to adopt TOSCA.
* Allows the orchestration implementations choose their comfortable technologies depending on the business scenarios
* Builds an ecosystem, Just like there're many programming languages which can accomplish the similar tasks, multiple workflow DSLs should also be supported in TOSCA to build an open, prosperous ecosystem.
Last, TOSCA can evolve in a compatible manner
* Reduce the rework for existing orchestration implementations which have already adopted TOSCA V1.0. So they don't have to change the workflow modelling and execution logic. (e.g. OPEN-O, ECOMP)
Thanks,
Huabing
[1] https://www.open-o.org/
[2] http://www.openecomp.org/
[3] https://www.sdxcentral.com/articles/news/logical-happens-open-o-merges-ecomp/2017/02/
Original Mail
Dear Oliver,
I acknowledge your comment during our public review period. It will be considered as part of the public comment review and the TC's response will be published.
Regards,
Paul
-----Original Message-----
From: tosca-comment@lists.oasis-open.org [mailto:tosca-comment@lists.oasis-open.org] On Behalf Of Oliver Kopp
Sent: Thursday, March 2, 2017 3:29 AM
To: tosca-comment@lists.oasis-open.org
Subject: [tosca-comment] Workflows in TOSCA
Dear OASIS TC,
I read the PRD 02 of Version 1.1 and read about the simple workflow language.
I have a background of several years in the area of workflow management. I was at the IAAS, which build a workflow-engine for BPEL (research prototype) and I know one main contributor of Apache ODE pretty well and also the founders of Camunda, which build a very good BPMN engine.
We also use BPEL and BPMN in context of TOSCA 1.0 and it works.
Seeing the workflow language in the specification, I think, the language is well-suited for short running tasks. But what about long-running processes? Such as monitoring the application. What about human tasks? What if I need an Oracle license? How can I do that with the proposed language? What about complex fault handling? What about reversing actions (compensation!)? This is all possible with BPEL and BPMN engines.
We also showed than one can combine declarative and imperative provisioning using BPEL:
Breitenbücher, Uwe et al.: Combining Declarative and Imperative Cloud Application Provisioning based on TOSCA. In: Proceedings of the IEEE International Conference on Cloud Engineering (IC2E), 2014.
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iaas.uni-2Dstuttgart.de_RUS-2Ddata_INPROC-2D2014-2D21-2520-2D-2520Combining-2520Declarative-2520and-2520Imperative-2520Cloud-2520Application-2520Provisioning-2520based-2520on-2520TOSCA.pdf&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=5MV73ln3EoUIoD70UytlVRU12tFCiU1h0Xz46ZcIQUk&e=
We also have REST extensions for BPEL and also a simplified syntax for BPEL (https://urldefense.proofpoint.com/v2/url?u=http-3A__bpelscript.org_&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=8dgD3vBBm1RrrYKGJxsHchWfTS6cfqbtoSRVpepYxXc&e= ).
TOSCA aims for portability. It has been shown that BPEL and BPMN are portable. Not all construcuts, but the most important ones. An overview is given here: https://urldefense.proofpoint.com/v2/url?u=https-3A__peace-2Dproject.github.io_&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=Ubss3oXKt-HLuwMtoFyiWvDeZNA4jnUnZBwbq6sXf8Q&e=
In TOSCA 1.0, this was acknowledged. One could add arbitrary management plans. Winery (https://urldefense.proofpoint.com/v2/url?u=http-3A__eclipse.org_winery_&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=R3k0DuJEZbK3-WRgHVD4vJmDulZugcMlyUdn-TyaXz0&e= ) also supports that. We also offer an open-source BPMN Modeler with direct support of TOSCA. Source: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_winery_BPMN4TOSCAModeler&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=Lm_XLecrXqAfAmDEgcz15MCT0O48mwARtiMwEoNDJCk&e= . The result is converted to BPEL processes, which have been successfully deployed on the WSO2 BPS, but can also deployed on other BPEL engines.
All in all, I would like to ask the TC if it was possible to bring back the support of established workflow languages and not restrict the implementors to one language.
Greetings from Stuttgart,
Oliver
--
This publicly archived list offers a means to provide input to the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC.
In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.
Subscribe: tosca-comment-subscribe@lists.oasis-open.org
Unsubscribe: tosca-comment-unsubscribe@lists.oasis-open.org
List help: tosca-comment-help@lists.oasis-open.org
List archive: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.oasis-2Dopen.org_archives_tosca-2Dcomment_&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=BWZE8j0BUChHFFaisGje5OQki2KwA0sP47NTu21WTXk&e=
Feedback License: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oasis-2Dopen.org_who_ipr_feedback-5Flicense.pdf&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=fpdr9K8HqafDxm8B7QnL9p5OP48x85RzW9DohprivRk&e=
List Guidelines: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oasis-2Dopen.org_maillists_guidelines.php&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=jhVBL_N209tAKzUEsq7AYSDTBCAlAbi8DZiBluJwB7U&e=
Committee: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oasis-2Dopen.org_committees_tosca&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=d5r_n4gSNxk7N2gX8wK0e9FPuOEViyc2zYaUG53i4-Y&e=
Join OASIS: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oasis-2Dopen.org_join_&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=3UUaotXGpqHidtIBP1k_gYHXTeBFOTS36FpSS_-nzAk&m=nD7ACc-aDih8t7_9gLPH9KtFyqfdsxqN9OkiTy01cto&s=4iffWFM4wyJhz-L2yA0K6t9GBvAhCx6kc9R_BPR5bxg&e=