Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lackof BPMN BPEL support-v1.0.pptx uploaded

Hi Huabing,

Would be happy to add you to the agenda.

Kind regards,
Matt Rutkowski

STSM, Master Inventor, IBM Open Cloud Technologies
and Standards
Apache OpenWhisk Incubator Project Lead,
Initial Committer
Chair, Lead Editor OASIS TOSCA Simple Profile
WG,
Co-Chair OASIS TOSCA Interop. SC,
Founder of DMTF Cloud Audit (CADF) Standard
,  mobile: 512-431-5002

From:      
 <>
To:      
 Matt Rutkowski/Austin/IBM@IBMUS,
<>
Cc:      
 <>,
<>, <>, <>,
<>, <>, <>,
<>, <>, <>,
<>, <>
Date:      
 04/20/2017 04:03 AM
Subject:    
   Re: [tosca]
Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lackof BPMN BPEL support-v1.0.pptx
uploaded

Hi Matt,
I modified the proposal to incorporate Chirs' delegate
approach for inclusive workflow definition.
Could we add this to the agenda of next week's TOSCA Simple
Profile WG meeting?

Thanks,
Huabing

Original Mail

Sender:  ＜＞;
To:  ＜＞; ＜＞;zhaohuabing10201488;
CC:  ＜＞; ＜＞;
＜＞; ＜＞; ＜＞;MengZhaoXing10024238;
＜＞; ＜＞; ＜＞;
＜＞; ＜＞;
Date: 2017/04/08 14:57
Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups
- Issue_TOSCA318_Lackof BPMN BPEL support-v1.0.pptx uploaded

Hi Chris, Micheal,
 
Just quick comment on your points 2 and
3: TOSCA imperative workflows are actually partially model driven as they
are defined at the template level and not instance  level, without
TOSCA model they don’t mean a lot and on the other hand that is why they
suits the TOSCA world.
 
Luc
 
From: Chris Lauwers ＜＞
Date: Friday, 7 April 2017 at 23:17
To: Michael Brenner ＜＞, ""
＜＞
Cc: Luc Boutier ＜＞, Matthew Rutkowski
＜＞, "" ＜＞,
"" ＜＞, Paul
Lipton ＜＞, shitao li ＜＞,  ""
＜＞, Nati Shalom ＜＞,
Arthur Berezin ＜＞, Amir Levy ＜＞,
Sivan Barzily ＜＞, Tal Liron ＜＞
Subject: RE: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx uploaded
 
Hi Michael,
 
Thanks for your detailed write-up. When
you finish your document on this topic, I’d love to get a copy.
 
A couple of comments:
 
1.      I
agree with your Day 1 vs. Day 2 distinction. TOSCA so far has focused primarily
on Day 1 deployments, but in my opinion the real value is in Day 2 operations.
I believe this will require  more progress on “instance models”
that capture operational state, since the Day 2 workflows you mentioned
are really implementation of autonomic processes that manipulate  “operational
state”. 
2.      I
also agree with your distinction between “model-driven” vs. “task-driven”
approaches to workflows. In fact, the TOSCA spec owes up to this distinction
by specifying both “imperative”  and “declarative” workflows.
Declarative workflows are created automatically by the orchestrators, whereas
imperative workflows must be specified by the service template designer
using the workflow language introduced in TOSCA Simple Profile for YAML
v1.1.  Declarative workflows in TOSCA don’t require service template
designers to specify any workflow at all: the “declarative” workflow
is derived automatically by the orchestrator by leveraging implementations
(“artifacts”) of operations that are part of the standard  lifecycle
management interfaces. 
3.      From
that point-of-view, the question whether to use TOSCA’s imperative workflow
language or BPEL or BPMN is actually a valid question, in my opinion, because
either one could be used  to specify “imperative” workflows. The
advantage of TOSCA’s built-in workflow language is obviously that it integrates
better with the rest of TOSCA, whereas more work is need to allow external
workflow engines to operate on TOSCA models.
4.      The
real question we should focus on, then, (and you alluded to this as well)
is why there should be a need to use imperative workflows at all? What
are the use cases that cannot be  solved using declarative workflows
and require imperative workflows instead? I would much rather focus our
energy on answering this question, since it will lead to improvements to
the language that will make declarative workflows more flexible and more
widely  applicable. 
5.      I’ve
given some thought to the types of extensions that may be required to make
declarative workflows more usable. The following come to mind:
a.       Introduce
interface-specific state variables. We currently assume that there is one
node state variable that captures lifecycle management state for that node.
For other types of interfaces  (such as your healing or scaling interfaces),
this state is not useful. We either need additional state values, or additional
state variables, or both. The best solution, in my opinion, is to move
the state variable into the interface.
b.      Introduce
additional metadata for lifecycle operations. For example: what are the
pre-conditions that need to be met before the operation can be executed
(e.g. what state does the node/interface  need to be in?). Are there
any side effects to the operation (e.g. node/interface transitions into
a different state). Such metadata is currently supported in the TOSCA imperative
workflow, but in my opinion much of this belongs with the operations themselves,
 not with the workflow.
