Re: [mule-user] Service Chaining with Dynamic ReplyTo

> I'm looking for an elegant way to handle a distributed operation and
> haven't found one yet.  Here's the scenario:
>  
> Two separate containers, call them Remote and HQ.  Remote exposes a
> WebService for local clients.  This WebService sends each
> request through a JMS topic to HQ and waits for the reply on
> a temporary topic (nevermind why topics are being used; the requests
> are being routed from remote JMS brokers over very-small-aperture
> satellite to a cluster of HQ brokers using SonicMQ's DRA).  HQ should
> handle each request by invoking a number of services
> serially/synchronously and sending the reply back via the message's
> embedded replyTo temporary topic.
>  
> The Remote WebService is implemented by a UMO that sends to a JMS
> endpoint through RequestContext.send().  It has an axis
> inboundEndpoint.  The JmsMessageDispatcher creates the temporary topic
> replyTo for us.  This works fine.
>  
> The HQ services are configured with the first service receiving on the
> JMS endpoint above.  Its outboundEndpoint is set to a VM endpoint to
> another service, which is connected to a third service.  This chain is
> a few services deep; your garden-variety Chain of Responsibility pattern.
>  
> My problem is that the first service at HQ sends its own results back
> rather than the results of its OutboundRouter (which represents the
> result of the services downstream).  I see this happening in MuleProxy:
>  
> ------onCall()------------
> UMOMessage result = invoker.execute();
> ...
> returnMessage = descriptor.getOutboundRouter().route(result,
>                                                        
>                          event.getSession(),
>                                                        
>                          event.isSynchronous());
> ...
> replyToHandler.processReplyTo(event, result, replyTo);
> --------------------------
>  
> In the case of a synchronous event, would it be possible to send
> returnMessage to the replyToHandler rather than result?
>  
> Such a feature would also allow the WebService on the Remote container
> to be a pass-through; configuring a synchronous outboundEndpoint would
> do the send operation and grab the result.  Perhaps I could implement
> a generic UMO that uses java.lang.reflect.Proxy to masquerade as
> whatever WebService interface is configured for it.  Essentially, it
> would allow an arbitrary chain of services (or a single service, for
> that matter) to look like a single WebService with no coding.
>  
> If that's not a desirable behavior, I'm looking for alternatives.
>  
> I've considered using a custom header to hold the reply endpoint, then
> configuring a special OutboundRouter on the last service to use it,
> but that would require some ugly hacks (getting the first service to
> not reply, configuring the last service to explicitly reply).  The
> latter could conceivably be done using the replyTo property of
> OutboundRouters, but that's not dynamic; I need to reply to the
> temporary topic embedded in the message.
>  
> Any help?
>  
> Thanks,
>   -- Todd