ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Ode Deployment Unit
Date Wed, 03 May 2006 19:28:31 GMT
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 <boisvert@intalio.com> 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.
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message