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. Cheers, Zubin. On 5/3/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
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. > >
