Hello, I tried the second opportunity that i have signaled to you and with .endpoint file there are 30 second for refresh operation. However let me know.
Best Regards 2009/12/16 Song Thuy Nguyen <[email protected]>: > 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 > >
