JBossDeveloper

I think messageSource == wsa:From, but I don't think the message necessarily
needs to know where it is going, the esb routes it based on the header informstion
and the esb configuration.

Hit submit too early!

So if there's a wsa:ReplyTo present on the message, that should be used to route the transformed message: which could be to another transformation service if we need a pipeline. If there's no wsa:ReplyTo then we either a) use the default rules within WS-A (depends on other aspects of WS-A elements) or the transformation service may use some application intelligence (e.g., based on what's in the message or, I suppose, the input parameters) to route the transformed message.

Once the WS-A implementation is in place, we'll be able to illustrate. But I'd definitely recommend checking out the WS-A specification and something that uses it (e.g., WS-TX): take a look at the on-the-wire message, because that's what I'm discussing. How that message is formed (as it flows from the client code, down through the dispatchers to the various plugins) is obviously important too, and I wonder if that's where some of the confusion is arising.

Yeah, tell me about it! I could use a 10 day week at the moment!!

Was offline yesterday presenting a talk at Manchester University. Anyway, in the architecture document, the dispatchers aren't the service: they're (typically) the things that augment the message as it flows from the client to the network/messaging infrastructure (e.g., add the transaction or security context), and strip off information from the message as it flows from the messaging infrastructure up to the service.

Now of course en-route to the messaging infrastructure, a message may undergo a transformation, but I see that as a service invocation too. Here's an example (in text): if I get a chance I'll produce a diagram later. Note, this is not the only way in which transformations would work in the ESB, but it is simple enough to illustrate the difference between services and dispatchers in this example.

Suppose a client C wants to talk to a service S and the client doesn't natively support the message format that S does (C supports formatA and S supports formatS). When S was looked up (via the registry), information about the message format would have been included in the contract definition. Also included in this definition (or via a separate lookup to the registry) would be an EPR for a transformation service (T) that can take message vocabulary formatA and transform it to formatB.

Now one way the client could then talk to S would be for it to explicitly call T, giving it the message in formatA and getting back a message in formatB, which is then sends to S.

The other way would be for C to make its call directly on S, but the dispatcher hierarchy that has been set up for C for this to happen now includes a transformation dispatcher (maybe as the very last thing that gets called prior to the messaging infrastructure, if we want to transform the context information, such as transactions or security, as well as the payload) which knows about T. This dispatcher makes an invocation on T (acting as a client, so it will have an T-specific dispatcher hierarchy and potentially use a completely different messaging infrastructure to make the call - colocation optimisations come much later) and when it gets back the transformed message, it then completes the client's invocation on S by calling down to the messaging infrastructure.