I also think that calling the service through a ESB will be a better alternative your approach. In this way you can use ESB to handle fail-over and failure handling is transparent to your BPEL. I think changing instance at runtime is not a good solution for this scenario. You can use Apache Synapse to handle fail-over. Please look endpoint section of article at[1].
Thanks Milinda [1] http://wso2.org/library/2559 On Wed, Dec 16, 2009 at 2:01 AM, Song Thuy Nguyen <[email protected]>wrote: > Hello Greg, > > > Wouldn't you also need to detect the > > failure and retry the failed activity? Would you also want all subsequent > > process instances to use the new endpoint, or would you expect each new > > instance to try the original ep and fail over as well? > > Once there is a failure calling a service endpoint, the process instance > execution will be paused, the new endpoint will be written over the old ones > and the processinstance will then be continued trying to call the last > action (new calling for the new endpoint). This solution is a kind of > "optimistic aproach" where service unavailability is mostly temporaly and > the next call to the same service is often successful again. There is also a > counter component who log the failing calls, once a service endpoints keeps > failing serveral times it will be marked as "permanently unavailable" and a > process-wide endpoint replacement will be executed, after this all > subsequent process instances will follow the updated BPEL with updated > endpoints (in the deployment descriptor). > > > If for some reason you cannot model the error handling in your BPEL > > process (which would be my first choice), it sounds like you would be > > better off capturing that logic elsewhere and using a fixed endpoint from > > BPEL. You could hide your 'real', potentially changing endpoints behind > > some other routing component (e.g. a camel route if you were running in > > servicemix). > > Using a routing component sounds interesting, although I don't want to > bloat the project with yet another component. But I will look into that > solution. Thank you! > > Best Regards, > > Thuy > > > > -----Original Message----- > > From: Greg Lucas [mailto:[email protected]] > > Sent: Tuesday, December 15, 2009 8:12 PM > > To: [email protected] > > Subject: Re: Extend InstanceManagement API to provide endpoint > > manipulation > > > > Thuy, > > > > I'm not aware of any existing support for this. I'm not sure I fully > > understand the requirements though. If the intent is to redirect a > > failed > > invocation to another endpoint then modifying the endpoint for an > > active > > process instance seems insufficient. Wouldn't you also need to detect > > the > > failure and retry the failed activity? Would you also want all > > subsequent > > process instances to use the new endpoint, or would you expect each new > > instance to try the original ep and fail over as well? > > > > If for some reason you cannot model the error handling in your BPEL > > process (which would be my first choice), it sounds like you would be > > better off capturing that logic elsewhere and using a fixed endpoint > > from > > BPEL. You could hide your 'real', potentially changing endpoints behind > > some other routing component (e.g. a camel route if you were running in > > servicemix). > > > > ~Greg > > > > > > > > On Tue, 15 Dec 2009 11:16:00 -0500, Song Thuy Nguyen > > <[email protected]> wrote: > > > > > Hi everyone, > > > > > > > > > I'm quite new to Apache ODE and mailing lists, hoping for your help. > > I > > > have > > > posted a similiar question in the user mailing list, but maybe here > > is a > > > better place to ask, as it has something to do with extending ODE. > > > > > > > > > As the title says I'm looking for a way to change service endpoints > > for > > > BPEL > > > process instances at runtime. That means that only one instance > > should be > > > affected by these changes, not the entire process and the deployment > > > descriptor. By convention of the project I'm working on, it is not > > > allowed > > > to write a BPEL-process that looks up service endpoints at a registry > > > service, put it in an variable and use it as the dynamic endpoint. > > The > > > reason is we want to provide a fault resistant BPEL process execution > > by > > > replacing failing or unavailabe service endpoints by working ones > > with > > > transparency to the process. So there should be no sign of the "fault > > > handling" in the BPEL file. Failing services will be detected by a > > > monitor > > > component, but this is not my part. > > > > > > > > > I have tried to look into the Management API doc for processes and > > > instances > > > to find a method that can provide a solution, but I had no luck. > > There > > > are > > > only methods to get and set endpoints on a process-wide level, on a > > > instance > > > level however, those methods are not available. > > > > > > > > > It seems to me that the only way to get such a functionality is to > > extend > > > the Instance Management API and write those methods myself. If this > > is > > > right, can someone please tell me where to start? I think there > > should be > > > Java objects representing each BPEL instance, and there are variables > > > storing the endpoints, so if I change them, I would get the > > > functionality I > > > need , right? > > > > > > > > > Or maybe there is already a built-in mechanism to do that but I > > missed > > > it? > > > > > > > > > Any help or comment would be appreciated. > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 4690 (20091215) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > > > > > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version > > 4634 (20091124) __________ > > > > E-Mail wurde geprüft mit ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > > > > > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version > > 4634 (20091124) __________ > > > > E-Mail wurde geprüft mit ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > -- Milinda Pathirage Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps WSO2 Inc.; http://wso2.com E-mail: [email protected], [email protected] Web: http://mpathirage.com Blog: http://blog.mpathirage.com
