Yes. I think we should define the structure and consistency rules of the deployment unit while allowing it to be deployed in an archive or directly on the file system.
The engine should provide a status for each deployment unit and a list of issues if deployment failed. (My interpretation of "failling gracefully") alex Lance Waterman wrote: > I think a developer centric deployment model is fine as long as we > articulate how the exploded-archive should be built ( i.e. all WSDL, > Schema, etc ... dependencies should be copied first and then the .bpel > file > ) and fail gracefully when artifacts can't be found. Is this what you > had in > mind? > > Lance > > On 5/3/06, Alex Boisvert <[EMAIL PROTECTED]> wrote: > >> >> >> As a developer, I'm a big fan of the exploded-archive format -- which >> is effectively an oximoron for no deployment archive -- where individual >> files are just moved or copied in a deployment area on the file system. >> >> I think this approach reduces the need for deployment tooling, reduces >> deployment times (faster test cycles) and reduces indirections, meaning >> that I know exactly what's deployed instead of guessing what's been put >> in the archive. >> >> It would be nice if the engine supported this kind of straight-through >> deployment in addition to the heavier archive deployment >> >> alex >> >> 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. >> >> >> >