c.       Introduce
additional metadata for interfaces themselves. For example: relationship
interfaces currently don’t allow the interface type designer to specify
any ordering relationships  between operations called on source node
vs. operations called on target nodes. Instead, orchestrators are supposed
to know the proper ordering for the normative relationship types. This
means that it is not possible to introduce custom relationship interfaces
 without also specifying a declarative workflow.  We need some
type of mechanism for specifying operations ordering. 
 
I look forward to further discussion about
this topic.
 
Thanks,
 
Chris
 
 
From: Michael Brenner [mailto:]

Sent: Tuesday, March 28, 2017 5:54 PM
To: 
Cc: BOUTIER, LUC ＜＞; Chris Lauwers ＜＞;
Matt Rutkowski ＜＞; ; ;
Lipton, Paul C ＜＞; Lishitao ＜＞;
;  Nati Shalom ＜＞;
Arthur Berezin ＜＞; Amir Levy ＜＞;
Sivan Barzily ＜＞; Tal Liron ＜＞
Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx uploaded
 
Hi all,
 
First of, I would like to apologize for joining
this thread just now.
The fact of the matter is that we felt this
is an important discussion and decision and therefore we needed to invest
more time analyzing the current proposal and impact of supporting BPMN/BPML/BPEL.
 
In general I think that Luc did a great job
both in the 1.1 proposal and also by outlining the general approach on
how we should handle workflows in TOSCA in order to allow better portability
 and at the same time make it simple.
 
I would like to start with something that
I feel we all may be correct in some way, but the solution often depends
on the context. In this case, different approaches may be related to what
each  of us mean by "workflow". Like in many other cases,
it is an overloaded term. I don't think we want to get into an academical
debate and spend huge efforts in creating a common definition, but if we
could accept a definition and use case for workflow it would  be easier
to discuss the potential benefit or disadvantages of integrating BPMN/BPML/BPEL
into this model.
 
Recently I started collecting various perspectives
and putting together an analysis on this topic (rough Draft at this point,
but it will posted soon and I will be ready to share with those interested).
 
I would like to quote specifically the workflow
definition as it provides an important framing for this discussion:
 
＜snip＞
DevOps Workflow:
Workflow is an orchestrated
and repeatable pattern representing an execution plan expressed as a directed
graph of tasks  – simple to define, to reason, to execute and to
visualize.
DevOps workflow are used
to orchestrate operations in infrastructure and applications, automate
complex CI/CD processes etc.
 
A typical use case for DevOps
workflow include “Day 0” operations such as Install/uninstall workflow
- execute the lifecycle operation of an application  and its associated
infrastructure.
 
Things get vastly more complex
in case of workflow that deal processes that need to update/change an existing
deployment, based on “Day 2” operations.  A typical set of workflows
that fits into this category includes: 
 
·  Heal
workflow - fix a failed node (typically by re-executing the failed node
lifecycle operation and relationship)
·  Scale
workflow - increase the capacity of a given application node (typically
by executing the lifecycle operation  of the target node multiple
time on each scale instance)
·  Update
workflow - a common pattern for update is referred to as blue/green. (A
typical implementation includes  taking a snapshot of the current
state -＞ pushing the new update -＞ redirecting traffic to the new deployment
-＞ gradually redirect all traffic to the new version -＞ if failed roll-back
to the previous version)
·  Topology
update (aka as blueprint update) - adding/removing an entire service from
and existing application topology.  A typical implementation includes
comparing the new blueprint with the existing version-＞identifying the
changes -＞ executing the changes and updating the model accordingly.
 
