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] implicite links of the runtime engine (was: Implicit<sequence> macro)


There definitely needs to be a way to combine a heirarchical composition 
of activities with a linkage between potentially concurrently 
activities. The first is needed for groups activities into the same 
context of execution (what BPEL calls scope) for handling local 
variables, failures, compensation, etc. The second is needed to 
establish non-trivial flows. So I can see why merging the two 
capabilities is beneficial.

If the decision is intentionally to include elements from both styles as 
a tour de froce, then of course other considerations are given less 
weight. This has to be written specifically in the specification, 
requirement document or elsewhere both for the benefit of the reader, 
and also to judge the acceptance for supporting additional requirements.

Moving down the road, once you ask "block-oriented" methodologists to 
consider structures such as DAGs you either end up with two different 
profiles for the language, or you find that tools slowly migrate to 
where they can support DAG throughout the language (barring other 
considerations such as authoring and modeling). Which is why it may boil 
to nothing more than an academic excercise.

Anyway, I may not agree with the rational, but at least I can understand 
it, and having it explicitly written down would be helpful for all 
future discussions, if nothing else than to justify other redundancies 
we have not discussed yet.

arkin


Frank Leymann wrote:

>I completely disagree that this is an academic exercise!  As Satish points
>out correctly, the combined block-structured and graph-structured nature of
>BPEL is a high-value feature of BPEL - real-world customers fall into one
>of these camps and you have hard problems convincing a "block-oriented"
>customer that graph-oriented is the right way to go and vice versa.  A
>combined language like BPEL is in fact very pragmatic by ending this
>discussion and being able to focus on features and functions.
>
>Regards,
>Frank
>
>-------------------
>Frank Leymann, Distinghuished Enineer
>IBM Software Group
>Member, IBM Academy of Technology
>
>Phone 1:  +49-7031-16 39 98
>Phone 2:  +49-7056-96 50 67
>Mobile:  +49-172-731 5858
>-----------------
>
>  
>




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