For what it's worth, option #2 appeals to certain types of businesses that want to obfuscate the code of their processes for intellectual property protection.
alex Lance Waterman wrote: > 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. >> > > >> > > >> > >> >> >