There are basically two main
approaches for workflow execution: a task-based approach vs a model-driven
approach.
In a task-based system we
execute a workflow by breaking it into a specific set of tasks. For example
let’s imagine a simple use case of installing  a nodeJS instance
on a virtual machine.
The workflow for that task
include the following steps:
 
1.      Provision
the VM
2.      Setup
network (public/private IP, security group etc)
3.      Install
and configure the nodeJS instance
4.      Start
the nodeJS instance
 
In a task-based system I
will need to map every step as a task and execute it.
 
In a model-driven approach
I would define the model first. The workflow execution will be driven from
the model and would be generated implicitly.
The Core Components of a
model-driven workflow are:
 
·  Model
(Graph) - describes the nodes and their relationship
·  State
- maintain the actual state of execution of each node. 
·  Execution
- the actual code that maps to the specific lifecycle operation of each
node.
 
The key differences between
a model-driven and task-driven approach is that task-driven approach tends
to be purpose-built (allows for more specificity,  but less re-usability)
while the model-driven approach lends itself to be more tend to be more
generic/flexible
In other words, a model-driven
workflow is simpler to change as it groups the tasks into their respective
node-types and thus provide more coarse-grain  building blocks that
are easier to change and maintain. It’s also easier to read and follow
and fits better with a designer task.
＜snip＞

I am sure you guessed that the task-based approach is exemplified by BPMN/BPML/BPEL,
and the model-driven approach is exemplified by the TOSCA-native approach
to workflows.
 
I would also like to end with the conclusion
that we see from that analysis:
 
＜snip＞
Conclusion:
In conclusion, the turn-around
in TOSCA towards the declarative, model-driven approach for workflows is
a very positive move, and will help TOSCA  to have “a good year in
2017”. There is really nothing wrong with using BPMN/BPML/BPEL, where
appropriate. But there is something to be said when we try to use a complex
specification designed for a different set of applications, in a domain
where an approach  that is simple, flexible, re-usable fits better,
and the word is “overkill”. 
So let’s support the “good
year of TOSCA” initiative by embracing the TOSCA_YAML_V1.1 approach ,
and focus on the progress of the improved TOSCA_YAML_V1.2,  and future
versions planned!"
＜snip＞
Thanks all for your patience in reading my
lengthy response; I am looking forward to continue staying engaged until
we find the right solution for the problem space.
 
Best regards,
Michael
 
On Mon, Mar 27, 2017 at 6:57 AM, ＜＞
wrote:
Hi Luc,
Please see my inline comments.
 
Thanks,
Huabing
Original Mail

Sender:  ＜＞;
To: zhaohuabing10201488;
CC:  ＜＞;
＜＞;
＜＞;
＜＞;
＜＞;
＜＞;MengZhaoXing10024238;
Date: 2017/03/27 16:10
Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups
- Issue_TOSCA318_Lack of BPMN BPEL support-v1.0.pptx uploaded 
 
Hi Huabing,
 
I realized you made your own choices out
of the TC and really want them to be standard now. 
Huabing: I didn't mea that(make my own choices),
It's the intention of broader audience/users of  TOSCA (Service Provider:AT&T,
CMCC, Vendor:Huawei, ZTE and research group:University of Stuttgart) to
keep BPMN/BPEL in TOSCA, based on their own experiences and requirements,
I think we all have heard their concerns in the proposal presentation and
open comments  maillist.  Also I thought it's the conclusion
of the last meeting that I've confirmed by mails.
 
You are talking a lot about scenarios that
cannot be done with current  TOSCA but I still don’t see them to
be honest. I think  that current workflow + artifact types/artifact
type executors can do everything, even manual operations as you can make
an artifact type/artifact type executor that will prompt user. It’s just
that it  follows a TOSCA compliant way to do so, and compliant  in
2 ways:
-      
   Can be triggered through
imperative workflows
-      
   Can be included in a declarative
