The old "using the mep" for sync/async responses chestnut again... Sorry Kev ;) Here was what was said on IM that time... anonymous wrote : (12:18:47) Tom Fennelly: another quick one... the mep issue | (12:18:55) Tom Fennelly: what was the issue with the? | (12:19:26) Tom Fennelly: you don't wanna use it to decide whether or not a respnse is sent back? | (12:19:33) Kevin Conner: The mep of the service has no bearing on the http gateway, it is an impleme | ntation config | (12:19:36) Kevin Conner: You can't | (12:19:57) Kevin Conner: A response can be sent back from a OneWay mep if it chains the request | (12:20:13) Kevin Conner: Service A (OneWay) -> Service B (RequestResponse) | (12:20:37) Kevin Conner: It is an implementation detail and not part of the service contract I'm not trying to contradict Kev, but given our current model where the gateways are configured on the services, I don't understand why the service mep is not an indicator of whether or not the invoked http-gateway should return the service response as its response (mep=RequestResponse), or should simply return an empty response as its response (mep=OneWay). It seems to me like having an additional sync/async config on the gateway would be very confusing for users. I think this is what's being proposed, right? So, assuming we add a "sync" flag on the http-gateway, how should the gateway respond when... 1. gateway sync=true, service mep=OneWay? 2. gateway sync=true, service mep=RequestResponse? 3. gateway sync=false, service mep=OneWay? 4. gateway sync=false, service mep=RequestResponse? If the http-gateway used the mep, what use case breaks, and how does it break i.e. what actually goes wrong e.g. with the chained services example outlined in the IM? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250252#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...