Hi Huabing, et. al. The need to specify imperative workflow “callous” from a TOSCA service template is pretty well understood, both from the enterprise and the telecom use case perspective. In fact, there is already a generic mechanism in TOSCA to support invocation and execution of “artifacts”, based on a template declaration. This is inclusive of BPMN/BPEL…
As I see it, the only blocker at this time are the issues around the call/return contract between the orchestrator execution and the workflow execution. Does the orchestrator block while the workflow is running? What happens if the workflow fails, or worse yet, what happens if a workflow processor fails? Does the orchestrator block forever, or is there a timeout? How do we clean up the leftover mess? Say the orchestrator does not block… Again, what happens during the invocation and failure? Obviously what happens upon workflow execution completion is also important. All of the above was discussed at the last TOSCA Simple YAML Profile meeting and action is being taken to document the call/return contracts. It might take a bit of time, but we will get there… TOSCA is a standard that caters to both the enterprise and the telecom use cases. All and any TOSCA orchestrators out there will need to support workflow “callouts” once they are part of the spec, so “measuring twice and cutting once” is pretty important… Kind regards, Alex Vul Intel Corporation ONAP Member OASIS TOSCA TC Member From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, May 10, 2017 12:17 AM To: [email protected] Cc: [email protected]; [email protected] Subject: [onap-tsc] [modeling] TOSCA BPMN support proposal at OASIS TOSCA WG Hi Amir and all, Both OPEN-O and OpenECOMP have used TOSCA for service topology modelling and BPMN/BPEL for lifecycle management process modelling. After the merger, ONAP will inherit the existing codes from OPEN-O and OpenECOMP and continue to use BPMN/BPEL in SO/VF-C. However, I noticed that TOSCA has removed the support for BPMN/BPEL in v1.1[1] which is recommended in the Topology and Orchestration Specification for Cloud Applications Version 1.0[2]. This incompatible change of TOSCA specification may cause unpredictable effects to existing opensource projects, in particular, the ONAP, which have already adopted BPMN as its lifecycle management process modelling. To harmonize the opensource and standards, I am co-proposing a proposal[3] with Lingli(CMCC), Claude(AT&T) and Shitaoto(Huawei) to suggest OASIS TOSCA revert standard workflow DSLs support such as BPMN/BPEL in the next version of simple YAML specification. The proposal has been discussed in the OASIS TOSCA for a couple of weeks and most of the members agreed on it except the strong pushback from Michael of Gigaspaces. I think this proposal is for the best interest of ONAP community, so I'm writing this mail to solicit supports from Gigaspaces and all the other community members who are both in ONAP and OASIS TOSCA WG. [1] http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html [2] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html [3] https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/60604/Issue_TOSCA318_Lack%20of%20BPMN%20BPEL%20support-v-2017-04-25.pptx Thanks, Huabing
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