generated workflow (this is critical as this is kind of the goal of TOSCA).
BPMN taks are not defined on TOSCA nodes
and cannot be triggered through declarative generated workflows. This is
again why it’s  not a good target for TOSCA and  for what we
try to achieve.
 Huabing: Ideally, yes, we can add
everything which not inside TOSCA in term of an artifact.  But it
imply that we have to implement another "Workflow execution Engine"
which has the similar functionalities of an arbitrary mature workflow execution
engine, in a different way, which would be a lot of work and it's not the
main goal of orchestration.
You asked for better choice we already provided
one:
-      
   artifact type approach
is absolutely valid and allow to have both portability kept and BPMN execution
possible, so this is to me the better approach  that we BTW agreed
on on the calls. Not sure you  understood what I write in my previous
email but I feel that delegate or artifact type are quite the same thing
here.
And no, I’m not in favour of losing portability
again, and to be honest not in favour of supporting any workflow languages
as  long as we don’t have a way to make  it portable (I mean
internally do what you want and as I explained already you can use internally
a BPMN engine to process your TOSCA, that is your choice).
 
I think that TOSCA exists for quite a long
time now and we didn’t had really portability, right now every implementer
made their  own choices (that’s what you  did, that’s what
GigaSpaces did, that’s also what we did in our tool – for the yet not
fully standardize custom artifact executions). Based on that I feel that
there is 2 path for TOSCA:
-      
   Stop trying to solve the
execution issue and be just a modelling language (drop interfaces and operations)
and let people provide imperative specific  means to make things executed
through other specs  (BPMN etc.) or other means (Docker compose, Kubernetes
models or other declarative approaches that comes).
-      
   Keep trying to address
the initial challenge which is to try to build a portable declarative and
executable standard (well that’s quick sentence but  I think it was
the main points of TOSCA somehow).
So I’m sorry but no I cannot kindly agree
with something that I really feels as a wrong path. That said if I’m the
only one to  feel that way please let me know  as we should probably
stop a lot of work we started here (including artifact type executor and
let people just do their own custom non portable things).
Huabing: What we're asking is not an "A"
or  "B" choice for workflow standard, instead, we'd like
to keep workflow  choice open so the implementation could choose whatever
workflow which make sense based on their requirement. So we don't have
to stop what we're working on right now to incorporate BPMN/BPEL into TOSCA.
Luc
 
From: ""
＜＞
Date: Monday, 27 March 2017 at 04:44
To: Luc Boutier ＜＞
Cc: Chris Lauwers ＜＞,
 Matthew Rutkowski ＜＞,
 ""
＜＞,
 ""
＜＞,
 Paul Lipton ＜＞,
 shitao li ＜＞,
  ""
＜＞
Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx uploaded 
 
Hi Luc,
I think Chirs' suggestion make sense.
Just like a famous western saying: "Rome wasn't built
in a day", it's not realistic to try to work out a "perfect"
solution overnight. We need to solve the issue we currently faced and allow
it evolve towards the right direction in the same time. I'd like  
to say that there might be a solution close to but not "perfect"
solution at all, becasue things always change. 
 
Furthermore, I don't think exclusive approach is the best
choice for workflow. Because there is no a silver bullet to solve all the
problems. Just as what I and Claud were saying in the last proposal presentation,
there were still some scenarios which tosca   workflow can't handle
with right now, which have already been implemented by BPMN/BPEL in OpenECOMP/OPEN-O/OpenTOSCA.
 
I will be appreciate if you could kindly agree this approach
or you can figure out a better one to address it in a short term.
 
Thanks,
Huabing
Original Mail

Sender:  ＜＞;
To:  ＜＞;zhaohuabing10201488;
CC:  ＜＞;
＜＞;
＜＞;
＜＞;
＜＞;MengZhaoXing10024238;
Date: 2017/03/25 04:35
Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups
- Issue_TOSCA318_Lack of BPMN BPEL support-v1.0.pptx uploaded
 
Hi Chris,
 
I see no real difference with this delegate
proposal and an operation within the workflow except that  operation
with artifact  type is something we are working  on and could
provide portable and normative support.
 
