Deployment Bundle and process versioning

[buddhika chamith <ch...@gmail.com>]

Hi all,

I am using DeploymentWebService to deploy and undeploy processes. I have the
following scenario.

I am using a process bundle named HelloBPEL.zip which contains a process
named HelloBPELProcess. So as you can see the bundle and the process names
are different. Now when I deploy the service I get HelloBPELProcess-1 in my
response as the process id. I am extracting this id and later use it as the
packageName value of the undeploy message sent in order undeploy the
process. But it fails since the engine cannot find a directory by the name
of HelloBPELProcess-1 because the actual directory created is named
HelloBPEL-1.

Now I have following observations about this scenario.

 - I think it would be more beneficial to have the process id in undeploy
SOAP message rather than the packageName which it currently expects for
following reasons.

1. Since process id is returned to the client in case of deployment success
it would more natural to the client to extract out this value and later use
it to undeploy the process rather than using the packageName which is not
returned in deployment response. Since the packageName with the version
number is generated from the engine and pacakageName is not returned in the
deployment response as well, client will have to include some seperate logic
to extract out version number from returned process id and append it to the
original bundle name to get the packageName.

2. There may be cases that more than one process is present in a single
deployment bundle. So by invoking undeploy using packageName causes the
whole bundle to be deleted even if only one of the contained processes is
required to be undeployed.

So I think it would be better to have user to return the process id for
undeploy operation. The engine should therefore maintain some mapping
between deployed bundle pacakgaeNames and process ids contained within them.
When the count of process ids' contained within the deployed bundle pacakge
come down to zero only the deployment bundle should be deleted.

WDYT of these suggestions or am I missing some thing big? :-)

Best Regards,
Chamith

Re: Deployment Bundle and process versioning

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

On Sun, Apr 26, 2009 at 1:24 AM, buddhika chamith
<ch...@gmail.com>wrote:

> Hi all,
>
> Regarding the 2nd point in the earlier mail.
> After going through the sources I realized that the undeployment behavior
> is
> bundle specific not process specific. I mean when a bundle is undeployed
> all
> the processes within it is undeployed. So there is no way to selectively
> undeploy a process within a bundle as far as I can see. Please correct me
> if
> I am wrong here.
>
> My question is, is this just a matter of perspective? Like basic
> undeployment unit should be a bundle not a process? Or are there another
> reasons for this? One reason I can think of is processes within the same
> bundle may be related and may include calls within themselves. So
> undeploying one of them may cause others to malfunction. Am I right here?
>
> But then again, if this is the case, I think the client is supposed be
> knowledegeble about such dependancies when making requests for undeployment
> in such scenarios and he has to take measures to prevent such situations.
> So
> we may be able to have a overloaded method to just undeploy a process
> definition alongside with undeployment of a bundle so that a client will
> have the option of undeploying a bundle or just a process contained within.
>
> Any suggestions on this is highly appreciated.
>

Deployment and undeployment are all handled at the bundle level and as you
mentioned, a bundle is a logical group of processes. It's particularly
useful when you start using versioning instead of always undeploying as all
processes in the bundle are versioned together.

Matthieu


