Title: 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
-----Original Message-----
From: Edwin
Khodabakchian [mailto:]
Sent: Friday, November
07, 2003 10:41 AM
To: 'Ron Ten-Hove'
Cc:
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
From: Ron Ten-Hove
[mailto:]
Sent: Friday, November 07, 2003
9:52 AM
To:
Subject:
[wsbpel] Sub-functions: some thoughts
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).
