Eoghan Glynn wrote:
Hi Dan ...
I think I did it because I wanted a way for messages to be correlated at
the transport level. For instance, lets take JMS with a correlation ID -
there should be someway to say from a transport - "you see this message?
this message is a response to your request!"
The problem with transport-level correlation is that we'd end up with
a hodge-podge of different and possibly incomplete correlation
mechanisms (I say incomplete because AFAIK there's no natural HTTP
mechanism for correlating decoupled reponses).
Instead IMO correlation should be consistently based on the WS-A
RealtesTo header ... even if an individual transport provides a
transport-specific correlation mechanism (such as the JMS correlation
ID).
Assuming of course that we can map the WS-A headers to all our
supported protocols/bindings (as is currently the case with SOAP &
XML).
I'd be OK with that. Does that mean we'd be enabling WS-A by default?
And synthesizing some ws-addressing headers? Or do we want to actually
integrate an EPR or some similar concept into the message itself?
I seem to recall this also had
something to do with the practicality of receiving faults on the client
as well, but to be honest I don't remember what exactly...
OK, if the motivation the change wasn't that memorable, it probably
wasn't curcial to your fault-handling scheme.
I hope not at least :-)
Complete oversight on my part... Things are crazy busy tomorrow, but if
you don't get to it tomorrow, I'll try to get this resolved over the
weekend.
I've got a fix in my working copy for this and another minor issue
exposed by the MAPTest ... I was really just checking that nothing
else was dependent on your change from inMessage.setExchange(exchange)
to exchange.setInMessage(inMessage) in the transport.
I'll commit these fixes when I'm back in the office (I'm off today).
Awesome. Thanks Eoghan!
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
