RE: [wsbpel] Abstract processes - how much energy do we expend here - how does this impact executable progress?

["Satish Thatte" <satisht@microsoft.com>]

I didn't say anything about a later version.  We can and should clarify this in the current version.

________________________________

From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: Thu 6/24/2004 11:20 AM
To: Satish Thatte
Cc: Tony Fletcher; 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?



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