Is there a real need for a pre-compiled packaging ?
I think the only reason (as you said) is to be able to discover errors
earlier, but this could also be done by a validating tool , without the
need to package.
Such a tool would be usefull to integrate into EDI (without packaging),
so ...
Cheers,
Guillaume Nodet
Matthieu Riou wrote:
Hi,
Lance mentioned before the need to agree on a deployment format for
Ode, in short to answer to the question "what will I deploy in Ode?".
Note that the question is 'what', not 'how' (yet). To start the debate
I'll just drop some of the requirements I'd have, to see what you guys
think.
First, we could support two types of deployment unit, just like any
J2EE app server does:
1. A raw format with no prior compilation, generation whatsoever. The
magic happens on deployment.
2. A compiled, validated, ready to use format. Upon deployment this
thing is just opened, read and we're ready to go.
For this first format, I think we just need a self containing archive,
including not only the process representation but also wsdl, xsl,
deployment descriptor, whatever... End of requirements.
The second format should be compiled and validated. So most (if not
all) possible errors in the original bpel description, the wsld or
anything else should be detected during the step that produces this
deployment unit. The compiled version of the process should be as
close as possible to the definition model used at runtime (something
like a pre-processed object tree).
This two format wouldn't be exclusive, it's just 2 steps in the
lifetime of our deployed package. This 2 steps can happen all at one
time (1 -> 2 -> running) or one after another (1 -> 2 // 2 ->
running).
Thoughts? Comments? Criticisms? Flames?
Matthieu.
