Hello, Thanks for pointing out where to start looking and extending ODE. That's roughly what I'm looking for. I will let you know if I succeed. Any additional hints and ideas would still be appreciated!
Best regards, Thuy > -----Original Message----- > From: Tammo van Lessen [mailto:[email protected]] > Sent: Tuesday, December 15, 2009 10:40 PM > To: [email protected] > Subject: Re: Changing Endpoints of a Process Instance at RUNTIME > > Hi, > > As an academic I'd also go with slightly extending ODE. The Instance > Management API is definitely a good starting point for that, I'd start > with adding a new method to > org.apache.ode.bpel.pmapi.InstanceManagement > and implement it in > org.apache.ode.bpel.engine.ProcessAndInstanceManagementImpl. The code > for modifying the EPR of a partner link can be derived from ASSIGN > and/or AssignHelper. > > HTH, > Tammo > > On 15.12.2009 21:46, Song Thuy Nguyen wrote: > > Setting up a proxy is seen as one of the less desireable solution, > because it would create a single point of failure. Incase the proxy > component fails, the whole BPEL engine will stop working. Our system > (as it is designed) as mentioned uses normal BPEL files without any > dynamic binding capability, so it would also work if the proces > instance rebinding component (which I'm trying to implement) fails. The > system then would run like a normal BPEL engine without fault > compensation ability. > > I will look into the WS-Policy, maybe this will work for me, thank > you! > > > > If anyone has another idea, especially how to extend ODE itself like > in my first post, please let me know. > > > > Best regards, > > > > Thuy > > > > > >> -----Original Message----- > >> From: Ford, Mark - 0661 - MITLL [mailto:[email protected]] > >> Sent: Tuesday, December 15, 2009 8:18 PM > >> To: [email protected] > >> Subject: Re: Changing Endpoints of a Process Instance at RUNTIME > >> > >> Have you considered setting up a proxy service that would handle > >> retries or address rewriting? This would keep your BPEL simple since > >> all of the changes are external to the BPEL and in fact external to > >> ODE. Another option would be to modify the invoke layer for ODE to > >> provide this behavior keyed off of WS-Policy. For a sample > >> implementation of this policy, check out the docs here: > >> http://tinyurl.com/ya4tmsk > >> > >> > >> > >> On Dec 15, 2009, at 10:51 AM, Song Thuy Nguyen wrote: > >> > >>> Hi Marco, > >>> Thanks for the fast answer and your suggestion, but the 2 links you > >>> gave me > >>> are not suitable for this problem. I read all the user manual of > >>> apache ode > >>> on the website before but didn't find any solution. The first link > >>> describes > >>> HOW endpoints can be represented, and the second one, as far as I > >>> understand > >>> describe is a way to manipulate endpoints on a process-wide level, > >>> and there > >>> is also a second problem with this solution (copied from > >>> http://ode.apache.org/endpoint-configuration.html): > >>> > >>> " Dynamic refresh > >>> > >>> Properties are dynamically loaded and refreshed at run time. > >>> The timing is the following: > >>> On every request, if the file has not been polled during the last > 30 > >>> seconds > >>> then check the file for updates. If any, reload it. > >>> > >>> Consequently, if you have updated properties, you have to wait ~30 > >>> seconds > >>> and then trigger a request." > >>> > >>> so you have to wait up to 30s to see the changes taking effect. > >> That's > >>> "ages" considering you are stopping a running instance to replace > an > >>> endpoint and continue. > >>> > >>> Looks like the 3rd suggestion is the only way to go. I'll let you > >>> know if I > >>> find an applicable concrete solution. > >>> > >>> Is there someone else with another solution for me? :) > >>> > >>> Regards, > >>> > >>> Thuy > >>> > >>> > >>> > >>> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Marco Indaco [mailto:[email protected]] > >>> Gesendet: Dienstag, 15. Dezember 2009 14:52 > >>> An: [email protected] > >>> Betreff: Re: Changing Endpoints of a Process Instance at RUNTIME > >>> > >>> Hi song, > >>> i'am working on your own objective, in my research project. > >>> There are many solution that you can investigate. > >>> > >>> 1) http://ode.apache.org/endpoint-references.html see that link > >>> > >>> 2)Create, if monitor observes, for example, that a service is down, > a > >>> file .endpoint located in conf directory in Apache Ode. see that > link > >>> http://ode.apache.org/endpoint-configuration.html > >>> > >>> 3) A more intrusive operation for modify source code to added these > >>> functionalites > >>> > >>> If you are any idea please contact me...working together is > powerful. > >>> > >>> Hi, for any question ask me!!! > >>> > >>> 2009/12/15 Song Thuy Nguyen <[email protected]>: > >>>> Hi everyone, > >>>> > >>>> > >>>> > >>>> I'm quite new to Apache ODE and mailing lists, hoping for your > help. > >>>> > >>>> 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 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? Any help would > be > >>>> appreciated. > >>>> > >>>> > >>>> > >>>> Thank you in advance > >>>> > >>>> > >>>> > >>>> Thuy > >>>> > >>>> > >>> > >>> __________ Information from ESET NOD32 Antivirus, version of virus > >>> signature > >>> database 4689 (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 > >>> > >>> > >>> > >>> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank- > >>> Version 4634 > >>> (20091124) __________ > >>> > >>> E-Mail wurde geprüft mit ESET NOD32 Antivirus. > >>> > >>> http://www.eset.com > >>> > >>> > >> > >> > >> > >> > >> -- > >> Mark Ford > >> MIT Lincoln Laboratory > >> 244 Wood Street > >> Lexington MA 02420 > >> (781) 981-1843 > > > > > > > -- > Tammo van Lessen - http://www.taval.de
