OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] Re:[tosca] RE: Re:[tosca] Groups - Issue_TOSCA318_Lack of 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 <lauwers@ubicity.com>
Date: Friday, 7 April 2017 at 23:17
To: Michael Brenner <michael@gigaspaces.com>, "zhao.huabing@zte.com.cn" <zhao.huabing@zte.com.cn>
Cc: Luc Boutier <luc.boutier@fastconnect.fr>, Matthew Rutkowski <mrutkows@us.ibm.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, "claude.noshpitz@att.com" <claude.noshpitz@att.com>, Paul Lipton <paul.lipton@ca.com>, shitao li <lishitao@huawei.com>, "meng.zhaoxing1@zte.com.cn" <meng.zhaoxing1@zte.com.cn>, Nati Shalom <natis@gigaspaces.com>, Arthur Berezin <arthur@gigaspaces.com>, Amir Levy <amir@gigaspaces.com>, Sivan Barzily <sivan@gigaspaces.com>, Tal Liron <tal@gigaspaces.com>
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:michael@gigaspaces.com]
Sent: Tuesday, March 28, 2017 5:54 PM
To: zhao.huabing@zte.com.cn
Cc: BOUTIER, LUC <luc.boutier@fastconnect.fr>; Chris Lauwers <lauwers@ubicity.com>; Matt Rutkowski <mrutkows@us.ibm.com>; tosca@lists.oasis-open.org; claude.noshpitz@att.com; Lipton, Paul C <paul.lipton@ca.com>; Lishitao <lishitao@huawei.com>; meng.zhaoxing1@zte.com.cn; Nati Shalom <natis@gigaspaces.com>; Arthur Berezin <arthur@gigaspaces.com>; Amir Levy <amir@gigaspaces.com>; Sivan Barzily <sivan@gigaspaces.com>; Tal Liron <tal@gigaspaces.com>
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, <zhao.huabing@zte.com.cn> wrote:

Hi Luc,

Please see my inline comments.

 

Thanks,

Huabing

Original Mail

Sender:  luc.boutier@fastconnect.fr;

To: zhaohuabing10201488;

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: "zhao.huabing@zte.com.cn" zhao.huabing@zte.com.cn
Date: Monday, 27 March 2017 at 04:44
To: Luc Boutier
luc.boutier@fastconnect.fr
Cc: Chris Lauwers
lauwers@ubicity.com, Matthew Rutkowski mrutkows@us.ibm.com, "tosca@lists.oasis-open.org" tosca@lists.oasis-open.org, "claude.noshpitz@att.com" claude.noshpitz@att.com, Paul Lipton paul.lipton@ca.com, shitao li lishitao@huawei.com,  "meng.zhaoxing1@zte.com.cn" meng.zhaoxing1@zte.com.cn
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:  luc.boutier@fastconnect.fr;

To:  lauwers@ubicity.com;zhaohuabing10201488;

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 lauwers@ubicity.com


Date: Friday, 24 March 2017 at 18:29
To: Luc Boutier luc.boutier@fastconnect.fr, "zhao.huabing@zte.com.cn" zhao.huabing@zte.com.cn

Cc: Matthew Rutkowski mrutkows@us.ibm.com, "tosca@lists..oasis-open..org" tosca@lists.oasis-open.org, "claude.noshpitz@att.com" claude.noshpitz@att.com, Paul Lipton paul.lipton@ca.com, shitao  li lishitao@huawei.com, "meng.zhaoxing1@zte.com.cn"  meng.zhaoxing1@zte.com.cn
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:luc.boutier@fastconnect.fr]
Sent: Wednesday, March 22, 2017 11:31 PM
To: Chris Lauwers
lauwers@ubicity.com; zhao.huabing@zte.com.cn
Cc: mrutkows@us..ibm.com; tosca@lists.oasis-open.org; claude.noshpitz@att.com; paul.lipton@ca.com; lishitao@huawei.com; meng.zhaoxing1@zte.com.cn
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: tosca@lists..oasis-open.org on behalf of Chris Lauwers lauwers@ubicity.com


Date: Thursday, 23 March 2017 at 05:58
To: "zhao.huabing@zte.com.cn" zhao.huabing@zte.com.cn
Cc: Matthew Rutkowski mrutkows@us.ibm.com, "tosca@lists.oasis-open.org" tosca@lists.oasis-open.org,  "claude.noshpitz@att.com"  claude.noshpitz@att.com, Paul Lipton paul.lipton@ca.com,  shitao li lishitao@huawei.com, "meng..zhaoxing1@zte.com.cn"  meng.zhaoxing1@zte.com.cn
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: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of zhao.huabing@zte.com.cn
Sent: Wednesday, March 22, 2017 9:57 PM
To: Chris Lauwers
lauwers@ubicity.com
Cc: mrutkows@us.ibm.com; tosca@lists.oasis-open.org; claude.noshpitz@att.com; paul.lipton@ca.com; lishitao@huawei.com; meng.zhaoxing1@zte.com.cn
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:  lauwers@ubicity.com;

To: zhaohuabing10201488; mrutkows@us.ibm.com;

CC:  tosca@lists.oasis-open.org; claude.noshpitz@att.com; paul.lipton@ca.com; lishitao@huawei.com;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: zhao.huabing@zte.com.cn [mailto:zhao.huabing@zte.com.cn]
Sent: Tuesday, March 21, 2017 4:41 AM
To: mrutkows@us.ibm.com; Chris Lauwers
lauwers@ubicity.com
Cc: tosca@lists.oasis-open.org; claude.noshpitz@att.com; paul.lipton@ca.com; lishitao@huawei.com; meng.zhaoxing1@zte.com.cn
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

CC:  tosca@lists.oasis-open.org; claude.noshpitz@att.com; paul.lipton@ca.com; lishitao@huawei.com;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:  mrutkows@us.ibm.com;

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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]