Yeah, I will agree with Guillaume - generally the commercial BPEL
Editor-Engine combos generally won't let you deploy any BPEL
Definition that
is deemed non-compliant or has vacant endpoints. I personally think
there is
merit to that decoupled approach. It's "Process Design by Contract"
and it
works for me.
+1 on the first version Matthieu recommended.
The difficult thing about getting a BPEL artifact assembled and
deployed is getting feedback about issues, and this was a usability
issue (IMHO) when we had a drop-and-deploy approach with PXE.
Fishing through the log to find out that you forgot something is
never fun.
The commercial editors have their place, although I've never thought
much of them. It is possible and even preferable to edit BPEL as XML
or to use a higher-level tool that generates BPEL from BPMN or
another more business-suitable notation. (I've always liked Gregor
Hohpe's characterization of "doodleware".)
There are a set of meaningful use cases for a "tool chain" that
focuses on validating BPEL, paticularly if you don't think about BPEL
as an originating artifact. Also, there will almost always be a need
to apply a specific profile to the BPEL that a user supplies. (This
will be less true in 2.0 than it was in 1.1 where there was
substantial ambiguity.)
FWIW, even PXE in its current form doesn't really compile the BPEL
into executable VPU code until deployment. The "compiler" actually
just builds the normalized process model and serializes it. There
are some neat things that you can do with JIT compilation of BPEL,
e.g., parameterized processes -- think about having something like a
velocity template that generates a BPEL process on demand.
--
Paul R Brown
[EMAIL PROTECTED]
http://mult.ifario.us/