We can write a TOSCA 1.1 workflow with set_state
at the end and a single call to the BPMN artifact  operation, that
is really  similar to what you propose but leveraging  planned
1.2 standard definitions (once we finish the artifact type and artifact
executor definition).. If not we will end up with a delegate that orchestrator
does not know how to handle,  delegate is intended for  orchestrator
provided nodes (matched abstract  nodes – so specific to orchestrator).
Or only some specific impl will know how to handle them? And this will
be custom per Impl and for no more benefits that the simple artifact support
 that we proposed.
 
Once again, I really think that we should
work on instance model and API before we go further. And  also complete
the work on  custom artifact type support because  even this
is not fully completed yet and seems on hold since we discuss this BPMN/BPEL
elements rather moving forward. I really believe that more than making
some people happy we should focus  on trying to build a reliable  standard.
This is exactly why we worked  on the workflow spec in 1.1. because
there where nothing people could really rely on in previous spec. Declarative
workflows ordering was not clearly defined and saying that multiple workflows
 languages could be consider  was not a reliable statement and
actually  just lead us to the point we are now with people making
their own choices out of the TC and trying to find a reconciliation rather
than moving forward on the multiple challenges we should  address.
 
I think that in this perspective the work
started on artifact type support is critical and we should  complete
that work rather  than trying to solve all issues  and especially
elements that will not bring more to TOSCA but just please people (I am
still not seeing anything that is TOSCA compliant that cannot be done with
the actual workflow language – and  not TOSCA compliant elements
 should currently be supported  through specific artifacts).
I still feel on my own that other workflows language will weaken TOSCA
as they are not compliant with the TOSCA way to define and call operations
and especially the current  artifact type work.
 
That said I don’t say we should not consider
the support of specific workflow languages in the future,  I just
feel that we should  not make wrong choices to please  people
while some elements are not ready yet in TOSCA.
 
Anyway, we just don’t agree here I guess,
 
Luc
 
From: Chris Lauwers ＜＞

Date: Friday, 24 March 2017 at 18:29
To: Luc Boutier ＜＞,
""
＜＞
Cc: Matthew Rutkowski
＜＞,
""
＜＞,
""
＜＞,
Paul Lipton ＜＞,
shitao  li ＜＞,
""
  ＜＞
Subject: RE: [tosca] Re:[tosca] RE: Re:[tosca]
Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v1.0.pptx uploaded
 
Hi Luc,
 
While I generally agree with
the “walk before you run” approach, I believe there might be a very simple
way to accommodate   what Huabing wants. How about the following:
 
1.      We
already have a “delegate” keyname on workflow activities. What if in
addition, we also allowed a “delegate” keyname on a top-level workflow
definition? This would  signal  to the orchestrator  (in
a standardized way) that the workflow would be taken over entirely by an
external entity. The argument of the “delegate” keyname would be the
artifact name of the BPNM or BPEL workflow (for which we would obviously
still need  to define  a processor).
2.      I
also agree that in order to do this correctly, we will have to standardize
an API to the instance model, and more sophisticated TOSCA workflows could
benefit from  such  an API as well.  However, the API available
to TOSCA workflows today is limited to “set_state” and “call_operation”.
At the very least, we could make those operations available to external
workflows, which would put these external workflows on-par with  TOSCA
 workflows.
 
While this doesn’t entirely
address your “portability” concerns, at least it provides a standard
way for template   designers to signal to the orchestrator that responsibility
 for orchestration needs to be delegated to an external workflow engine.

 
thanks,
 
Chris
 
 
 
From: BOUTIER, LUC [mailto:]

Sent: Wednesday, March 22, 2017 11:31 PM
To: Chris Lauwers ＜＞;

Cc: ;
;
;
;
;

Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx uploaded
 
Chris, Huabing,
 
I think that we should not constraint 1.2
on custom workflow support and that we should try to go step by step:
1.      We
still don’t have artifact type executors completed and I think this is
the first step we need to complete
2.      We
still don’t have an instance model
3.      And
once instance model is defined we will need also an instance model API
to be defined and agreed
 
Instance model and Instance model APIs are
pre-requisite for any kind of workflow extensions are workflow execution
extensions   will mean workflow engines external to the TOSCA orchestrator,
 or there won’t be portability as we cannot expect or have as a pre-requisite
for TOSCA orchestrator to support any kind of Workflow languages especially
open workflow languages supporting extensions   (meaning not supported
everywhere).
 
