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

 

-          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).

-          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:

·         We still don’t have artifact type executors completed and I think this is the first step we need to complete

·         We still don’t have an instance model

·         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

To:  mrutkows@us.ibm.com; lauwers@ubicity.com;

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;

To:  tosca@lists.oasis-open.org;

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
               
           

 

 

 

 





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