overwrite the endpoint address (soap address) for the external web services.

[jeff.yuchang]

This requirement is from the following scenario.

1) In the development phase, BPEL developers used the external web services that in the test Environment for their developing and testing.

2) After BPEL developers successfully developed and tested the Bpel process, they will hand over those bpel process artifacts to those admin users for the production deployment.

3) Because in the production environment, those external web services in production has a different  endpoint address in the wsdl. Those admin users are expecting to update those endpoint address when they got the bpel process artifacts from BPEL developers. And I believe they don't like to change those wsdl's soap address one by one, they would rather to update these information in one configuration file, for example.

As far as I know, we don't have a mechanism to substitude the endpoint address for the external web services. (Are we able to achieve this by using UDDI, Kurt?)

Also, if we indeed don't have this substituion, what would be the preferred way of doing so?

thoughts?

Regards

Jeff

[kurtstam]

Hi Jeff,

I would love fixing this problem. For a plain webservices we have a way of making this work, let me explain that a little and then we can swing back to BPEL WSDLs.

For WebServices, you can use UDDIAnnotations, to markup your webservice. Upon deployment, the webservices will register into the UDDI. You'd have a UDDI server for each environment (dev, stage, prod). So the correct endpoint information will be registered into UDDI. Now a caller, looks up the WebService and obtains the BindingTemplates (1 or more if there is more then one server in that environment), in the bindingTemplate it can look up the where to obtain the WSDL, and you're off to the races.

For BPEL, we have also register the BPEL endpoints upon deployment, the one issue we have though is that our deployment process looks up dependent endpoints upon deployment, so they depend services need to be there at deployment time, and we can't control the deployment order in RiftSaw. So this is why UDDI Lookup in turned off by default in RiftSaw; for simple BPEL cases it should work, for more complex dependencies it has issues. If we don't want to add somekind of deployment order mechanism, we can think of a way to overwrite the endpoint information at runtime.

--Kurt

[jeffdelong]

Another option is to add additional service bindings in the original partner wsdl, and modify the bpel-deploy.xml file upon deployment.

[jeff.yuchang]

Thanks Kurt.

Yeah, seems to me that it is better that we have this on the runtime side.

Regards

Jeff

[jeff.yuchang]

This is a good workaround ;-), although I am  not sure if corporates allow developers putting the production's soap address in the  dev/test environment.

-Jeff Yu

[kurtstam]

Thanks guys, I'm going to create an example setup. Once I have it I will publish and ask for your feedback. Stay tuned. --Kurt

[clsimone]

Hello everyone,

Is there any example available on how to change the endpoint for the external web services?

Thank you,

Laura

[jeff.yuchang]

Hi Laura,

No, we don't have examples on this yet. I think you can take Jeff Delong's suggestion at this moment, adding another service binding, and then change it upon deployment.

Regards

Jeff

[kurtstam]

Hi Laura,

I'm working on it and it requires some small code changes in RIftSaw to make it all work smoothly. I'll be checking those in later this week. So hopefully by next week I will have an example.

Cheers,

--Kurt

[clsimone]

Thank you for your responses. Before proceeding with this approach I would have a question: if I add another service binding and update the bpel-deploy.xml I have to deploy again the process. So it is not possible to do this change at runtime (not to undeploy and deploy again the process)?

Regards,

Laura