[jboss-dev-forums] [JBoss ESB Development] - Re: Http Gateway - requirements please...

[Kevin.Conner@jboss.com]

"tfennelly" wrote : 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 is not an indicator, and never can be in the current implementation, because it only reflects an intent on that particular service *implementation*.  It has no bearing on whether the client expects to receive, or should receive, a response.

The mep is not a contract for the service which is how I believe you are interpreting it.  The only service type mechanism we have at present is the EBWS declarations, i.e. inXsd, outXsd, faultXsd, and it is these declarations which determine the contract for the exposed webservice, not a service mep.

"tfennelly" wrote : 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?
It is the only way in the current architecture.  I want a proper service contract as part of the architecture and, as you know, we have discussed this as part of the ESB 5 work.  Once we have the contract then it will be the definitive location for making these types of decisions but, until then, a separate configuration is necessary.

"tfennelly" wrote : So, assuming we add a "sync" flag on the http-gateway, how should the gateway respond when...
Ignore the service mep, it is irrelevant to the caller (see below).

"tfennelly" wrote : 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?
If I understand correctly you are expecting the service mep to declare the outcome of the invocation from the perspective of the client, but this has never been the case.  It has always been an indication of intent on behalf of the service implementation.

Originally there was no mep, and the decision for a pipeline to return a response was left completely up to the implementation of the actions.  If they returned a null response then the pipeline terminated at that point, if a message reached the end then it would attempt to send a response to a client.  This caused numerous issues, especially when actions were intended to be used in both scenarios as it required a new action, or specific handling, to decide whether the message was to be propagated along the pipeline.  If this was not done, or if the wrong action was used, then we had situations where multiple responses were being sent to the caller.

The mep was introduced, to the service implementation, as a way of trying to clean some of this up and allow the service to declare, regardless of how the actions behaved, whether a response could be sent at the end of the pipeline.  It meant that it was no longer necessary to know which action could progress the pipeline processing and it removed a major source of problems.

If the mep is declared RequestResponse then the service is stating that it should, directly, respond to the caller.  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.

So your table should look as follows

1. gateway sync=true, service mep=OneWay?

Synchronous invocation, response may come from a second service (as highlighted in IM conversation).

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.

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.

So in every case the gateway configuration you are discussing will map directly onto the invocation, irrespective of the service mep.

It appears that you are looking for a service contract definition but the mep is not, and has never been, that.  The closest we have at present is the EBWS configuration on the service.

Kev

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252493#4252493

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252493