Message
I apologize if this post is a bit off topic
or if the this subject has been addressed some time before (I cannot
follow all the discussion threads on BPEL).
I am traditionally not a big fan of XSLT,
specially for UI applications, but I do think it has its place
somewhere within the SOA fabric, though neither composition,
orchestration, choreography, coordination or collaboration use it.
"Transformations" are often needed as part of
an orchestration solution. (I could also argue that they could be done
within the fabric istself at the choreography level but this is not the
topic here, maybe they are needed in both places).
I designed and implemented a BPEL engine last
fall and the first thing we ended up needing was "transformations" so
we created the equivalent element of assign for transformations. It
looks like XSLT could address pretty well the need for subFunctions
that can be invoked. I think pretty much all transformation engine
support some level of scripting today. I know that designer tools do it
very well.
Transformations are usually good because they
provide an extra level of decoupling, promiting consumer oriented data
formats as opposed to producer contracts. This is particularly useful
to support different consumer types from the same orchestration
definition.
Cheers,
Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634
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
BPELers,
At the risk of going off topic, I'll try to apply an analogy[1] to
our subfunction discussion. Let us say we are crafting a specification
for a new, simple imperative programming language. We have spent a lot
of time defining an exec() mechanism for the language that we are all
agreed on, and consider an important part of the language. It is noted
that this actually means that subfunctions aren't strictly necessary --
all subfunctions can be treated as a kind of exec(). We now break into
two camps over this:
- The minimalists, who argue that adding subfunctions is
unnecessary, and just clutters the language. The KISS principle rules.
- The traditionalists, who argue that virtually every other
language of this sort has subfunctions, and programmers will expect to
have them in the new language. Doing an exec() to calculate a
square-root sounds silly, and slow.
The minimalists attempt to find the middle ground, by holding that
a sufficiently clever IDE could create the illusion of subfunctions,
while in fact creating code that used exec() instead. The
traditionalists reject this line of reasoning, claiming that the
language is being crafted for humans to use, understand, and reason
with, not code generators.
Enough analogizing; back to BPEL: we seem to be revisiting an old
issue -- who is the target of this language: tools, or humans? This is
a topic we have discussed in the past; I believe our consensus was that
human readers (and even writers) were important. In addition, we have
seem to have accepted the assertion of the original authors that the
language is not merely for execution, but for process modelling as well.
Also, the principle of minimalism in a language has to kept in
check. To quote Satish Thatte (June 20, 2003):
"There is some element of judgment involved in
deciding what is minimal enough for BPEL -- emulation is not a
conclusive argument."
So how is our judgement to be informed and guided? Personal taste?
Keep the status quo, since that is easiest? Serve crass
commercial interests? Examine current practice in industry to adopt the
best elements and build an idea of what expectations have been created
over years of practice and innovation? Recall what makes open technical
standards viable, valuable, and widely adopted? Use a ouija board? ;-)
-Ron
[1] In general, I hate analogies, but given the membership of this TC,
this might actually be an apt one (YMMV).