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
