Thank you for this suggestion. It seems to be a every efficient and practical sollution. Now I have to check back with the others in my project and see how much work it would create to integrate an ESB in our system. For now ODE communicates directly with service endpoints, there is no ESB or MoM in between. I wonder why my people did not design the system with an ESB in the first place... academics! :D
Greetings, 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
