Ok, I misunderstood the intention of your message. Correlation can but need not be an issue on the BPEL side. If we go back to the call center and make it message-based, like let's say receiving postal letters in the good ol' days instead of handling phone calls. I'll put the technical equivalents in []. I as a customer [e.g. Axis2 client] send a letter [SOAP message] containing my customer no and an order request. The company [Apache ODE] receives the message [receive activity] and processes the order [long running BPEL process]. From the envelope of the letter [the issue at hand] it extracts my postal address [endpoint] and sends back the order confirmation [SOAP message; invoke] after some days. I receive the order confirmation and need to correlate it to my original order [2nd issue at hand].
As you can see, in this scenario, no correlation is needed on the BPEL side, as long as I do not want to interact with the company again. However, I as the Axis2 client need to deal with the correlation. Currently, I would have to send ODE-specific headers. Axis2 does not understand them natively. I started to write a module that can insert the ODE headers into the outgoing message, but due to my missing knowledge in the Axis architecture, I currently do not know how to deal with the incoming message and correlate it back to the original request. I don't know exactly which BPEL engine uses which headers for transmitting the endpoint reference for the callback. At least the Eclipse BPEL editor inserts comments into the BPEL source that WS-Addressing is used. This means for me that to the editor developers' understanding WS-Addressing has to be used. Because these are mainly IBM and Oracle devs, I would assume that the BPEL servers of these companies use WS-Addressing (but I cannot tell). You are right that it is different to correlate messages and sessions. However, I'd think that message correlation can also be used for correlating sessions. The question to be answered is, what is the reply (or the replies). But if we look at the partnerlink concept, what we need to do is to say that when the process is started, the client-partnerlink endpoint is initialized not by the WSDL or other things by the server but instead by information passed with the initiating message. Because WS-Addressing is the only standard available in this area, using it (perhaps not 100% as intended) has at least the advantage that client frameworks like Axis2 can be used to easily call ODE processes, which is currently not the case. Daniel Matthieu Riou schrieb: > On Mon, Jan 19, 2009 at 8:15 AM, Daniel Luebke < > [email protected]> wrote: > > >> Matthieu Riou schrieb: >> >>> [...] >>> So how do you typically pass a callback endpoint for a stateful service? >>> Also the use case you're describing would probably be better handled >>> >> using >> >>> correlation, don't you think? >>> >>> Cheers, >>> Matthieu >>> >>> >> I would assume a WS-Addressing replyTo header. The replyTo header >> transmits the endpoint reference that is stored in the partnerlink >> afterwards. Each invoke and reply by ODE is sent to this new endpoint. >> IMO correlation alone does not solve the problem. How does ODE know >> where the partner is to be called? Correlation does not deal with >> endpoint references. >> >> > > I was actually going back to your example of a phone number, which is > typically stateful information and not just endpoint address. So when you > invoke a stateful partner (which a process is) you'll usually need both: > something that says which address to call and something that says which > instance at that address you're trying to reach. > > The problem with replyTo in WS-Addressig is that it's explcitly tied to the > reply to a request. It's not meant to be kept around and not really fit for > long-living asynchronous interactions as we're discussing here. AFAIK > there's no standard headers for async endpoint passing. Even less when you > want to add stateful information to it. So that's why we had to come up with > our own headers. > > Cheers, > Matthieu > > > >> Daniel >> >> -- >> Dr.-Ing. Daniel Lübke >> Leibniz Universität Hannover >> Welfengarten 1 >> D-30167 Hannover >> Tel. +49 511 762 19672 >> Fax +49 511 762 19679 >> >> >> >> > > -- Dr.-Ing. Daniel Lübke Leibniz Universität Hannover Welfengarten 1 D-30167 Hannover Tel. +49 511 762 19672 Fax +49 511 762 19679
signature.asc
Description: OpenPGP digital signature
