[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] implicite links of the runtime engine (was: Implicit<sequence> macro)
Satish Thatte wrote: >> I'm putting out a particular opinion in the understanding that the >> specification is geared towards the definition of executable >> >> >processes. > > >> Is that a wrong assumption? >> >> > >We obviously support and will continue to support both abstract and >executable processes. Abstract processes are clearly not relevant only >to execution engines. As Yaron has pointed out, even execution oriented >BPEL models will be looked at and modified by humans whatever our >intention or recommendation. > > The abstract as I understand it, is used to define the business protocol. I'm not sure what other purposes it serves, the only one I can think of is to constrain the process definition. Which means you need to check for interface compliance, again in terms of implementation a <sequence> doesn't give you much unless we have a profile in which <flow> is not supported. As for modifying by humans, again we have to look at how often/how much. If it's frequent then you add a requirement to support XML authoring and add more constructs to the syntax to make life easier. If it's less frequent, then you try to be as easy to use as XML Schema, WSDL and other related specifications. >> For the record we looked at this long and hard within the context of >> BPML. >> >> > >Does BPML have a notion of links and graphs? I must have missed that. > > I guess you could form cyclic graphs if you wanted to using spawn. There was a nice example (diagram and all) in an older version of the spec. If you are doing acylic graphs you can just synchronize using signals. Single-link signals are semanticaly equivalent to links (including) DPE. See the diagram on page 39. arkin >Satish > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]