Hi Michael,
I brought this issue here only because the proposal has a strong relationship
to the ONAP community.
In the OASIS TOSCA meeting and maillist, I have repeatedly clarified that our
proposal only adds an option for the backward-compatible with TOSCA 1.0 to
allow reusing the tremendous existing codes of OpenECOMP and OPEN-O, it doesn't
intend to replace the new workflow DSL defined in TOSCA v1.1, and we also
acknowledge the vision of TOSCA declarative workflow.
TOSCA TSC Chair Matt also agree on this approach, here is what he said: “I
thought we had resolved going forward to acknowledge BPMN and BPEL (by name) as
popular examples of opaque ("Black box" artifact) work flow languages and list
all the issues/problems/caveats around using them in conjunction within a
declarative topology (for the Orchestrator and portability). To be clear, we
would not endorse them as normative, but neither would we reject them and
follow our philosophy of "meeting customer where they are at in their
(declarative) journey that is, not leave them behind, ignore them or force them
to choose to rewrite to TOSCA or leave.”
If BPMN/BPEL is not included in the TOSCA, we must either abandon the existing
codes, or extend the TOSCA spec in a non-standard way to support this. We hope
that the opensource and standard can cooperate and codevelop in a harmonized
way in the journey to it's ideally destination, that's why we submit this
proposal to OASIS TOSCA.
Here is the main idea of the proposal: it suggests an inclusive approach for
workflow definition: While the user can define each step of the imperative
workflow, the workflow can also be delegated to an arbitrary artifact, which
could be BPMN, BPEL or any other implementations which make sense.
To achieve that, the proposal suggest adding a “delegate” keyname at the
workflow level to signal that the workflow is delegated to an artifact
implementation. The value of “delegate” keyname is the relative path of the
artifact file in the CSAR package which the tosca template is in. During the
runtime, the orchestrator is responsible for instantiating the corresponding
artifact processor and hand over the workflow to it.
artifact_types:
tosca.artifacts.Implementation.BPMN:
derived_from: tosca.artifacts.Implementation
description: Script artifact for the BPMN workflow
mime_type: application/bpmn+xml
file_ext: [ bpmn ]
topology_template:
workflows:
update:
description: A BPMN workflow to update the network service
delegate: plan/update.bpmn
This approach is similar to the plan defined in TOSCA V1.0
＜Plans＞
＜Plan id="UpdateApplication"
planType="http://www.example.com/UpdatePlan";
planLanguage="http://www.omg.org/spec/BPMN/20100524/MODEL"＞
＜PlanModelReference reference="plans:UpdateApp"/＞
＜/Plan＞
＜/Plans＞
Given the intention of this proposal which is detailed described above, I don't
understand why you keep pushing it back .
Thanks,
Huabing
Original Mail
Sender: ＜mich...@gigaspaces.com＞
To: zhaohuabing10201488
CC: ＜a...@gigaspaces.com＞ ＜onap-disc...@lists.onap.org＞
＜onap-tsc@lists.onap.org＞
Date: 2017/05/10 21:03
Subject: Re: [onap-discuss] [modeling] TOSCA BPMN support proposal at
OASISTOSCA WG
Huabing,
I recognize the need in ONAP to support delegation in TOSCA to external
workflow engines. I have said this repeatedly, and still am miss-interpreted.
This has nothing to do with backward compatibility to TOSCA 1.0, it only has to
do with supporting "facts on the ground/existing implementations". We should
get this agreed once for all, and it became obvious in ONAP's Friday modeling
discussion.
It also became clear that some of these "facts-on-the-ground" use TOSCA in a
limited way. This is OK, and I have no issue with that. I can support in TOSCA
TC to find the right mechanism to delegate externally, but only if we do it in
a way that is complete: that means we need to not only specify how to "get out
of TOSCA" but also has to include how to "get back to TOSCA", and "what is the
TOSCA orchestrator supposed to do after it delegates externally". I suggest we
work jointly to resolve these issues.
Further, your claim that I am the only one opposing the half-way solution on
the table is incorrect, and you know it. Luc Boutier in the TOSCA TC is also
vehemently opposed, and partly at least for the same reasons as those quoted by
me.
It would be great if we stop making unfounded claims in one community, by
quoting only partially what happens in another community, and it would be
better to focus joint energy to resolve the issue in a consistent and complete
technical manner in the TOSCA TC. Please realize that you absolutely CANNOT
resolve TOSCA TC discussions/debates in the ONAP community alone, and this is
not the appropriate way for you to convince me to drop my opposition in TOSCA
TC.
The right way to have me support this is by resolving the technical issues that
I raised.
Best regards,
Michael
On Wed, May 10, 2017 at 3:16 AM, ＜zhao.huab...@zte.com.cn＞ wrote:
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
onap-disc...@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
--
Michael Brenner, Chief Architect NFVM:
+1-732-895-5772http://getcloudify.org@cloudifysource_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
