[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Sub-functions: some thoughts
Ron,
We should be driven by uses cases NOT analogies. In
this case case, the use case is about re-use. As pointed out, there are multiple
ways to address that need:
(1) Encapsulation of the logic to be re-used in a
seperate process
(2) Let the tooling address this need through
templates
(3) Create a new construct at the language level
(called subfunction)
It seems that the only benefits of (3) over (1), (2) or a
combination of (1) and (2) is that the use of subfunction signatures can having
to avoid creating a new message type and the assign activities needs to
initialize and read data from the message types.
There might be also an argument about (3) offering better
support for privacy and packaging and deployment.
But there are also drawbacks/costs with (3) that need to be
weighted:
(1) Complexity: to really deliver on the
benefit of sub-functions, we need to replicate a very large number of concept
and constructs already existing in the process and scope elements.
(2) Lack of communication channel: we
need to create a communication mechanism between the subfunction and the calling
activity so that the subfunction can report its status. This last need is much
better addressed with option (1) because already supported by scope event
handlers and receive activities. This is an area where BPEL is very different
from traditional flow languages and this is why I am not sure that your "other
process language do this" argument is valid.
(3) Lack of
consistency:
This is a software point but I find the passing arguments
to the subfunction not consistent with the rest of the spec: you need to create
a new subfunction interface definition language (not WSDL), you need to learn
that sometime you can do assign (when using invoke, receive, pick) for data
manipulation and sometime you can plug expressions directly in the signature
(this is at least what Yaron is suggesting).
I believe that the single most important success factor for
BPEL to succeed is to remain simple (which is not trivial given that we inherit
the complexity of XML Schema and some of the exotic variations of WSDL).
Given that there is a significant complexity "cost" associated with
adding this feature to the language, I would like to recommend following Ugo's
advice and finding use cases where the problem can not be addressed using a
combination of (1) and (2) and therefore require us to go the extra mile
of spec'ing out (3).
Best,
Edwin
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]