So, my suggestion is that the 1.2 target
should define a way to execute custom operation types in a portable way
and we need to   have this work completed (this is the great work
started  by Chris). BPMN or BPEL in 1.2 will be artifact types with
the limitations Chris mentioned.
 
As we say in France « Il ne faut pas mettre
la charrue avant les bœufs »
 
Luc
 
From: ＜＞ on behalf of Chris Lauwers ＜＞

Date: Thursday, 23 March 2017 at 05:58
To: ""
＜＞
Cc: Matthew Rutkowski ＜＞,
""
＜＞,
 ""
  ＜＞,
Paul Lipton ＜＞,
 shitao li ＜＞,
""
  ＜＞
Subject: RE: [tosca] Re:[tosca] RE: Re:[tosca]
Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v1.0.pptx uploaded
 
I’m not sure about the timeframe. Matt
should chime in on this.
 
Thanks,
 
Chris
 
From: [mailto:]
On Behalf Of 
Sent: Wednesday, March 22, 2017 9:57 PM
To: Chris Lauwers ＜＞
Cc: ;
;
;
;
;

Subject: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx uploaded
 
Hi Chris,
Thanks for your explanation.
That's exactly what I'm curious about. 
So we're planing planning to add arbitrary artifact implementations
for the entire workflow of the topology template in 1.2, such as BPMN,
BPEL, Node-RED,Ballerina etc.?
 
Thanks,
Huabing
Original Mail

Sender:  ＜＞;
To: zhaohuabing10201488; ＜＞;
CC:  ＜＞;
＜＞;
＜＞;
＜＞;MengZhaoXing10024238;
Date: 2017/03/23 12:21
Subject: [tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx uploaded
 
Hi Huabing,
 
Yes, your understanding of the plan is correct.
 
However, in the current version of the spec,
artifacts can only be used to provide implementations for operations. For
example,    this means that you will be able to specify  a
BPEL workflow to implement the “create” operation on the Standard lifecycle
operation.
 
We currently don’t have a mechanism to
use artifacts as implementations for entire workflows. This will need to
get added in a    later version.
 
Thanks,
 
Chris
 
From: [mailto:]

Sent: Tuesday, March 21, 2017 4:41 AM
To: ;
Chris Lauwers ＜＞
Cc: ;
;
;
;

Subject: Re:[tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v1.0.pptx
uploaded
 
Hi Matt, Chris,
 
I haven't find any update about this in my inbox, did I
miss anything?
I guess the idea is that TOSCA could take BPMN/BPEL as
an artifact type and it can be executed by an artifact processor(workflow
execution engine) provided by orchestrator, right?
 
Thanks,
Huabing
 
Original Mail

Sender: zhaohuabing10201488
To:  ＜＞;
＜＞;
CC:  ＜＞;
＜＞;
＜＞;
＜＞;MengZhaoXing10024238;
Date: 2017/03/16 09:54
Subject: Re:[tosca] Groups - Issue_TOSCA318_Lack of
BPMN BPEL support-v1.0.pptx uploaded
 
Hi Matt,
Thanks for uploading the slide deck.
Do we have a minutes for this meeting? I'm still improving
my English skill, so I have difficulty to get all the points of everyone
in this meeting....
Is the conclusion that we'll incorporate BPMN/BPEL workflow
as artifact in the later version of simple YAML and Chris are working on
that?
 
Thanks,
Huabing
 
 
Sender:  ＜＞;
To:  ＜＞;
Date: 2017/03/15 23:16
Subject: [tosca] Groups - Issue_TOSCA318_Lack of BPMN
BPEL support-v1.0.pptx uploaded
 
Submitter's message
        Parts of these slides were presented during
the 2017-03-14 Simple Profile WG meeting.         
-- Mr. Matthew Rutkowski

Document
Name: Issue_TOSCA318_Lack
of BPMN BPEL support-v1.0.pptx
       

No description provided....    
   
        Download
Latest Revision
        Public
Download Link
       

Submitter: Mr. Matthew Rutkowski
                Group: OASIS
Topology and Orchestration Specification for Cloud Applications (TOSCA)
TC
        Folder: Working Documents
        Date submitted: 2017-03-15 08:15:37
                
           
 
 
 
 
 
 
 
 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php