[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: >All true, except for the simple matter of analyzing the implications of >concurrency for access to shared data or being able to recognize the >patterns where concurrency is absent and thus concurrency control is not >required. In particular, if a sequence has incoming and outgoing links, >and is now replaced with a flow with links itself, I submit that >recovering the original pattern and its simple inexpensive >implementation would be challenging. > This type of analysis should be done, regardless of whether <sequence> is used. Further, it is not that difficult to distinguish sequential chains of activities, if one models the process as a (suitably annotated) DAG, rather than an XML tree. (Control of concurrent access to process instance state is a topic we need to delve into separately. Is there such a thing as a "safe" BPEL process, in this regard? Can we create a formal semantics of execution to aid in verifying safety properties?) > >In other words, we would be raising the bar for implementers of both >tools and runtime engines, especially if we expect them to cater to the >prejudices of those who prefer the "block structured" approach rather >than the "linking activities" approach that Assaf seems to like these >days. > I'm not sure I understand this final comment. Eliminating <sequence> does not change the basic topology of such process graphs. As for "raising the bar" for implementors: I'd issue the standard word of warning about "premature optimization." As a colleague of mine is fond of saying, we have to paint the dragon before we can slay it. Cheers, -Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]