Late binding vs. early binding

[Matthieu Riou <ma...@gmail.com>]

Hi,

Currently when you deploy a process, very little gets loaded to save memory
(some people deploy a lot of processes without using them all). This kind of
goes with the dehydration but it's just that the default for now is to never
fully load a process as long as it's not used.

However this has some side effects. Mostly you can never be sure after
deployment that your process is fully okay, including the services that it
should invoke. Because the messaging layer loads the WSDL only at first
invocation, you might get a nasty error there saying that the services
declared in your deploy.xml don't exist at all in your WSDL. Which is
usually true but it's the kind of things you'd rather find out at deployment
time.

I'm going to change that a bit so that projects get "hydrated" at deployment
if no specific dehydration policy is defined. This way people who don't care
about lazy process loading can find out early about the problems their
processes might have. And those who care about the memory footprint can
still set an hydration policy and enjoy the lazy loading.

Anybody against this? Shout quick because I'm going to do that right now :)

Cheers,
Matthieu

Re: Late binding vs. early binding

[Matthieu Riou <ma...@gmail.com>]

Should be.

On 6/14/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> +1 and if we can get this to happen during the scope of
> DeploymentService.deployPackage(...) that's even better.
>
> alex
>
>
> On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > Hi,
> >
> > Currently when you deploy a process, very little gets loaded to save
> > memory
> > (some people deploy a lot of processes without using them all). This
> > kind of
> > goes with the dehydration but it's just that the default for now is to
> > never
> > fully load a process as long as it's not used.
> >
> > However this has some side effects. Mostly you can never be sure after
> > deployment that your process is fully okay, including the services that
> > it
> > should invoke. Because the messaging layer loads the WSDL only at first
> > invocation, you might get a nasty error there saying that the services
> > declared in your deploy.xml don't exist at all in your WSDL. Which is
> > usually true but it's the kind of things you'd rather find out at
> > deployment
> > time.
> >
> > I'm going to change that a bit so that projects get "hydrated" at
> > deployment
> > if no specific dehydration policy is defined. This way people who don't
> > care
> > about lazy process loading can find out early about the problems their
> > processes might have. And those who care about the memory footprint can
> > still set an hydration policy and enjoy the lazy loading.
> >
> > Anybody against this? Shout quick because I'm going to do that right now
> > :)
> >
> > Cheers,
> > Matthieu
> >
>
>

Re: Late binding vs. early binding

[Alex Boisvert <bo...@intalio.com>]

+1 and if we can get this to happen during the scope of
DeploymentService.deployPackage(...) that's even better.

alex


On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Hi,
>
> Currently when you deploy a process, very little gets loaded to save
> memory
> (some people deploy a lot of processes without using them all). This kind
> of
> goes with the dehydration but it's just that the default for now is to
> never
> fully load a process as long as it's not used.
>
> However this has some side effects. Mostly you can never be sure after
> deployment that your process is fully okay, including the services that it
> should invoke. Because the messaging layer loads the WSDL only at first
> invocation, you might get a nasty error there saying that the services
> declared in your deploy.xml don't exist at all in your WSDL. Which is
> usually true but it's the kind of things you'd rather find out at
> deployment
> time.
>
> I'm going to change that a bit so that projects get "hydrated" at
> deployment
> if no specific dehydration policy is defined. This way people who don't
> care
> about lazy process loading can find out early about the problems their
> processes might have. And those who care about the memory footprint can
> still set an hydration policy and enjoy the lazy loading.
>
> Anybody against this? Shout quick because I'm going to do that right now
> :)
>
> Cheers,
> Matthieu
>

Re: Late binding vs. early binding

[Matthieu Riou <ma...@gmail.com>]

Hi Antoine

it is possible that at deployment time, all the services have not been
> deployed yet to the server. So when deploying, it would raise an error,
> and
> that would induce an order in the deployment of the projects.


That's what I've changed yesterday in the trunk, now a deployment with bad
service references generates immediate deployment errors.

In the case that two projects call each other, it becomes impossible to
> deploy them. (each one targets the other port type of the other, each one
> defining the binding to its own port).


I'm not following here, if you have 2 processes using each other, either
they are in the same deployment package or if they are in two separate
packages, then each package include each others' WSDL. So practically
there's no problem I think.

Instead, would it be possible to pause the process, and alarm the user that
> a service/port/operation is missing, so that he has a change to deploy it
> ?


Why not just fail the deployment?

