[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Abstract processes - how much energy do we expend here -how does this impact executable progress?
Could we then consider including a manageable definition and use cases to facilitate, in a timely manner, the development and release of our anticipated committee draft to meet the overall TC objective? As you indicated Satish, the expression could come later and reasonably in a later version. Thanks. >Thatte: +1 > >And I don't think this is a difficult technical problem. It is more of a problem of gaining common understanding of the meaning and goals. I believe we have made good progress in the direction of gaining clarity on this as a result of the ongoing discussion. I certainly feel that I have made progress in my own thinking. I will write up a summary of what I expressed here at the F2F and see how everyone likes it. > >Satish >________________________________ > >From: Tony Fletcher [mailto:tony_fletcher@btopenworld.com] >Sent: Wed 6/23/2004 2:50 PM >To: 'Monica J. Martin'; 'Wsbpel@Lists. Oasis-Open. Org (E-mail)' >Subject: RE: [wsbpel] Abstract processes - how much energy do we expend here - how does this impact executable progress? > >My personal opinion. > >Does not necessarily impact executable progress as executable currently is >progressing in parallel and has its own critical path. We could further >decouple. > >While I understand the need to solve the executable BPEL problems and get >the spec for executable BPEL out, and I am therefore sympathetic to the idea >of decoupling, I can also see that without it people will have some >difficulties - and at first may try to 'bend' executable BPEL to abstract >BPEL uses. This may actually work to some extent as I currently see the two >as being close syntax wise though the uses can be fairly different. While I >think there is a whole spectrum of abstract possibilities and executable >(but non runnable) possibilities through to runnable executable processes >and many different use cases as presented by Phil, Ivana and captured in the >informal group on abstract processes temporary document, I think the main >ones have been outlined by Satish - and they will not go away. That is in >one direction you want to design a process, you start of with the essentials >only (an abstract process) and incrementally develop it maybe with hand >offs to different designers until you have an executable process that runs >and does all that you want it to. In the other direction you have an >executable process (or code and you derive and executable BPEL process from >that) and you want to share it with a partner so that they do the inverse >(in terms of messages i.e. they receive when you send and send when you >receive), but want to keep some of the detail of what you are actually doing >under the hood confidential. > >Summary: I think we will need something like what we currently call abstract >BPEL sometime, and it should be simpler than executable. > >Best Regards Tony >A M Fletcher >Home: 35, Wimborne Avenue, IPSWICH IP3 8QW >Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 > amfletcher@iee.org (also tony.fletcher@talk21.com & >tony_fletcher@btopenworld.com) >-----Original Message----- >From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] >Sent: 23 June 2004 22:02 >To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)' >Subject: [wsbpel] Abstract processes - how much energy do we expend here - >how does this impact executable progress? > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]