-
60. Re: Http Gateway - requirements please...
"jtyrrell" wrote:
David W, was working on XSLT in/out of a gateway (it was faster the smooks for him) he was writing around Web Services, should that idea be included in this gateway. Does that even make sense?
I dropped the XSLT capability of the SOAPProxy a long time ago. It didn't make architectural sense, as it makes the proxy do more than it is supposed to. Daniel Bevenius wrote an XsltAction, which can be put in front of and/or after the SOAPProxy, which makes a lot more sense for the pipeline ala' "separation of concerns". -
61. Re: Http Gateway - requirements please...
"jtyrrell" wrote:
A few thoughts from this page:
http://www.jboss.org/community/wiki/HTTPGateway
Hey Jim... thanks for ahving a look and providing some feedback..."jtyrrell" wrote:
What about performance and tuning considerations?
I'm fairly sure this would be done at a container level and that there's nothing in the servlet spec wrt performance tuning etc. So, I think the answer to your question is... same as for any other war deployment in the JBossWeb container."jtyrrell" wrote:
From that link:
In the "Synchronous/Asynchronous Responses"
To be worked out!! Currently using the Service MEP to decide whether or not the gateway should wait on the Service response (mep=RequestResponse), or deliver an empty response immediately (mep="OneWay"). Kev has indicated that we can't use the mep, so we need to find out how it should work.
section.
Why should we mandate one or the other, why can this not be configurable. Why would we change the "semantics" for this option around mep, although maybe that is not a valid thought either.
I think both sync and async should be support with this, with hopefully the same kind of configurations as the mep parameter?
Not sure what you mean here Jim. Both sync and async are/will be supported. The only outstanding question (AFAIK) is the how part i.e. if we can't use the associated service's mep to decide how the gateway should respond (and Kev has indicated that we can't), what do we use and how would that work ala the questions I asked a few posts back. -
62. Re: Http Gateway - requirements please...
"tfennelly" wrote:
Not sure what you mean here Jim. Both sync and async are/will be supported. The only outstanding question (AFAIK) is the how part i.e. if we can't use the associated service's mep to decide how the gateway should respond (and Kev has indicated that we can't), what do we use and how would that work ala the questions I asked a few posts back.
Sorry, thought we had put this to bet a long time ago but I will look back and follow up on your latest posting.
Kev -
64. Re: Http Gateway - requirements please...
"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 -
65. Re: Http Gateway - requirements please...
"Kevin.Conner@jboss.com" wrote:
but I will look back and follow up on your latest posting.
Ah, you posted after I went on vacation. That explains why I hadn't seen it :)
Kev -
66. Re: Http Gateway - requirements please...
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@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@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@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@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@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@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!! -
67. Re: Http Gateway - requirements please...
Sorry guys... just for clarity... what this is going to mean is...
1. Gateway sync="true": Gateway will sync invoke service and return the sync response payload in the http response.
2. Gateway sync="false": Gateway will async invoke service and return an empty response payload in the http response.
OK? -
68. Re: Http Gateway - requirements please...
2. Gateway sync="false": Gateway will async invoke service and return an empty response payload in the http response.
I think the section in the HTTP spec regarding a 202 status code gives some guidance on how this might work: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3
In that section it saysThe entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
One use case for the sync="false" is to kick off a long-running process and the 202 status can be used to indicate that the request was received and the accompanying response payload can be used to give the client some information about when the job might be done, a URL to retrieve the status, etc. This is partially supported in the JBR gateway with the asyncResponse property.
Can support for that type of interaction be included?
Thanks,
Scott -
69. Re: Http Gateway - requirements please...
Hi Scott... thanks for your comments.
"ScottDawson" wrote:
Can support for that type of interaction be included?/quote]
Yes, but not statically at the moment. How you could implement this currently is to write a service that "captures" the request, dispatches it async to the service that does the actual work, and then sets up the HttpResponse with whatever response code makes sense, plus a response payload containing the info needed by the client to make its decisions re getting the eventual response.
I'm not gone on the idea of putting in a "static" mechanism such as that on the JBR Gateway. What do you think? -
70. Re: Http Gateway - requirements please...
Duh.... sorry.... ignore the last post. Should have been...
"ScottDawson" wrote:
Can support for that type of interaction be included
Yes, but not statically at the moment. How you could implement this currently is to write a service that "captures" the request, dispatches it async to the service that does the actual work, and then sets up the HttpResponse with whatever response code makes sense, plus a response payload containing the info needed by the client to make its decisions re getting the eventual response.
I'm not gone on the idea of putting in a "static" mechanism such as that on the JBR Gateway. What do you think? -
71. Re: Http Gateway - requirements please...
"tfennelly" wrote:
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.
Yes, when referring to sync/async I had assumed you meant the invocation on the ESB service so I believe we are talking about the same thing."tfennelly" wrote:
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.
Sorry, was talking about the sync/async context so the gateway is the client of the ESB service as far as my posting was concerned."tfennelly" wrote:
Right... and just for clarity... in this case, the caller to the Service is the HttpGateway and not the "Client" invoking the gateway.
It is any invoker of an ESB service but, in this case, I am talking about the gateway."tfennelly" wrote:
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?
This is the reason why you cannot use the mep as the source of that decision and why you need the parameter on the gateway. It is not possible to use the mep in this way."tfennelly" wrote:
So the gateway makes a sync invocation on the OneWay Service?
Yes. Did you look through the continuation example I posted earlier in this thread? It contains an example of this."tfennelly" wrote:
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.
Brittle and hard to support in what way? This is nothing more than basic routing, passing a request over to another service to fulfil."tfennelly" wrote:
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?
Yes, and this is a major problem with the way in which the current transport layer is implemented and does not just affect InVM."tfennelly" wrote:
But doesn't this then hardcode a decisoin for all clients calling through this gateway?
It is not the HTTP client which is making this decision, rather it is the gateway acting as a proxy for the ESB service. It is deciding whether it should be exposing any response to the HTTP client."tfennelly" wrote:
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.
Sorry, but why is this behaviour any different from any other servlet/HTTP provider? If I have a servlet returning a response and the HTTP client chooses to ignore it then that is a decision for that HTTP client."tfennelly" wrote:
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).
I don't think the HTTP gateway should be providing this behaviour as it is really a decision for the ESB service, i.e. the business logic, to make. The ESB service understands the request better than the gateway and is free to make this type of decision based on all the criteria that it is aware of."tfennelly" wrote:
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 :)
ROFL, I'm sure that will happen anyway."tfennelly" wrote:
Thanks again Kev!!
No problems, keep the questions coming ;)
Kev -
72. Re: Http Gateway - requirements please...
"Kevin.Conner@jboss.com" wrote:
"tfennelly" wrote:
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 :)
ROFL, I'm sure that will happen anyway.
Sure, but I can then point him here :) -
73. Re: Http Gateway - requirements please...
Tom - your comments on the 202 status make good sense. So I could use sync="true", specify a 202 status code and create whatever response payload is necessary. That's very straightforward and flexible.
Thanks,
Scott -
74. Re: Http Gateway - requirements please...
Hey Scott... as it turns out, Kevin would also like the static option, so we'll be adding this too. It will look something like the following...
<http-gateway....> <asyncResponse status="202" payload="/async-responses/202.xml" /> </http-gateway>
This seem OK?
So both options will be available... the more dynamic version we described above, as well as this static version.