[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Sub-functions: some thoughts
Edwin, Thanks very much for the thoughtful reply. You've raised some very good points; the one I most appreciate is the reminder that there are costs and benefits for all the language features we create, or, I would add, exclude. Users will bear some of the costs, after all. My comments are in-line with yours, below: Edwin Khodabakchian wrote: This is not an insignificant advantage. Crafting new message types, and writing "gnarly" assign activities are not simple tasks, and can be regarded as "overhead" getting in the way of the process author. Put another way, our domain-specific language requires a lot of solution domain elements; sub-functions could serve reduce the number of solution domain elements the author need worry about. I think your general point about increased complexity is true, but I'm not sure about the need to replicate much of what already exists. Yaron's proposal seemed a very straight forward extension of those concepts, not duplicative. Perhaps you were referring to implementations, rather than the language itself? An interesting point. I regard the proposed sub-function invocation mechanism as a simple extension of that used by existing activity types, such as <invoke>. Variables are passed by reference, either as input, or output. The chief difference is cardinality -- subfunctions allow multiple input (and output?) variables. The general mechanism, from the user's perspective, is the same. I'm not sure what you mean by a subfunction reporting its status. Are you envisioning some sort of asynchronous subfunction invocation? I don't think BPEL is so different from existing languages, just simplified. The adoption of an abstract messaging model for work performers and requesters does eliminate (or move elsewhere) some of the complexities found in other languages. In some other languages it is theoretically possible to model other processes as work performers/requesters, but this, as far as I know, has never been carried to the extreme of requiring that it be done so. Regardless, I don't think BPEL is so different that the need for for a compositional mechanism supported by the language itself has been eliminated. Right. There would be a new concept, the subfunction, which is invoked in a syntactically different, seemingly more direct way than services. This distinguishes subfunctions from (external) services, but at the cost of the user knowing the difference. The actual "pass by reference" semantics would remain the same, keeping things consistent at that level. Unfortunately we have already established that we will not simply reduce BPEL to the simplest language possible. (I find this minimalist approach very attractive, but this has been rejected by the TC. BPEL is a modelling language as well as an executable one. This will increase language complexity / clutter.) I still find Ugo's suggestion (that you refer to) as being decidedly biased, and it certainly misses the mark in this issue. As you mentioned earlier in your note, the question is about reuse: what language support for reuse should we have? This affects readability, composability, and (less directly) the granularity of reusable "components" that are feasible. None of these factors are examined when simply looking for use cases that cannot be addressed. Your point about cost/benefit trade-off is well taken. Adding more domain-specific concepts to a language makes it more complex to implement, while making it easier for end-users to utilize. Conversely, reducing the number of domain-specific concepts makes it harder for end-users to use the language, but makes implementations easier to realize. There is a balance to be achieved, not by always favouring minimal language features, but, as Satish reminded us, by using our judgement. How are we to judge the cost/benefit of language-based support for reuse? Best regards, -Ron |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]