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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: Re: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)


> And, no, I won't be
> going to the conference you speak of, but I'd love to somehow see it
anyway.

+1

----- Original Message ----- 
From: "Ben Bloch" <ben_b54@hotmail.com>
To: "Tony Andrews" <tandrews@microsoft.com>; "Furniss, Peter"
<Peter.Furniss@choreology.com>; "Yaron Y. Goland" <ygoland@bea.com>; "John
Evdemon" <jevdemon@microsoft.com>; <wsbpel@lists.oasis-open.org>
Sent: Thursday, October 23, 2003 1:01 PM
Subject: Re: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)


> Tony,
>
> I absolutely concur that the spec can and probably should do a better job
of
> describing what abstract processes are, including their relationship to
and
> potential unboundedness from executable processes. In fact, if this could
> somehow be raised as an issue, perhaps the editors (of which I am one) can
> take a swag at this. It would make the spec more readable and show the
> value(s) of abstract processes themselves.
>
> I also agree that individual abstract processes should not be dependent
upon
> one another to be able to operate.  However, one process IMO should be
able
> to learn or at least be influenced by the state (eg failure) of another
> process, perhaps from the process in question itself, a coordination or
> monitoring service (more likely) or some other mechanism.
>
> And lastly,  if I could focus in on the last sentence about your demo:
> "In a nutshell, it shows how we can verify that web service systems
> (described by BPEL abstract processes) will communicate successfully, and
> how we can detect and visualize errors."
> Could you please define "successful" on this context? And, no, I won't be
> going to the conference you speak of, but I'd love to somehow see it
anyway.
>
> Ben
>
>
>
> how they compare to WSDL.
> ----- Original Message ----- 
> From: "Tony Andrews" <tandrews@microsoft.com>
> To: "Furniss, Peter" <Peter.Furniss@choreology.com>; <ygoland@bea.com>;
> "John Evdemon" <jevdemon@microsoft.com>; <wsbpel@lists.oasis-open.org>
> Sent: Thursday, October 23, 2003 2:30 PM
> Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
>
>
> Thanks for jumping in on this Peter. That's a pretty good summary of my
> position. Certainly, what's missing from BPEL today is a way of
> describing how individual BPEL abstract processes can be combined
> together in a precise way. That is a non-trivial problem in itself, and
> while such a description would be of great interest to BPEL, I don't
> think that the two should be dependent on one another. One might well
> wish to describe the connection of web services whose behaviors are not
> specified (or are not specified using BPEL).
>
> Satish pointed to some of the rationale for describing the behavior of
> the individual participants rather than taking a more neutral view of
> the interaction. On a very practical level, a single-party view has
> other benefits as well. It allows systems to be composed using either a
> unilateral or bi/multi-lateral approach. Each abstract process
> represents the behavior of one service, so it's in a form that can be
> directly leveraged by developers to seed or verify their
> implementations.
>
> Historically, I believe this approach has also been widely used in
> network protocol design. The TCP connection protocol, for example,
> speaks of server states (CLOSED, LISTEN, SYN-RECEIVED, ESTABLISHED) and
> client states (CLOSED, SYN-SENT, ESTABLISHED) and describes the behavior
> of each party in terms of its own local observations and state
> transitions. And as Satish was saying, in a neutral model the
> (potentially many) race conditions that might arise would have to be
> modeled explicitly while in an individual view they still exist but need
> not be enumerated.
>
> I'll also just echo a couple of important points that Peter raised.
> First, the existence of an abstract BPEL process says *nothing* about
> the way in which it is implemented. In fact, we'll probably start
> describing existing services long before the first BPEL-compliant
> execution engine runs its first process. In that respect, it's very much
> like WSDL - purely descriptive.
>
> Second, the interface/implementation relationship is a key point and
> gives users a great deal of flexibility. Multiple implementations of a
> single interface will be routine. But I think it will also be common for
> services to implement multiple abstract process behaviors simultaneously
> - perhaps as a "server" in one protocol and a "client" in another.
>
>
> I don't think abstract processes are very well motivated in the spec
> today. We should probably say more about their independence from
> implementation and about their relationship to executable processes. We
> should also say something about the formal methods that they are
> intended to support - certainly, the limitations on abstract processes
> were put in place with very specific analytic approaches in mind (i.e.
> model-checking).
>
> I have a demonstration of this that I'll be showing at the Microsoft
> developer conference in Los Angeles next week. If anyone in the TC will
> be attending, please stop by the Microsoft Research booth to say hello
> and see the demo. In a nutshell, it shows how we can verify that web
> service systems (described by BPEL abstract processes) will communicate
> successfully, and how we can detect and visualize errors.
>
> Tony
>
> > -----Original Message-----
> > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> > Sent: Wednesday, October 22, 2003 4:42 PM
> > To: ygoland@bea.com; John Evdemon; wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
> >
> > Some of Yaron's comments on the FAQ (most of which I agree
> > with) seem to relate to the power of abstract BPEL
> >
> > paragraph from the proposed FAQ:
> >
> > <quote>
> > The Business Process Execution Language is a XML-based
> > language for formally describing interoperable business
> > processes and business interaction protocols.  It defines how
> > web services are connected together and in what sequence in
> > order to accomplish a particular task
> >
> > </quote>
> >
> > to which Yaron comments :
> >
> > <quote>
> > BPEL only provides a description of the behavior of a single
> > player in a business process protocol. Since protocols
> > require, by definition, more than one player BPEL is by
> > definition unable to completely describe a business process
> > protocol or to specify how different processes interact
> > beyond describing the behavior of a single participant.
> > Therefore I think this paragraph should be struck.
> > </quote>
> >
> > which was very much my view until I had a conversation with
> > Tony Andrews and got a better understanding of his
> > presentation from the first face-to-face (
> > http://www.oasis-open.org/archives/wsbpel/200305/msg00172.html
> > ). It seemed some things I had thought would be necessary,
> > and which I hadn't seen stated, and so assumed were not in
> > view, were definitely
> > intended/expected:
> >
> > - there can be multiple abstract definitions for a
> > single executable, each specifying the dynamic behaviour of
> > one (or set of
> > related) interfaces, with the other interfaces handled by
> > opaque assignment; the choice of how many of these there are,
> > their level of opacity and the interfaces covered is a
> > design/viewpoint question
> >
> > - there can be (and need to be for the "global"
> > picture) abstract bpel definitions for processes that are
> > never going to be in bpel - not least because some are "leaf"
> > processes in the web-service world, and do real work on
> > databases or visible effect on GUIs etc.
> > rather than just defer to yet another web-service, which is
> > all executable bpel can do
> >
> > - there can be multiple executable processes matching a
> > single abstract definition - this is just an
> > interface:implementation relationship
> >
> > (Apologies to Tony if I've mis-represented him). They
> > obviously have some exciting implications for what bpel tools
> > in general might do (especially the middle one - how on earth
> > do you show compatibility between abstract bpel and a legacy
> > app written in cobol with a web-service front end)
> >
> > But these don't seem to be in the spec. (last one might be).
> > Should it be left to interpretation (and, no doubt, some books) ?
> >
> > There's also the possibility of stating the rules (guidelines ?
> > constraints ?) involved in the two abstract bpel definitions
> > that make up either side of a business protocol.
> >
> >
> > (I should possibly mention that I was for a long time very
> > sceptical about whether bpel or things like it was the way to
> > do this, and thought it could be done with a simpler, less
> > procedural approach. but gradually I found my vague "ideal"
> > was getting necessarily more complex and needing more
> > functionality - in fact heading towards somehting much like
> > on abstract bpel)
> >
> > Peter (speaking for himself)
> >
> >
> >
> > > -----Original Message-----
> > > From: Yaron Goland [mailto:ygoland@bea.com]
> > > Sent: 22 October 2003 23:09
> > > To: 'John Evdemon'; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] FAQ
> > >
> > >
> > > Some comments
> > >
> > > > -----Original Message-----
> > > > From: John Evdemon [mailto:jevdemon@microsoft.com]
> > > > Sent: Tuesday, October 21, 2003 12:44 PM
> > > > To: wsbpel@lists.oasis-open.org
> > > > Subject: [wsbpel] FAQ
> > > >
> > > >
> > > >  <<WSBPEL DRAFT FAQ.txt>> Hello all,
> > > >
> > > >  A while ago I asked for feedback on a TC FAQ.  I have attached a
> > > > draft that incorporates some initial feedback from Monica and Ugo.
> > > > Please respond with any additional questions or concerns.
> > > >
> > > > If there is no feedback by 10/28 I will assume the TC is
> > happy with
> > > > the current version (attached) and submit it to OASIS.
> > > >
> > > > Thanks!
> > > >
> > > > John
> > > >
> > > >
> > >
> >
> > To unsubscribe from this mailing list (and be removed from
> > the roster of the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > ave_workgroup.php.
> >
> >
> >
>
> To unsubscribe from this mailing list (and be removed from the roster of
the
> OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>



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