I like the idea of option #1 as well. My concerns with option #2 have to do with exposing engine artifacts and versioning/backward compatibility issues that can surface.
Perhaps the "how" discussion can address the validation tool that Guillaume mentions. Lance On 5/3/06, Zubin Wadia <[EMAIL PROTECTED]> wrote:
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. > > > > >
