ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <boisv...@intalio.com>
Subject Re: Ode Deployment Unit
Date Wed, 03 May 2006 18:43:38 GMT

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 <zwadia@gmail.com> 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 <guillaume.nodet@worldonline.fr> 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.
>> > >
>> > >
>> >
>>
>>
>


Mime
View raw message