>
> Best Regards,
> Chamith
>
>
> On Sun, Apr 26, 2009 at 1:00 PM, buddhika chamith
> <ch...@gmail.com>wrote:
>
> > Hi all,
> >
> > I am using DeploymentWebService to deploy and undeploy processes. I have
> > the following scenario.
> >
> > I am using a process bundle named HelloBPEL.zip which contains a process
> > named HelloBPELProcess. So as you can see the bundle and the process
> names
> > are different. Now when I deploy the service I get HelloBPELProcess-1 in
> my
> > response as the process id. I am extracting this id and later use it as
> the
> > packageName value of the undeploy message sent in order undeploy the
> > process. But it fails since the engine cannot find a directory by the
> name
> > of HelloBPELProcess-1 because the actual directory created is named
> > HelloBPEL-1.
> >
> > Now I have following observations about this scenario.
> >
> >  - I think it would be more beneficial to have the process id in undeploy
> > SOAP message rather than the packageName which it currently expects for
> > following reasons.
> >
> > 1. Since process id is returned to the client in case of deployment
> success
> > it would more natural to the client to extract out this value and later
> use
> > it to undeploy the process rather than using the packageName which is not
> > returned in deployment response. Since the packageName with the version
> > number is generated from the engine and pacakageName is not returned in
> the
> > deployment response as well, client will have to include some seperate
> logic
> > to extract out version number from returned process id and append it to
> the
> > original bundle name to get the packageName.
> >
> > 2. There may be cases that more than one process is present in a single
> > deployment bundle. So by invoking undeploy using packageName causes the
> > whole bundle to be deleted even if only one of the contained processes is
> > required to be undeployed.
> >
> > So I think it would be better to have user to return the process id for
> > undeploy operation. The engine should therefore maintain some mapping
> > between deployed bundle pacakgaeNames and process ids contained within
> them.
> > When the count of process ids' contained within the deployed bundle
> pacakge
> > come down to zero only the deployment bundle should be deleted.
> >
> > WDYT of these suggestions or am I missing some thing big? :-)
> >
> > Best Regards,
> > Chamith
> >
> >
>

Re: Deployment Bundle and process versioning

[buddhika chamith <ch...@gmail.com>]

Hi all,

Regarding the 2nd point in the earlier mail.
After going through the sources I realized that the undeployment behavior is
bundle specific not process specific. I mean when a bundle is undeployed all
the processes within it is undeployed. So there is no way to selectively
undeploy a process within a bundle as far as I can see. Please correct me if
I am wrong here.

My question is, is this just a matter of perspective? Like basic
undeployment unit should be a bundle not a process? Or are there another
reasons for this? One reason I can think of is processes within the same
bundle may be related and may include calls within themselves. So
undeploying one of them may cause others to malfunction. Am I right here?

But then again, if this is the case, I think the client is supposed be
knowledegeble about such dependancies when making requests for undeployment
in such scenarios and he has to take measures to prevent such situations. So
we may be able to have a overloaded method to just undeploy a process
definition alongside with undeployment of a bundle so that a client will
have the option of undeploying a bundle or just a process contained within.

Any suggestions on this is highly appreciated.

Best Regards,
Chamith


On Sun, Apr 26, 2009 at 1:00 PM, buddhika chamith
<ch...@gmail.com>wrote:

> Hi all,
>
> I am using DeploymentWebService to deploy and undeploy processes. I have
> the following scenario.
>
> I am using a process bundle named HelloBPEL.zip which contains a process
> named HelloBPELProcess. So as you can see the bundle and the process names
> are different. Now when I deploy the service I get HelloBPELProcess-1 in my
> response as the process id. I am extracting this id and later use it as the
> packageName value of the undeploy message sent in order undeploy the
> process. But it fails since the engine cannot find a directory by the name
> of HelloBPELProcess-1 because the actual directory created is named
> HelloBPEL-1.
>
> Now I have following observations about this scenario.
>
>  - I think it would be more beneficial to have the process id in undeploy
> SOAP message rather than the packageName which it currently expects for
> following reasons.
>
> 1. Since process id is returned to the client in case of deployment success
> it would more natural to the client to extract out this value and later use
> it to undeploy the process rather than using the packageName which is not
> returned in deployment response. Since the packageName with the version
> number is generated from the engine and pacakageName is not returned in the
> deployment response as well, client will have to include some seperate logic
> to extract out version number from returned process id and append it to the
> original bundle name to get the packageName.
>
> 2. There may be cases that more than one process is present in a single
> deployment bundle. So by invoking undeploy using packageName causes the
> whole bundle to be deleted even if only one of the contained processes is
> required to be undeployed.
>
> So I think it would be better to have user to return the process id for
> undeploy operation. The engine should therefore maintain some mapping
> between deployed bundle pacakgaeNames and process ids contained within them.
> When the count of process ids' contained within the deployed bundle pacakge
> come down to zero only the deployment bundle should be deleted.
>
> WDYT of these suggestions or am I missing some thing big? :-)
>
> Best Regards,
> Chamith
>
>