It would be great to validate the deploy.xml too, and issue some information
> like "This process will need this port type: " + portTypeName.


This should be done during deployment now.

What do you think ?
>
> Antoine
>
> On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > I agree with the intent but it has non trivial implications. In the
> > current
> > code base only the ILs now what a service really is, endpoints are
> > completely opaque to the server, which is good. And sometimes even the
> IL
> > doesn't know everything about an endpoint, only whatever we're hooked to
> > knows (think Axis2 or the JBI bus).
> >
> > I guess we could have some sort of "best effort" tool that tries to
> guess
> > which IL you want to use, tries to understand the format of your
> endpoints
> > and all that stuff. But if we write it with only SOAP/HTTP in mind and
> > somebody configures Axis2 to use JMS, the tool will fail even if your
> > endpoint is fine.
> >
> > On 6/14/07, Paul Brown <pa...@gmail.com> wrote:
> > >
> > > On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
> > > > Currently when you deploy a process, very little gets loaded to save
> > > memory
> > > > (some people deploy a lot of processes without using them all). This
> > > kind of
> > > > goes with the dehydration but it's just that the default for now is
> to
> > > never
> > > > fully load a process as long as it's not used.
> > > > However this has some side effects. Mostly you can never be sure
> after
> > > > deployment that your process is fully okay, including the services
> > that
> > > it
> > > > should invoke. Because the messaging layer loads the WSDL only at
> > first
> > > > invocation, you might get a nasty error there saying that the
> services
> > > > declared in your deploy.xml don't exist at all in your WSDL. Which
> is
> > > > usually true but it's the kind of things you'd rather find out at
> > > deployment
> > > > time.
> > >
> > > Hmmm.  Hmmmm.
> > >
> > > Well, this seems like functionality that should be part of the bpelc
> > > step in the toolchain and not part of deployment.  It's a usability
> > > nightmare to have to debug your process and accompanying metadata at
> > > deployment time only, and in a production/secure environment, getting
> > > access to logs may be inconvenient or impossible.  (This was part of
> > > the motivation for bpelc as a commandline tool in the first place...)
> > >
> > > How about a "deploycheck" commandline tool or other such that provides
> > > this functionality, either as an alternative to the less lazy loading
> > > or as an adjunct?  (Seems like we could just use the same code, more
> > > or less.)
> > >
> > > --
> > > paulrbrown@gmail.com
> > > http://mult.ifario.us/
> > >
> >
>
>
>
> --
> Intalio, the Open Source BPMS Company
> <a href="http://www.intalio.com">http://www.intalio.com</a>
> <a href="http://bpms.intalio.com">Community website:
> http://bpms.intalio.com</a>
>

Re: Late binding vs. early binding

[Antoine Toulme <at...@intalio.com>]

Hi Matthieu,

it is possible that at deployment time, all the services have not been
deployed yet to the server. So when deploying, it would raise an error, and
that would induce an order in the deployment of the projects.

In the case that two projects call each other, it becomes impossible to
deploy them. (each one targets the other port type of the other, each one
defining the binding to its own port).

Instead, would it be possible to pause the process, and alarm the user that
a service/port/operation is missing, so that he has a change to deploy it ?

It would be great to validate the deploy.xml too, and issue some information
like "This process will need this port type: " + portTypeName.

What do you think ?

Antoine

On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> I agree with the intent but it has non trivial implications. In the
> current
> code base only the ILs now what a service really is, endpoints are
> completely opaque to the server, which is good. And sometimes even the IL
> doesn't know everything about an endpoint, only whatever we're hooked to
> knows (think Axis2 or the JBI bus).
>
> I guess we could have some sort of "best effort" tool that tries to guess
> which IL you want to use, tries to understand the format of your endpoints
> and all that stuff. But if we write it with only SOAP/HTTP in mind and
> somebody configures Axis2 to use JMS, the tool will fail even if your
> endpoint is fine.
>
> On 6/14/07, Paul Brown <pa...@gmail.com> wrote:
> >
> > On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
> > > Currently when you deploy a process, very little gets loaded to save
> > memory
> > > (some people deploy a lot of processes without using them all). This
> > kind of
> > > goes with the dehydration but it's just that the default for now is to
> > never
> > > fully load a process as long as it's not used.
> > > However this has some side effects. Mostly you can never be sure after
> > > deployment that your process is fully okay, including the services
> that
> > it
> > > should invoke. Because the messaging layer loads the WSDL only at
> first
> > > invocation, you might get a nasty error there saying that the services
> > > declared in your deploy.xml don't exist at all in your WSDL. Which is
> > > usually true but it's the kind of things you'd rather find out at
> > deployment
> > > time.
> >
> > Hmmm.  Hmmmm.
> >
> > Well, this seems like functionality that should be part of the bpelc
> > step in the toolchain and not part of deployment.  It's a usability
> > nightmare to have to debug your process and accompanying metadata at
> > deployment time only, and in a production/secure environment, getting
> > access to logs may be inconvenient or impossible.  (This was part of
> > the motivation for bpelc as a commandline tool in the first place...)
> >
> > How about a "deploycheck" commandline tool or other such that provides
> > this functionality, either as an alternative to the less lazy loading
> > or as an adjunct?  (Seems like we could just use the same code, more
> > or less.)
> >
> > --
> > paulrbrown@gmail.com
> > http://mult.ifario.us/
> >
>



