"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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...