Ron,
> Portability is
not as restricted as the XSLT example you cite, for Java is also portable. One
could reasonably expect quite a number of BPEL engines that would support BPELJ,
> assuming that
JSR 207 standardizes it, thus avoiding vendor lock-in games.
I think BPELJ raises
language issues that go well beyond Java itself.
BPELJ is basically
saying: a language-agnostic approach based solely on the BPEL language and
WS-based interactions is unlikely to be sufficient in practice.
So we start
introducing Java-based escape doors. But why limit ourselves to
Java? There are many platforms out there where the native or preferred
programming language is something else (C#, Python, etc.). Those languages
should be supported too (an article just yesterday brought up the idea of a
BPELC#).
So, if I am a BPEL
implementer, I am facing the choice of either supporting all those possible
languages, or else contributing to undermining BPEL
portability.
Ugo
Brand,
Olivier, VF-GP&S Düsseldorf wrote:
Yaron,
I have reviewed the BPELJ whitepaper and I have several concerns / questions regarding this. I am concern on the approach which is "breaking" the portability of BPEL. This reminds me of some Java extensions that can be included in some XSLT (a vendor centric approach).
I believe there are two possible answers to this
concern:
- Portability is not as restricted as the XSLT example you cite, for Java
is also portable. One could reasonably expect quite a number of BPEL engines
that would support BPELJ, assuming that JSR 207 standardizes it, thus
avoiding vendor lock-in games.
- The BPELJ partner links could be changed to conventional service types.
This could be done without affecting the process, so there exists at least a
subset of BPELJ that could be regarded as portable, regardless of the
engine's support of Java.
Why don't we take the approach that IBM is following within their BPEL implementation: make use of the WSDL binding extensions to include other type of technology? I am talking here about WSIF. It seems to be a good approach. The BPEL compiler will be the one optimizing access to the objects.
I have spend a lot of time making similar points with my
colleagues. I have consistently run into the objection that packaging very
fine-grained data manipulation operations as Web services is a) an unnatural
act for a programmer, and b) incredibly inefficient. I have found some could
ways to counter the latter point (to some degree), but not the former. Does
anyone have some insight into the former line of argument?
The other point I wanted to raise is on the use of transactions. How would you (if you would) propagate a transaction from a Java component to a Web Service endpoint? I think that this raises the issue of not having a Web Service Transactional framework in place in the current BPEL spec. Why not advocating the use of WS-CAF which is the only standard in this space for managing transactions and context propagation? (Initiatives from IBM and Microsoft are not in any standardization bodies. Am I wrong?)
Transactions are also of great concern to me. WS-CAF
would appear to be the only standard in town worth considering in the WS
space. I would encourage the authors of proprietary alternatives to elements
of WS-CAF to either submit them to a standards setting organization ASAP, or
throw their weight behind the WS-CAF standard. We need to have a clear set of
standards to achieve interoperability between web services with appropriates
qualities of service to make them practical. (That's my personal opinion; I'm
just an engineer who wants to create something of value at the end of the
day.)
Perhaps the F2F next week will foster greater understanding of
transactions, and the standards space surrounding them. Choreology has made
some interestig proposals in the past, and I am not convinced that we have
properly digested them yet. Perhaps the focus that a F2F meeting brings will
help in this regard.
Cheers,
-Ron