-- 
Intalio, the Open Source BPMS Company
<a href="http://www.intalio.com">http://www.intalio.com</a>
<a href="http://bpms.intalio.com">Community website: http://bpms.intalio.com</a>

Re: Late binding vs. early binding

[Matthieu Riou <ma...@gmail.com>]

I agree with the intent but it has non trivial implications. In the current
code base only the ILs now what a service really is, endpoints are
completely opaque to the server, which is good. And sometimes even the IL
doesn't know everything about an endpoint, only whatever we're hooked to
knows (think Axis2 or the JBI bus).

I guess we could have some sort of "best effort" tool that tries to guess
which IL you want to use, tries to understand the format of your endpoints
and all that stuff. But if we write it with only SOAP/HTTP in mind and
somebody configures Axis2 to use JMS, the tool will fail even if your
endpoint is fine.

On 6/14/07, Paul Brown <pa...@gmail.com> wrote:
>
> On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
> > Currently when you deploy a process, very little gets loaded to save
> memory
> > (some people deploy a lot of processes without using them all). This
> kind of
> > goes with the dehydration but it's just that the default for now is to
> never
> > fully load a process as long as it's not used.
> > However this has some side effects. Mostly you can never be sure after
> > deployment that your process is fully okay, including the services that
> it
> > should invoke. Because the messaging layer loads the WSDL only at first
> > invocation, you might get a nasty error there saying that the services
> > declared in your deploy.xml don't exist at all in your WSDL. Which is
> > usually true but it's the kind of things you'd rather find out at
> deployment
> > time.
>
> Hmmm.  Hmmmm.
>
> Well, this seems like functionality that should be part of the bpelc
> step in the toolchain and not part of deployment.  It's a usability
> nightmare to have to debug your process and accompanying metadata at
> deployment time only, and in a production/secure environment, getting
> access to logs may be inconvenient or impossible.  (This was part of
> the motivation for bpelc as a commandline tool in the first place...)
>
> How about a "deploycheck" commandline tool or other such that provides
> this functionality, either as an alternative to the less lazy loading
> or as an adjunct?  (Seems like we could just use the same code, more
> or less.)
>
> --
> paulrbrown@gmail.com
> http://mult.ifario.us/
>

Re: Late binding vs. early binding

[Paul Brown <pa...@gmail.com>]

On 6/14/07, Matthieu Riou <ma...@gmail.com> wrote:
> Currently when you deploy a process, very little gets loaded to save memory
> (some people deploy a lot of processes without using them all). This kind of
> goes with the dehydration but it's just that the default for now is to never
> fully load a process as long as it's not used.
> However this has some side effects. Mostly you can never be sure after
> deployment that your process is fully okay, including the services that it
> should invoke. Because the messaging layer loads the WSDL only at first
> invocation, you might get a nasty error there saying that the services
> declared in your deploy.xml don't exist at all in your WSDL. Which is
> usually true but it's the kind of things you'd rather find out at deployment
> time.

Hmmm.  Hmmmm.

Well, this seems like functionality that should be part of the bpelc
step in the toolchain and not part of deployment.  It's a usability
nightmare to have to debug your process and accompanying metadata at
deployment time only, and in a production/secure environment, getting
access to logs may be inconvenient or impossible.  (This was part of
the motivation for bpelc as a commandline tool in the first place...)

How about a "deploycheck" commandline tool or other such that provides
this functionality, either as an alternative to the less lazy loading
or as an adjunct?  (Seems like we could just use the same code, more
or less.)

-- 
paulrbrown@gmail.com
http://mult.ifario.us/