Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Nils Pedersen
I'm experiencing  a problem  with  reusing the same BPEL  SU  in  
multiple SA's and deploying them to the same ESB instance.
The deployment fails with an error stating that the endpoint already
exist (referring to the endpoint name on the properties of the "Provide"
of the BPEL SU inside the CASA editor).
This is the case even if the BPEL is based on an abstract WSDL
definition and the only endpoints (BC's) connected to the BPEL SE is
defined through the CASA's.
And yes each of the CASA assemblies has different endpoint addresses.
I've tried the same scenarios but using JEE SU's instead, and that works
like a charm.

I have a suspicion that this issue is related to how the BPEL SE handles
the BPEL definitions and that this is related to how it "handles"
multiple versions of the same BPEL definition.Even if they're deployed
packaged inside different CASA projects.
Can anybody verify what I'm experiencing is correct and perhaps even
shed some light if this is acting as supposed to or if I'm experiencing
a "bug".

YS

Nils
PS! IMHO if this is working as expected it highly limits the way you may
reuse BPEL definitions in different CASA's. And it seems that it sort of
breaks up the expected behavior of SU's packaged in SA's.

--
Sun Microsystems <http://www.java.com> * Nils Pedersen *
SOA Deployment Architect

*Sun Microsystems, Inc.*
Sognsveien 75
Oslo NO-0805 NO
Phone x43738/+47-23-369 738
Mobile +4790645848
Email [hidden email]
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Andreas Egloff
Do I understand your scenario correctly: you have a copy of the same SU
(i.e. with the same endpoints defined in them) in more than one
composite application (SA)?

Today we do not support an application private namespace. That is,
service/endpoint names in your application are shared and visible to
every application on the ESB. This also means these public names need to
be unique.

What is expected today is that you can share this SU by referencing one
instance in multiple applications (SAs) rather than dupplicating it in
each application. If you do want to duplicate it (copy it into) each
application, it expects unique names for the services.

If would be great if you could share the exact motivations/use cases of
why this may not be suitable for your needs. We have been discussing the
application private / ESB visibility / External visibility namespaces
for a while, but we have not had the concrete business drivers to
prioritize such an enhancement.

Thanks,
Andi

Nils Pedersen wrote:

> I'm experiencing  a problem  with  reusing the same BPEL  SU  in  
> multiple SA's and deploying them to the same ESB instance.
> The deployment fails with an error stating that the endpoint already
> exist (referring to the endpoint name on the properties of the
> "Provide" of the BPEL SU inside the CASA editor).
> This is the case even if the BPEL is based on an abstract WSDL
> definition and the only endpoints (BC's) connected to the BPEL SE is
> defined through the CASA's.
> And yes each of the CASA assemblies has different endpoint addresses.
> I've tried the same scenarios but using JEE SU's instead, and that
> works like a charm.
>
> I have a suspicion that this issue is related to how the BPEL SE
> handles the BPEL definitions and that this is related to how it
> "handles" multiple versions of the same BPEL definition.Even if
> they're deployed packaged inside different CASA projects.
> Can anybody verify what I'm experiencing is correct and perhaps even
> shed some light if this is acting as supposed to or if I'm
> experiencing a "bug".
>
> YS
>
> Nils
> PS! IMHO if this is working as expected it highly limits the way you
> may reuse BPEL definitions in different CASA's. And it seems that it
> sort of breaks up the expected behavior of SU's packaged in SA's.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Nils Pedersen
Well, what I do is rather straight forward:
1. Create a BPEL module
2. Create an abstract WSDL (no bindings or services defined)
3. Create a BP and use the WSDL from 2. as the BP service def.
    The content of the process does not matter here, but you might want
to just add an assign of some sort between receive and reply of th BP
just for ensuring it actually works.
4. Create a CASA and add the BPEL module to the CASA.
5. Drag any BC (for this exercise just use the SOAP BC) and bind it to
the provider icon of the BPEL module in the CASA editor. Remember to
change the endpoint address of the BC to something  unique.
6. Deploy the CASA. You might want to create a test case and verify that
the CASA has been successfully deployed and is running correctly.
7. Repeat steps 4 to 6 (reusing the BPEL module you created in 1.), but
remember to change the endpoint address of the SOAP BC.
This will fail during deployment of the second CASA, unless you undeploy
the first. The failure is due to the "internal" provider endpoint name
(which you cannot change) on the BPEL module in the CASA editor.
If you do the same exercise but use a EJB project (JEE SU) instead of a
BPEL module it works as expected (both CASA's get successfully deployed
and are working perfectly.

Now to the use case of this scenario:
Given the fact that you often create want to reuse SU's (and in this
case BPEL definitions) in different applications should not force you to
do this as only external services. If so you will force it to do
networking for each of this invocations and that will not scale in a
larger deployment (actually it does not have to. If all SU's that you
want to reuse has to be deployed as simple standalone CASA's you will
simply end up with a much too fragmented service landscape to keep track
of (and you will not have to do more then let's say 20 reusable
components and you start to see the picture. Working with a project that
would quickly end up with more than 100 SU's/SA's). Another point here
is that by forcing reuse by single instance, it would not be possible to
have uneven updates of the shared SU across the CA's using it.

And why is it working with the JEE SE modules and not the BPEL. And
according to the error message the reason is because of the Provider
endpoint on the BPEL module in the CASA editor. I would have understood
it if it was the BC endpoint address of the CASA (which is what is being
exposed to the surroundings). And even if that was a limitation, why
can't we allow for the provider endpoint name to be changed in the CASA
editor?

This all boils down to how the platform allows for different strategies
and solution designs for reuse of your components.

YS

Nils
PS! I would be happy to RAR some sample project so you could see the two
exercises.


Andreas Egloff wrote:

> Do I understand your scenario correctly: you have a copy of the same
> SU (i.e. with the same endpoints defined in them) in more than one
> composite application (SA)?
>
> Today we do not support an application private namespace. That is,
> service/endpoint names in your application are shared and visible to
> every application on the ESB. This also means these public names need
> to be unique.
>
> What is expected today is that you can share this SU by referencing
> one instance in multiple applications (SAs) rather than dupplicating
> it in each application. If you do want to duplicate it (copy it into)
> each application, it expects unique names for the services.
>
> If would be great if you could share the exact motivations/use cases
> of why this may not be suitable for your needs. We have been
> discussing the application private / ESB visibility / External
> visibility namespaces for a while, but we have not had the concrete
> business drivers to prioritize such an enhancement.
>
> Thanks,
> Andi
>
> Nils Pedersen wrote:
>> I'm experiencing  a problem  with  reusing the same BPEL  SU  in  
>> multiple SA's and deploying them to the same ESB instance.
>> The deployment fails with an error stating that the endpoint already
>> exist (referring to the endpoint name on the properties of the
>> "Provide" of the BPEL SU inside the CASA editor).
>> This is the case even if the BPEL is based on an abstract WSDL
>> definition and the only endpoints (BC's) connected to the BPEL SE is
>> defined through the CASA's.
>> And yes each of the CASA assemblies has different endpoint addresses.
>> I've tried the same scenarios but using JEE SU's instead, and that
>> works like a charm.
>>
>> I have a suspicion that this issue is related to how the BPEL SE
>> handles the BPEL definitions and that this is related to how it
>> "handles" multiple versions of the same BPEL definition.Even if
>> they're deployed packaged inside different CASA projects.
>> Can anybody verify what I'm experiencing is correct and perhaps even
>> shed some light if this is acting as supposed to or if I'm
>> experiencing a "bug".
>>
>> YS
>>
>> Nils
>> PS! IMHO if this is working as expected it highly limits the way you
>> may reuse BPEL definitions in different CASA's. And it seems that it
>> sort of breaks up the expected behavior of SU's packaged in SA's.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Sun Microsystems <http://www.java.com> * Nils Pedersen *
SOA Deployment Architect

*Sun Microsystems, Inc.*
Sognsveien 75
Oslo NO-0805 NO
Phone x43738/+47-23-369 738
Mobile +4790645848
Email [hidden email]
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

jbaragry
Nils. This should fail.
If I remember the spec correctly, a Service is uniquely idenitified by its QName (namespace + service name).

It looks like you are deploying 2 services (BPEL SUs) with the same QName, which is why you get the deploy error. It doesn't matter if they are communicating with different HTTP SUs in different SAs. The JBI runtime requires unique names for the SUs.

Check out this discussion on reusability of Service Units.
http://blogs.sun.com/jason/entry/packaging_and_deploying_reusable_services

BTW, I think you are working too hard. You and I have discussed this issue before which led me to write the blog entry in the first place :)

cheers
Jason


On Thu, Sep 4, 2008 at 12:14 AM, Nils Pedersen <[hidden email]> wrote:
Well, what I do is rather straight forward:
1. Create a BPEL module
2. Create an abstract WSDL (no bindings or services defined)
3. Create a BP and use the WSDL from 2. as the BP service def.
  The content of the process does not matter here, but you might want to just add an assign of some sort between receive and reply of th BP just for ensuring it actually works.
4. Create a CASA and add the BPEL module to the CASA.
5. Drag any BC (for this exercise just use the SOAP BC) and bind it to the provider icon of the BPEL module in the CASA editor. Remember to change the endpoint address of the BC to something  unique.
6. Deploy the CASA. You might want to create a test case and verify that the CASA has been successfully deployed and is running correctly.
7. Repeat steps 4 to 6 (reusing the BPEL module you created in 1.), but remember to change the endpoint address of the SOAP BC.
This will fail during deployment of the second CASA, unless you undeploy the first. The failure is due to the "internal" provider endpoint name (which you cannot change) on the BPEL module in the CASA editor.
If you do the same exercise but use a EJB project (JEE SU) instead of a BPEL module it works as expected (both CASA's get successfully deployed and are working perfectly.

Now to the use case of this scenario:
Given the fact that you often create want to reuse SU's (and in this case BPEL definitions) in different applications should not force you to do this as only external services. If so you will force it to do networking for each of this invocations and that will not scale in a larger deployment (actually it does not have to. If all SU's that you want to reuse has to be deployed as simple standalone CASA's you will simply end up with a much too fragmented service landscape to keep track of (and you will not have to do more then let's say 20 reusable components and you start to see the picture. Working with a project that would quickly end up with more than 100 SU's/SA's). Another point here is that by forcing reuse by single instance, it would not be possible to have uneven updates of the shared SU across the CA's using it.

And why is it working with the JEE SE modules and not the BPEL. And according to the error message the reason is because of the Provider endpoint on the BPEL module in the CASA editor. I would have understood it if it was the BC endpoint address of the CASA (which is what is being exposed to the surroundings). And even if that was a limitation, why can't we allow for the provider endpoint name to be changed in the CASA editor?

This all boils down to how the platform allows for different strategies and solution designs for reuse of your components.

YS

Nils
PS! I would be happy to RAR some sample project so you could see the two exercises.



Andreas Egloff wrote:
Do I understand your scenario correctly: you have a copy of the same SU (i.e. with the same endpoints defined in them) in more than one composite application (SA)?

Today we do not support an application private namespace. That is, service/endpoint names in your application are shared and visible to every application on the ESB. This also means these public names need to be unique.

What is expected today is that you can share this SU by referencing one instance in multiple applications (SAs) rather than dupplicating it in each application. If you do want to duplicate it (copy it into) each application, it expects unique names for the services.

If would be great if you could share the exact motivations/use cases of why this may not be suitable for your needs. We have been discussing the application private / ESB visibility / External visibility namespaces for a while, but we have not had the concrete business drivers to prioritize such an enhancement.

Thanks,
Andi

Nils Pedersen wrote:
I'm experiencing  a problem  with  reusing the same BPEL  SU  in  multiple SA's and deploying them to the same ESB instance.
The deployment fails with an error stating that the endpoint already exist (referring to the endpoint name on the properties of the "Provide" of the BPEL SU inside the CASA editor).
This is the case even if the BPEL is based on an abstract WSDL definition and the only endpoints (BC's) connected to the BPEL SE is defined through the CASA's.
And yes each of the CASA assemblies has different endpoint addresses.
I've tried the same scenarios but using JEE SU's instead, and that works like a charm.

I have a suspicion that this issue is related to how the BPEL SE handles the BPEL definitions and that this is related to how it "handles" multiple versions of the same BPEL definition.Even if they're deployed packaged inside different CASA projects.
Can anybody verify what I'm experiencing is correct and perhaps even shed some light if this is acting as supposed to or if I'm experiencing a "bug".

YS

Nils
PS! IMHO if this is working as expected it highly limits the way you may reuse BPEL definitions in different CASA's. And it seems that it sort of breaks up the expected behavior of SU's packaged in SA's.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Sun Microsystems <http://www.java.com>  * Nils Pedersen *
SOA Deployment Architect

*Sun Microsystems, Inc.*
Sognsveien 75
Oslo NO-0805 NO
Phone x43738/+47-23-369 738
Mobile +4790645848
Email [hidden email]
NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Nils Pedersen
And to the blog entry I totally agree; the QName of the provider needs
to unique on the NMR or else it would not be possible to route
invokation over the NMR (similar of having two JAR files in the same
class loader with the same class definition in them) , and yes I recall
that you and I have had this discussion before.

There reason why this pops up again is: What I try to do with BPEL SU's
works for JEE SU's (and SQL SU's), so why not BPEL SU's?
Your comment should then apply to any SU, right? But this is not the
case. The SU's that stands out and doesn't work (so far in my testing)
are the BPEL SU's (no I haven't tested every SE, only JEE, SQL and BPEL).

I'll probably just have to let this one go, but for my own interest it
would be nice to know why there is a difference in how the SE's/SU's behave.

Nils

Jason Baragry wrote:

> Nils. This should fail.
> If I remember the spec correctly, a Service is uniquely idenitified by
> its QName (namespace + service name).
>
> It looks like you are deploying 2 services (BPEL SUs) with the same
> QName, which is why you get the deploy error. It doesn't matter if
> they are communicating with different HTTP SUs in different SAs. The
> JBI runtime requires unique names for the SUs.
>
> Check out this discussion on reusability of Service Units.
> http://blogs.sun.com/jason/entry/packaging_and_deploying_reusable_services
>
> BTW, I think you are working too hard. You and I have discussed this
> issue before which led me to write the blog entry in the first place :)
>
> cheers
> Jason
>
>
> On Thu, Sep 4, 2008 at 12:14 AM, Nils Pedersen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Well, what I do is rather straight forward:
>     1. Create a BPEL module
>     2. Create an abstract WSDL (no bindings or services defined)
>     3. Create a BP and use the WSDL from 2. as the BP service def.
>       The content of the process does not matter here, but you might
>     want to just add an assign of some sort between receive and reply
>     of th BP just for ensuring it actually works.
>     4. Create a CASA and add the BPEL module to the CASA.
>     5. Drag any BC (for this exercise just use the SOAP BC) and bind
>     it to the provider icon of the BPEL module in the CASA editor.
>     Remember to change the endpoint address of the BC to something
>      unique.
>     6. Deploy the CASA. You might want to create a test case and
>     verify that the CASA has been successfully deployed and is running
>     correctly.
>     7. Repeat steps 4 to 6 (reusing the BPEL module you created in
>     1.), but remember to change the endpoint address of the SOAP BC.
>     This will fail during deployment of the second CASA, unless you
>     undeploy the first. The failure is due to the "internal" provider
>     endpoint name (which you cannot change) on the BPEL module in the
>     CASA editor.
>     If you do the same exercise but use a EJB project (JEE SU) instead
>     of a BPEL module it works as expected (both CASA's get
>     successfully deployed and are working perfectly.
>
>     Now to the use case of this scenario:
>     Given the fact that you often create want to reuse SU's (and in
>     this case BPEL definitions) in different applications should not
>     force you to do this as only external services. If so you will
>     force it to do networking for each of this invocations and that
>     will not scale in a larger deployment (actually it does not have
>     to. If all SU's that you want to reuse has to be deployed as
>     simple standalone CASA's you will simply end up with a much too
>     fragmented service landscape to keep track of (and you will not
>     have to do more then let's say 20 reusable components and you
>     start to see the picture. Working with a project that would
>     quickly end up with more than 100 SU's/SA's). Another point here
>     is that by forcing reuse by single instance, it would not be
>     possible to have uneven updates of the shared SU across the CA's
>     using it.
>
>     And why is it working with the JEE SE modules and not the BPEL.
>     And according to the error message the reason is because of the
>     Provider endpoint on the BPEL module in the CASA editor. I would
>     have understood it if it was the BC endpoint address of the CASA
>     (which is what is being exposed to the surroundings). And even if
>     that was a limitation, why can't we allow for the provider
>     endpoint name to be changed in the CASA editor?
>
>     This all boils down to how the platform allows for different
>     strategies and solution designs for reuse of your components.
>
>     YS
>
>     Nils
>     PS! I would be happy to RAR some sample project so you could see
>     the two exercises.
>
>
>
>     Andreas Egloff wrote:
>
>         Do I understand your scenario correctly: you have a copy of
>         the same SU (i.e. with the same endpoints defined in them) in
>         more than one composite application (SA)?
>
>         Today we do not support an application private namespace. That
>         is, service/endpoint names in your application are shared and
>         visible to every application on the ESB. This also means these
>         public names need to be unique.
>
>         What is expected today is that you can share this SU by
>         referencing one instance in multiple applications (SAs) rather
>         than dupplicating it in each application. If you do want to
>         duplicate it (copy it into) each application, it expects
>         unique names for the services.
>
>         If would be great if you could share the exact motivations/use
>         cases of why this may not be suitable for your needs. We have
>         been discussing the application private / ESB visibility /
>         External visibility namespaces for a while, but we have not
>         had the concrete business drivers to prioritize such an
>         enhancement.
>
>         Thanks,
>         Andi
>
>         Nils Pedersen wrote:
>
>             I'm experiencing  a problem  with  reusing the same BPEL
>              SU  in  multiple SA's and deploying them to the same ESB
>             instance.
>             The deployment fails with an error stating that the
>             endpoint already exist (referring to the endpoint name on
>             the properties of the "Provide" of the BPEL SU inside the
>             CASA editor).
>             This is the case even if the BPEL is based on an abstract
>             WSDL definition and the only endpoints (BC's) connected to
>             the BPEL SE is defined through the CASA's.
>             And yes each of the CASA assemblies has different endpoint
>             addresses.
>             I've tried the same scenarios but using JEE SU's instead,
>             and that works like a charm.
>
>             I have a suspicion that this issue is related to how the
>             BPEL SE handles the BPEL definitions and that this is
>             related to how it "handles" multiple versions of the same
>             BPEL definition.Even if they're deployed packaged inside
>             different CASA projects.
>             Can anybody verify what I'm experiencing is correct and
>             perhaps even shed some light if this is acting as supposed
>             to or if I'm experiencing a "bug".
>
>             YS
>
>             Nils
>             PS! IMHO if this is working as expected it highly limits
>             the way you may reuse BPEL definitions in different
>             CASA's. And it seems that it sort of breaks up the
>             expected behavior of SU's packaged in SA's.
>
>
>
>         ---------------------------------------------------------------------
>         To unsubscribe, e-mail:
>         [hidden email]
>         <mailto:[hidden email]>
>         For additional commands, e-mail:
>         [hidden email]
>         <mailto:[hidden email]>
>
>
>     --
>     Sun Microsystems <http://www.java.com>  * Nils Pedersen *
>     SOA Deployment Architect
>
>     *Sun Microsystems, Inc.*
>     Sognsveien 75
>     Oslo NO-0805 NO
>     Phone x43738/+47-23-369 738
>     Mobile +4790645848
>     Email [hidden email]
>     NOTICE: This email message is for the sole use of the intended
>     recipient(s) and may contain confidential and privileged
>     information. Any unauthorized review, use, disclosure or
>     distribution is prohibited. If you are not the intended recipient,
>     please contact the sender by reply email and destroy all copies of
>     the original message.
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

--
Sun Microsystems <http://www.java.com> * Nils Pedersen *
SOA Deployment Architect

*Sun Microsystems, Inc.*
Sognsveien 75
Oslo NO-0805 NO
Phone x43738/+47-23-369 738
Mobile +4790645848
Email [hidden email]
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Murali Pottlapelli
Hi Nils,
BPEL SU behavior is correct. If you need to use the SU in multiple
applications you need to use it as reference as suggested by Jason.

I am surprised why other SUs are not behaving the same, we need to
analyze them. Most likely  would result in bugs.

Regards
Murali

Nils Pedersen wrote:

> And to the blog entry I totally agree; the QName of the provider needs
> to unique on the NMR or else it would not be possible to route
> invokation over the NMR (similar of having two JAR files in the same
> class loader with the same class definition in them) , and yes I
> recall that you and I have had this discussion before.
>
> There reason why this pops up again is: What I try to do with BPEL
> SU's works for JEE SU's (and SQL SU's), so why not BPEL SU's?
> Your comment should then apply to any SU, right? But this is not the
> case. The SU's that stands out and doesn't work (so far in my testing)
> are the BPEL SU's (no I haven't tested every SE, only JEE, SQL and BPEL).
>
> I'll probably just have to let this one go, but for my own interest it
> would be nice to know why there is a difference in how the SE's/SU's
> behave.
>
> Nils
>
> Jason Baragry wrote:
>> Nils. This should fail.
>> If I remember the spec correctly, a Service is uniquely idenitified
>> by its QName (namespace + service name).
>>
>> It looks like you are deploying 2 services (BPEL SUs) with the same
>> QName, which is why you get the deploy error. It doesn't matter if
>> they are communicating with different HTTP SUs in different SAs. The
>> JBI runtime requires unique names for the SUs.
>>
>> Check out this discussion on reusability of Service Units.
>> http://blogs.sun.com/jason/entry/packaging_and_deploying_reusable_services 
>>
>>
>> BTW, I think you are working too hard. You and I have discussed this
>> issue before which led me to write the blog entry in the first place :)
>>
>> cheers
>> Jason
>>
>>
>> On Thu, Sep 4, 2008 at 12:14 AM, Nils Pedersen <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Well, what I do is rather straight forward:
>>     1. Create a BPEL module
>>     2. Create an abstract WSDL (no bindings or services defined)
>>     3. Create a BP and use the WSDL from 2. as the BP service def.
>>       The content of the process does not matter here, but you might
>>     want to just add an assign of some sort between receive and reply
>>     of th BP just for ensuring it actually works.
>>     4. Create a CASA and add the BPEL module to the CASA.
>>     5. Drag any BC (for this exercise just use the SOAP BC) and bind
>>     it to the provider icon of the BPEL module in the CASA editor.
>>     Remember to change the endpoint address of the BC to something
>>      unique.
>>     6. Deploy the CASA. You might want to create a test case and
>>     verify that the CASA has been successfully deployed and is running
>>     correctly.
>>     7. Repeat steps 4 to 6 (reusing the BPEL module you created in
>>     1.), but remember to change the endpoint address of the SOAP BC.
>>     This will fail during deployment of the second CASA, unless you
>>     undeploy the first. The failure is due to the "internal" provider
>>     endpoint name (which you cannot change) on the BPEL module in the
>>     CASA editor.
>>     If you do the same exercise but use a EJB project (JEE SU) instead
>>     of a BPEL module it works as expected (both CASA's get
>>     successfully deployed and are working perfectly.
>>
>>     Now to the use case of this scenario:
>>     Given the fact that you often create want to reuse SU's (and in
>>     this case BPEL definitions) in different applications should not
>>     force you to do this as only external services. If so you will
>>     force it to do networking for each of this invocations and that
>>     will not scale in a larger deployment (actually it does not have
>>     to. If all SU's that you want to reuse has to be deployed as
>>     simple standalone CASA's you will simply end up with a much too
>>     fragmented service landscape to keep track of (and you will not
>>     have to do more then let's say 20 reusable components and you
>>     start to see the picture. Working with a project that would
>>     quickly end up with more than 100 SU's/SA's). Another point here
>>     is that by forcing reuse by single instance, it would not be
>>     possible to have uneven updates of the shared SU across the CA's
>>     using it.
>>
>>     And why is it working with the JEE SE modules and not the BPEL.
>>     And according to the error message the reason is because of the
>>     Provider endpoint on the BPEL module in the CASA editor. I would
>>     have understood it if it was the BC endpoint address of the CASA
>>     (which is what is being exposed to the surroundings). And even if
>>     that was a limitation, why can't we allow for the provider
>>     endpoint name to be changed in the CASA editor?
>>
>>     This all boils down to how the platform allows for different
>>     strategies and solution designs for reuse of your components.
>>
>>     YS
>>
>>     Nils
>>     PS! I would be happy to RAR some sample project so you could see
>>     the two exercises.
>>
>>
>>
>>     Andreas Egloff wrote:
>>
>>         Do I understand your scenario correctly: you have a copy of
>>         the same SU (i.e. with the same endpoints defined in them) in
>>         more than one composite application (SA)?
>>
>>         Today we do not support an application private namespace. That
>>         is, service/endpoint names in your application are shared and
>>         visible to every application on the ESB. This also means these
>>         public names need to be unique.
>>
>>         What is expected today is that you can share this SU by
>>         referencing one instance in multiple applications (SAs) rather
>>         than dupplicating it in each application. If you do want to
>>         duplicate it (copy it into) each application, it expects
>>         unique names for the services.
>>
>>         If would be great if you could share the exact motivations/use
>>         cases of why this may not be suitable for your needs. We have
>>         been discussing the application private / ESB visibility /
>>         External visibility namespaces for a while, but we have not
>>         had the concrete business drivers to prioritize such an
>>         enhancement.
>>
>>         Thanks,
>>         Andi
>>
>>         Nils Pedersen wrote:
>>
>>             I'm experiencing  a problem  with  reusing the same BPEL
>>              SU  in  multiple SA's and deploying them to the same ESB
>>             instance.
>>             The deployment fails with an error stating that the
>>             endpoint already exist (referring to the endpoint name on
>>             the properties of the "Provide" of the BPEL SU inside the
>>             CASA editor).
>>             This is the case even if the BPEL is based on an abstract
>>             WSDL definition and the only endpoints (BC's) connected to
>>             the BPEL SE is defined through the CASA's.
>>             And yes each of the CASA assemblies has different endpoint
>>             addresses.
>>             I've tried the same scenarios but using JEE SU's instead,
>>             and that works like a charm.
>>
>>             I have a suspicion that this issue is related to how the
>>             BPEL SE handles the BPEL definitions and that this is
>>             related to how it "handles" multiple versions of the same
>>             BPEL definition.Even if they're deployed packaged inside
>>             different CASA projects.
>>             Can anybody verify what I'm experiencing is correct and
>>             perhaps even shed some light if this is acting as supposed
>>             to or if I'm experiencing a "bug".
>>
>>             YS
>>
>>             Nils
>>             PS! IMHO if this is working as expected it highly limits
>>             the way you may reuse BPEL definitions in different
>>             CASA's. And it seems that it sort of breaks up the
>>             expected behavior of SU's packaged in SA's.
>>
>>
>>
>>        
>> ---------------------------------------------------------------------
>>         To unsubscribe, e-mail:
>>         [hidden email]
>>         <mailto:[hidden email]>
>>         For additional commands, e-mail:
>>         [hidden email]
>>         <mailto:[hidden email]>
>>
>>
>>     --     Sun Microsystems <http://www.java.com>  * Nils Pedersen *
>>     SOA Deployment Architect
>>
>>     *Sun Microsystems, Inc.*
>>     Sognsveien 75
>>     Oslo NO-0805 NO
>>     Phone x43738/+47-23-369 738
>>     Mobile +4790645848
>>     Email [hidden email]
>>     NOTICE: This email message is for the sole use of the intended
>>     recipient(s) and may contain confidential and privileged
>>     information. Any unauthorized review, use, disclosure or
>>     distribution is prohibited. If you are not the intended recipient,
>>     please contact the sender by reply email and destroy all copies of
>>     the original message.
>>
>>
>>    
>> ---------------------------------------------------------------------
>>     To unsubscribe, e-mail: [hidden email]
>>     <mailto:[hidden email]>
>>     For additional commands, e-mail: [hidden email]
>>     <mailto:[hidden email]>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Tientien Li
In reply to this post by Nils Pedersen
Nils,

As many others have pointed out to you that what you are trying to do is
not supported by the JBI spec. There are a few more points that I will
like to make on this issue:

1. Your issue is with SA not CASA. SA is the deployment artifact for JBI
applications. CASA is an editor for SA.  The bpel SU in this case is
generated by the bpel project not CASA. In fact, you can create both
bpel and ejb examples using CompApp project directly without open them
in CASA.

2. The ejb example you shown did not work at all. I just tried it out.
If you look at your server log closely, we will find the following two
warning messages when the second SA is deployed:

....
Two web services are being deployed with the same endpoint URL
echoWSService/echoWS; The service that gets loaded last will always be
the one that is active for this URL
...
Ignoring duplicate registration of endpoint
http://ws.echo/,echoWSService,javaee_echoWSPort from component
sun-javaee-engine
...

The first one is telling you that GF overwrite the soap endpoint of
first EJB web service and assigned it to the second EJB web service
loaded. The second one is saying that the OpenESB run-time ignored the
second NMR endpoint registration request because it has been registered
by the first JavaEE SU.

HTH,

--
Tientien Li

Nils Pedersen wrote:

> Well, what I do is rather straight forward:
> 1. Create a BPEL module
> 2. Create an abstract WSDL (no bindings or services defined)
> 3. Create a BP and use the WSDL from 2. as the BP service def.
>    The content of the process does not matter here, but you might want
> to just add an assign of some sort between receive and reply of th BP
> just for ensuring it actually works.
> 4. Create a CASA and add the BPEL module to the CASA.
> 5. Drag any BC (for this exercise just use the SOAP BC) and bind it to
> the provider icon of the BPEL module in the CASA editor. Remember to
> change the endpoint address of the BC to something  unique.
> 6. Deploy the CASA. You might want to create a test case and verify
> that the CASA has been successfully deployed and is running correctly.
> 7. Repeat steps 4 to 6 (reusing the BPEL module you created in 1.),
> but remember to change the endpoint address of the SOAP BC.
> This will fail during deployment of the second CASA, unless you
> undeploy the first. The failure is due to the "internal" provider
> endpoint name (which you cannot change) on the BPEL module in the CASA
> editor.
> If you do the same exercise but use a EJB project (JEE SU) instead of
> a BPEL module it works as expected (both CASA's get successfully
> deployed and are working perfectly.
>
> Now to the use case of this scenario:
> Given the fact that you often create want to reuse SU's (and in this
> case BPEL definitions) in different applications should not force you
> to do this as only external services. If so you will force it to do
> networking for each of this invocations and that will not scale in a
> larger deployment (actually it does not have to. If all SU's that you
> want to reuse has to be deployed as simple standalone CASA's you will
> simply end up with a much too fragmented service landscape to keep
> track of (and you will not have to do more then let's say 20 reusable
> components and you start to see the picture. Working with a project
> that would quickly end up with more than 100 SU's/SA's). Another point
> here is that by forcing reuse by single instance, it would not be
> possible to have uneven updates of the shared SU across the CA's using
> it.
>
> And why is it working with the JEE SE modules and not the BPEL. And
> according to the error message the reason is because of the Provider
> endpoint on the BPEL module in the CASA editor. I would have
> understood it if it was the BC endpoint address of the CASA (which is
> what is being exposed to the surroundings). And even if that was a
> limitation, why can't we allow for the provider endpoint name to be
> changed in the CASA editor?
>
> This all boils down to how the platform allows for different
> strategies and solution designs for reuse of your components.
>
> YS
>
> Nils
> PS! I would be happy to RAR some sample project so you could see the
> two exercises.
>
>
> Andreas Egloff wrote:
>> Do I understand your scenario correctly: you have a copy of the same
>> SU (i.e. with the same endpoints defined in them) in more than one
>> composite application (SA)?
>>
>> Today we do not support an application private namespace. That is,
>> service/endpoint names in your application are shared and visible to
>> every application on the ESB. This also means these public names need
>> to be unique.
>>
>> What is expected today is that you can share this SU by referencing
>> one instance in multiple applications (SAs) rather than dupplicating
>> it in each application. If you do want to duplicate it (copy it into)
>> each application, it expects unique names for the services.
>>
>> If would be great if you could share the exact motivations/use cases
>> of why this may not be suitable for your needs. We have been
>> discussing the application private / ESB visibility / External
>> visibility namespaces for a while, but we have not had the concrete
>> business drivers to prioritize such an enhancement.
>>
>> Thanks,
>> Andi
>>
>> Nils Pedersen wrote:
>>> I'm experiencing  a problem  with  reusing the same BPEL  SU  in  
>>> multiple SA's and deploying them to the same ESB instance.
>>> The deployment fails with an error stating that the endpoint already
>>> exist (referring to the endpoint name on the properties of the
>>> "Provide" of the BPEL SU inside the CASA editor).
>>> This is the case even if the BPEL is based on an abstract WSDL
>>> definition and the only endpoints (BC's) connected to the BPEL SE is
>>> defined through the CASA's.
>>> And yes each of the CASA assemblies has different endpoint addresses.
>>> I've tried the same scenarios but using JEE SU's instead, and that
>>> works like a charm.
>>>
>>> I have a suspicion that this issue is related to how the BPEL SE
>>> handles the BPEL definitions and that this is related to how it
>>> "handles" multiple versions of the same BPEL definition.Even if
>>> they're deployed packaged inside different CASA projects.
>>> Can anybody verify what I'm experiencing is correct and perhaps even
>>> shed some light if this is acting as supposed to or if I'm
>>> experiencing a "bug".
>>>
>>> YS
>>>
>>> Nils
>>> PS! IMHO if this is working as expected it highly limits the way you
>>> may reuse BPEL definitions in different CASA's. And it seems that it
>>> sort of breaks up the expected behavior of SU's packaged in SA's.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>


--
Tientien Li


Netbeans SOA Tools, http://enterprise.netbeans.org
Open ESB Community, http://open-esb.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Nils Pedersen
Thanks,  Tien!

I didn't look at the log, but now that you've pointed it out I found it.
We've already taken the steps to move solutions in using external services.
Then at least to make this consistent, shouldn't the deployment of the
EJB sample fail in the same manner that the deployment of the BPEL
sample fails?
Another Q:
If what you say is correct (JBI standard prevents this) then what you
are saying is that it is the JBI specification that stands in the way of
the BPEL SE supporting multiple versions of the same BPEL process
definition. Since you would not be allowed to deploy the same BPEL
process project twicw to the same ESB instance. Am I correct?

Nils



Tientien Li wrote:

> Nils,
>
> As many others have pointed out to you that what you are trying to do
> is not supported by the JBI spec. There are a few more points that I
> will like to make on this issue:
>
> 1. Your issue is with SA not CASA. SA is the deployment artifact for
> JBI applications. CASA is an editor for SA.  The bpel SU in this case
> is generated by the bpel project not CASA. In fact, you can create
> both bpel and ejb examples using CompApp project directly without open
> them in CASA.
>
> 2. The ejb example you shown did not work at all. I just tried it out.
> If you look at your server log closely, we will find the following two
> warning messages when the second SA is deployed:
>
> ....
> Two web services are being deployed with the same endpoint URL
> echoWSService/echoWS; The service that gets loaded last will always be
> the one that is active for this URL
> ...
> Ignoring duplicate registration of endpoint
> http://ws.echo/,echoWSService,javaee_echoWSPort from component
> sun-javaee-engine
> ...
>
> The first one is telling you that GF overwrite the soap endpoint of
> first EJB web service and assigned it to the second EJB web service
> loaded. The second one is saying that the OpenESB run-time ignored the
> second NMR endpoint registration request because it has been
> registered by the first JavaEE SU.
>
> HTH,
>
> --
> Tientien Li
>
> Nils Pedersen wrote:
>> Well, what I do is rather straight forward:
>> 1. Create a BPEL module
>> 2. Create an abstract WSDL (no bindings or services defined)
>> 3. Create a BP and use the WSDL from 2. as the BP service def.
>>    The content of the process does not matter here, but you might
>> want to just add an assign of some sort between receive and reply of
>> th BP just for ensuring it actually works.
>> 4. Create a CASA and add the BPEL module to the CASA.
>> 5. Drag any BC (for this exercise just use the SOAP BC) and bind it
>> to the provider icon of the BPEL module in the CASA editor. Remember
>> to change the endpoint address of the BC to something  unique.
>> 6. Deploy the CASA. You might want to create a test case and verify
>> that the CASA has been successfully deployed and is running correctly.
>> 7. Repeat steps 4 to 6 (reusing the BPEL module you created in 1.),
>> but remember to change the endpoint address of the SOAP BC.
>> This will fail during deployment of the second CASA, unless you
>> undeploy the first. The failure is due to the "internal" provider
>> endpoint name (which you cannot change) on the BPEL module in the
>> CASA editor.
>> If you do the same exercise but use a EJB project (JEE SU) instead of
>> a BPEL module it works as expected (both CASA's get successfully
>> deployed and are working perfectly.
>>
>> Now to the use case of this scenario:
>> Given the fact that you often create want to reuse SU's (and in this
>> case BPEL definitions) in different applications should not force you
>> to do this as only external services. If so you will force it to do
>> networking for each of this invocations and that will not scale in a
>> larger deployment (actually it does not have to. If all SU's that you
>> want to reuse has to be deployed as simple standalone CASA's you will
>> simply end up with a much too fragmented service landscape to keep
>> track of (and you will not have to do more then let's say 20 reusable
>> components and you start to see the picture. Working with a project
>> that would quickly end up with more than 100 SU's/SA's). Another
>> point here is that by forcing reuse by single instance, it would not
>> be possible to have uneven updates of the shared SU across the CA's
>> using it.
>>
>> And why is it working with the JEE SE modules and not the BPEL. And
>> according to the error message the reason is because of the Provider
>> endpoint on the BPEL module in the CASA editor. I would have
>> understood it if it was the BC endpoint address of the CASA (which is
>> what is being exposed to the surroundings). And even if that was a
>> limitation, why can't we allow for the provider endpoint name to be
>> changed in the CASA editor?
>>
>> This all boils down to how the platform allows for different
>> strategies and solution designs for reuse of your components.
>>
>> YS
>>
>> Nils
>> PS! I would be happy to RAR some sample project so you could see the
>> two exercises.
>>
>>
>> Andreas Egloff wrote:
>>> Do I understand your scenario correctly: you have a copy of the same
>>> SU (i.e. with the same endpoints defined in them) in more than one
>>> composite application (SA)?
>>>
>>> Today we do not support an application private namespace. That is,
>>> service/endpoint names in your application are shared and visible to
>>> every application on the ESB. This also means these public names
>>> need to be unique.
>>>
>>> What is expected today is that you can share this SU by referencing
>>> one instance in multiple applications (SAs) rather than dupplicating
>>> it in each application. If you do want to duplicate it (copy it
>>> into) each application, it expects unique names for the services.
>>>
>>> If would be great if you could share the exact motivations/use cases
>>> of why this may not be suitable for your needs. We have been
>>> discussing the application private / ESB visibility / External
>>> visibility namespaces for a while, but we have not had the concrete
>>> business drivers to prioritize such an enhancement.
>>>
>>> Thanks,
>>> Andi
>>>
>>> Nils Pedersen wrote:
>>>> I'm experiencing  a problem  with  reusing the same BPEL  SU  in  
>>>> multiple SA's and deploying them to the same ESB instance.
>>>> The deployment fails with an error stating that the endpoint
>>>> already exist (referring to the endpoint name on the properties of
>>>> the "Provide" of the BPEL SU inside the CASA editor).
>>>> This is the case even if the BPEL is based on an abstract WSDL
>>>> definition and the only endpoints (BC's) connected to the BPEL SE
>>>> is defined through the CASA's.
>>>> And yes each of the CASA assemblies has different endpoint addresses.
>>>> I've tried the same scenarios but using JEE SU's instead, and that
>>>> works like a charm.
>>>>
>>>> I have a suspicion that this issue is related to how the BPEL SE
>>>> handles the BPEL definitions and that this is related to how it
>>>> "handles" multiple versions of the same BPEL definition.Even if
>>>> they're deployed packaged inside different CASA projects.
>>>> Can anybody verify what I'm experiencing is correct and perhaps
>>>> even shed some light if this is acting as supposed to or if I'm
>>>> experiencing a "bug".
>>>>
>>>> YS
>>>>
>>>> Nils
>>>> PS! IMHO if this is working as expected it highly limits the way
>>>> you may reuse BPEL definitions in different CASA's. And it seems
>>>> that it sort of breaks up the expected behavior of SU's packaged in
>>>> SA's.
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
>

--
Sun Microsystems <http://www.java.com> * Nils Pedersen *
SOA Deployment Architect

*Sun Microsystems, Inc.*
Sognsveien 75
Oslo NO-0805 NO
Phone x43738/+47-23-369 738
Mobile +4790645848
Email [hidden email]
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to package same BPEL SU in two different CASA and deploy to same ESB instance

Tientien Li
Nils,

On your questions...

1. Yes, there is a difference between how BPEL SE and JavaEE SE handle
this fault. The JBI spec, I think, allows different ways to handle this
fault.

2. JBI spec allows the loading of multiple component instances, but the
problem you have here is that some resources can not be shared. In this
case, the common resources needed is the NMR endpoints. Likewise, in the
EJB example, it is the soap endpoints. This is similar to sharing file
locks in JVM. One can have multiple instances of a Java class. But if
they all use the same file for I/O, then only one can lock and use the file.

HTH,

--
Tientien Li

Nils Pedersen wrote:

> Thanks,  Tien!
>
> I didn't look at the log, but now that you've pointed it out I found it.
> We've already taken the steps to move solutions in using external
> services.
> Then at least to make this consistent, shouldn't the deployment of the
> EJB sample fail in the same manner that the deployment of the BPEL
> sample fails?
> Another Q:
> If what you say is correct (JBI standard prevents this) then what you
> are saying is that it is the JBI specification that stands in the way
> of the BPEL SE supporting multiple versions of the same BPEL process
> definition. Since you would not be allowed to deploy the same BPEL
> process project twicw to the same ESB instance. Am I correct?
>
> Nils
>
>
>
> Tientien Li wrote:
>> Nils,
>>
>> As many others have pointed out to you that what you are trying to do
>> is not supported by the JBI spec. There are a few more points that I
>> will like to make on this issue:
>>
>> 1. Your issue is with SA not CASA. SA is the deployment artifact for
>> JBI applications. CASA is an editor for SA.  The bpel SU in this case
>> is generated by the bpel project not CASA. In fact, you can create
>> both bpel and ejb examples using CompApp project directly without
>> open them in CASA.
>>
>> 2. The ejb example you shown did not work at all. I just tried it
>> out. If you look at your server log closely, we will find the
>> following two warning messages when the second SA is deployed:
>>
>> ....
>> Two web services are being deployed with the same endpoint URL
>> echoWSService/echoWS; The service that gets loaded last will always
>> be the one that is active for this URL
>> ...
>> Ignoring duplicate registration of endpoint
>> http://ws.echo/,echoWSService,javaee_echoWSPort from component
>> sun-javaee-engine
>> ...
>>
>> The first one is telling you that GF overwrite the soap endpoint of
>> first EJB web service and assigned it to the second EJB web service
>> loaded. The second one is saying that the OpenESB run-time ignored
>> the second NMR endpoint registration request because it has been
>> registered by the first JavaEE SU.
>>
>> HTH,
>>
>> --
>> Tientien Li
>>
>> Nils Pedersen wrote:
>>> Well, what I do is rather straight forward:
>>> 1. Create a BPEL module
>>> 2. Create an abstract WSDL (no bindings or services defined)
>>> 3. Create a BP and use the WSDL from 2. as the BP service def.
>>>    The content of the process does not matter here, but you might
>>> want to just add an assign of some sort between receive and reply of
>>> th BP just for ensuring it actually works.
>>> 4. Create a CASA and add the BPEL module to the CASA.
>>> 5. Drag any BC (for this exercise just use the SOAP BC) and bind it
>>> to the provider icon of the BPEL module in the CASA editor. Remember
>>> to change the endpoint address of the BC to something  unique.
>>> 6. Deploy the CASA. You might want to create a test case and verify
>>> that the CASA has been successfully deployed and is running correctly.
>>> 7. Repeat steps 4 to 6 (reusing the BPEL module you created in 1.),
>>> but remember to change the endpoint address of the SOAP BC.
>>> This will fail during deployment of the second CASA, unless you
>>> undeploy the first. The failure is due to the "internal" provider
>>> endpoint name (which you cannot change) on the BPEL module in the
>>> CASA editor.
>>> If you do the same exercise but use a EJB project (JEE SU) instead
>>> of a BPEL module it works as expected (both CASA's get successfully
>>> deployed and are working perfectly.
>>>
>>> Now to the use case of this scenario:
>>> Given the fact that you often create want to reuse SU's (and in this
>>> case BPEL definitions) in different applications should not force
>>> you to do this as only external services. If so you will force it to
>>> do networking for each of this invocations and that will not scale
>>> in a larger deployment (actually it does not have to. If all SU's
>>> that you want to reuse has to be deployed as simple standalone
>>> CASA's you will simply end up with a much too fragmented service
>>> landscape to keep track of (and you will not have to do more then
>>> let's say 20 reusable components and you start to see the picture.
>>> Working with a project that would quickly end up with more than 100
>>> SU's/SA's). Another point here is that by forcing reuse by single
>>> instance, it would not be possible to have uneven updates of the
>>> shared SU across the CA's using it.
>>>
>>> And why is it working with the JEE SE modules and not the BPEL. And
>>> according to the error message the reason is because of the Provider
>>> endpoint on the BPEL module in the CASA editor. I would have
>>> understood it if it was the BC endpoint address of the CASA (which
>>> is what is being exposed to the surroundings). And even if that was
>>> a limitation, why can't we allow for the provider endpoint name to
>>> be changed in the CASA editor?
>>>
>>> This all boils down to how the platform allows for different
>>> strategies and solution designs for reuse of your components.
>>>
>>> YS
>>>
>>> Nils
>>> PS! I would be happy to RAR some sample project so you could see the
>>> two exercises.
>>>
>>>
>>> Andreas Egloff wrote:
>>>> Do I understand your scenario correctly: you have a copy of the
>>>> same SU (i.e. with the same endpoints defined in them) in more than
>>>> one composite application (SA)?
>>>>
>>>> Today we do not support an application private namespace. That is,
>>>> service/endpoint names in your application are shared and visible
>>>> to every application on the ESB. This also means these public names
>>>> need to be unique.
>>>>
>>>> What is expected today is that you can share this SU by referencing
>>>> one instance in multiple applications (SAs) rather than
>>>> dupplicating it in each application. If you do want to duplicate it
>>>> (copy it into) each application, it expects unique names for the
>>>> services.
>>>>
>>>> If would be great if you could share the exact motivations/use
>>>> cases of why this may not be suitable for your needs. We have been
>>>> discussing the application private / ESB visibility / External
>>>> visibility namespaces for a while, but we have not had the concrete
>>>> business drivers to prioritize such an enhancement.
>>>>
>>>> Thanks,
>>>> Andi
>>>>
>>>> Nils Pedersen wrote:
>>>>> I'm experiencing  a problem  with  reusing the same BPEL  SU  in  
>>>>> multiple SA's and deploying them to the same ESB instance.
>>>>> The deployment fails with an error stating that the endpoint
>>>>> already exist (referring to the endpoint name on the properties of
>>>>> the "Provide" of the BPEL SU inside the CASA editor).
>>>>> This is the case even if the BPEL is based on an abstract WSDL
>>>>> definition and the only endpoints (BC's) connected to the BPEL SE
>>>>> is defined through the CASA's.
>>>>> And yes each of the CASA assemblies has different endpoint addresses.
>>>>> I've tried the same scenarios but using JEE SU's instead, and that
>>>>> works like a charm.
>>>>>
>>>>> I have a suspicion that this issue is related to how the BPEL SE
>>>>> handles the BPEL definitions and that this is related to how it
>>>>> "handles" multiple versions of the same BPEL definition.Even if
>>>>> they're deployed packaged inside different CASA projects.
>>>>> Can anybody verify what I'm experiencing is correct and perhaps
>>>>> even shed some light if this is acting as supposed to or if I'm
>>>>> experiencing a "bug".
>>>>>
>>>>> YS
>>>>>
>>>>> Nils
>>>>> PS! IMHO if this is working as expected it highly limits the way
>>>>> you may reuse BPEL definitions in different CASA's. And it seems
>>>>> that it sort of breaks up the expected behavior of SU's packaged
>>>>> in SA's.
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>
>>
>


--
Tientien Li


Netbeans SOA Tools, http://enterprise.netbeans.org
Open ESB Community, http://open-esb.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]