Hello Milinda, We decided to put an ESB, probably WSO2 ESB, between ODE and the services to implement the failsave functionality. Thanks again for the suggestion. I will tell you about the progress.
Regards, Thuy > -----Original Message----- > From: Milinda Pathirage [mailto:[email protected]] > Sent: Wednesday, December 16, 2009 4:52 AM > To: [email protected] > Subject: Re: Extend InstanceManagement API to provide endpoint > manipulation > > 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
