Thanks Kev. I'm afraid I still have some questions for you :) Before getting more detail on your answers to the table of sync/async questions.... The HttpGateway always returns a response, no matter what, right? HTTP is a synchronous protocol, at least as implemented by the serlvet spec, which is what we're using. So as far as I see, it's not so much whether the gatway responds sync or not (because it always responds sycn). It's whether it puts a payload into the response, and where it gets that payload from if it does. So when I say sync/async, I just mean payload/no-payload on the servlet response from the http gateway. "Kevin.Conner(a)jboss.com" wrote : If I understand correctly you are expecting the service mep to declare the outcome of the invocation from the perspective of the client No, I'm not expecting this. As far as the client of the http gateway is concerned, it's a HTTP invocation so I'm expecting them to expect a sync response. "Kevin.Conner(a)jboss.com" wrote : If the mep is declared RequestResponse then the service is stating that it should, directly, respond to the caller. Right... and just for clarity... in this case, the caller to the Service is the HttpGateway and not the "Client" invoking the gateway. "Kevin.Conner(a)jboss.com" wrote : If the mep is declared as OneWay then the service is stating that it will not respond to the caller but this does not prevent another service, invoked as part of the pipeline (i.e. routing), from responding. And since the caller of the service is the gateway, how would we implement this? How do we decide whether or not the gateway makes a sync or async invocation (using ServiceInvoker) on the OnWay Service? "Kevin.Conner(a)jboss.com" wrote : 1. gateway sync=true, service mep=OneWay? | | Synchronous invocation, response may come from a second service (as highlighted in IM conversation). So the gateway makes a sync invocation on the OneWay Service? I can obviously see how this could work, but I personally think this is going to lead to a lot of confusion and is going to be quite brittle and hard to support. For example, wouldn't the person implementing serviceA (oneway service, being sync invoked by gateway) need to know that they can't use InVM from the gateway to serviceA, if serviceA and serviceB (the downstream service that's going to respond to the sync invoke from the gateway) are not in the same VM? "Kevin.Conner(a)jboss.com" wrote : 2. gateway sync=true, service mep=RequestResponse? | | Synchronous invocation, service pipeline should return response. | | 3. gateway sync=false, service mep=OneWay? | | Asynchronous invocation. Pipeline will not return a response, even in subsequent services, as the client has indicated that it does not want one. These are as I'd expect :) "Kevin.Conner(a)jboss.com" wrote : 4. gateway sync=false, service mep=RequestResponse? | | Asynchronous invocation. Pipeline will not return a response as the caller has indicated that it does not want one. But doesn't this then hardcode a decisoin for all clients calling through this gateway? As I see it, in this case the service being called by the gateway is able to produce a payload for the gateway response. Some HTTP clients (to the gateway) may want this payload in the HTTP response and other clients may not. Seems to me like the clients that are not interested need can just ignore the response payload, no? I don't get the logic of hardcoding this into the gateway. I suppose what we could do for this is support a "noResponsePayload" http query parameter on the gateway (or a HTTP header ala the "Accepts" header). That way, individual clients can indicate whether or not they want a payload in the response (whether they "accept" a response payload). Anyway... after all that... I'll just go and implement a "sync" flag on the gateway as you request :) I just wanted my thoughts on the record because I know Burr etc will be pointing the finger at me down the line :) Thanks again Kev!! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252565#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...