-
30. Re: Http Gateway - requirements please...
"dward" wrote:
Even though part of me wants to side with Tom and Daniel on this (so as to allow maximum flexibility to the user), I think we would be opening up a big can of worms. I don't think we want to - or even should - support everything you can put into a web.xml. We're not trying to be an entire "Servlet [Container] Gateway" here, just an HTTP Gateway.
This is also my opinion. The purpose of the http gateway is to expose services through http endpoints, and only that. The fact that we are generating web.xml and exposing these through a servlet container should be an implementation detail.
If we are to support merging in web.xml then it has the following negative impacts
- potential merges can cause the generated web.xml to be invalid
- potential merges can cause interference at run time
- any generation we do automatically becomes part of the public API of the gateway.
Kev -
31. Re: Http Gateway - requirements please...
"tfennelly" wrote:
OK... so I think we are in agreement then that EBWS in it's current form would need to change in order to provide a common basis for these http related features? I thought Kev was suggesting otherwise.
It was never my intent to suggest otherwise, apologies for not being clear."tfennelly" wrote:
after that (for me) it's just about the format and I think keeping it in line with the web.xml makes sense from a user perspective (they know web.xml) and removes the need to perform a mapping (because it's already in the target format).
They also know jboss-esb.xml where the rest of the config lies."tfennelly" wrote:
What we differ on perhaps is the strictness of the validation. Kev and Dave prefer the "we only allow values X, Y and Z and we block everything else" approach, where as Danny and I seem to prefer the "we don't allow A, B, or C but do allow everything else" approach (if that makes sense :) ).
I think this is a fair summary, although I would add that 'allowing everything else' ties us into a particular implementation (it is now part of the public API) and also allows unforeseen side-effects to exist without constraint, especially if there is also a D which should have been explicitly excluded but wasn't.
Kev -
32. Re: Http Gateway - requirements please...
It is now time to revisit this work so we need to nail down the requirements. These are the requirements as I see them.
The purpose of this work is to provide a gateway into the ESB using http as the transport mechanism.
We are not writing extensible frameworks to support any transport but, as the current implementation choice is to use a servlet, we should be modifying the current EBWS codebase to share some of the implementation details. We should be deploying a single war file which should have its urls divided into ebws and http sections (perhaps /ebws/* and /http/* or more suitable)
All configuration must be done from within the jboss-esb.xml file, with any deployment artifacts (for example web.xml) being generated solely by the ESB. The HTTP gateway functionality must include the following
- Configurable support for the following verbs: DELETE, HEAD, GET, POST, PUT and automatic support for OPTIONS
- security, covering the following: authentication, transport guarantees, security constraints
- security integrating with Daniel's work
- url patterns
- Configurable synchronous/asynchronous behaviour (mep, timeout, async response)
- No specific servlet integration (e.g. filters/listeners)
There will probably be areas of this that needs to be fleshed out further, but this should provide the integration we need without exposing the specific details of the implementation.
Kev -
-
34. Re: Http Gateway - requirements please...
"Kevin.Conner@jboss.com" wrote:
We should be deploying a single war file which should have its urls divided into ebws and http sections (perhaps /ebws/* and /http/* or more suitable)
I'm not a big fan of those url patterns. I would rather see:
http://host/${service.category}/${service.name}
, and for web services specifically (whether they be ebws, the new webservice proxy stuff, ...), I would want the wsdl to be available there also per "?wsdl" convention:
http://host/${service.category}/${service.name}?wsdl
This would be in addition to the contract wsdl urls we have now. In fact, a brainstorm way for the "?wsdl" to easily work would be for there to be a servlet filter in the new http gateway that catches anything that ends in "*?wsdl" and request dispatches over to the existing contract wsdl location, which can be inferred by parsing the request uri path for /${service.category}/${service.name}.
Thoughts? -
35. Re: Http Gateway - requirements please...
"dward" wrote:
I'm not a big fan of those url patterns. I would rather see:
http://host/${service.category}/${service.name}
Well this can certainly be the default although the endpoint must be something like
http://host/context/http/${service.category}/${service.name}
There must be a way to separate ebws from http.
We already have a context because of the war and we need to further divide that into two areas, there must be a way to separate ebws from http."dward" wrote:
web services specifically (whether they be ebws, the new webservice proxy stuff, ...), I would want the wsdl to be available there also per "?wsdl" convention:
http://host/${service.category}/${service.name}?wsdl
This should already be handled for EBWS because of the JBossWS integration.
As for the rest, can we please get the http gateway working first before we go off track and implement other features?
Kev -
36. Re: Http Gateway - requirements please...
First, why can't ${service.category} be the context? Are we worried about "too many wars" being deployed?
Next, can you explain your reasoning why ebws and http paths must be kept separate? The only thing I can think of is if you wanted to provide *both* soap-ws/http and raw-xml/http access to the same service, at which point you'd have to distinguish them somehow.
Last, what if ${service.category} and ${service.name} have spaces in them? The ESB allows for this, but my guess would be that for a url, each space would have to be replaced with %20. Just something to make sure we test. -
37. Re: Http Gateway - requirements please...
"dward" wrote:
First, why can't ${service.category} be the context?
This is done per esb deployment so there could easily be conflicts with other esb deployments (services in same category) or even other war deployments."dward" wrote:
Next, can you explain your reasoning why ebws and http paths must be kept separate? The only thing I can think of is if you wanted to provide *both* soap-ws/http and raw-xml/http access to the same service, at which point you'd have to distinguish them somehow.
Someone could choose to do both, for whatever reason, and may even have multiple gateways pointing at the same target service. The EBWS is a fixed, 1-1 relationship but the http need not be. There could easily be different http gateways, with different composers and/or different security constraints, targeting the same ESB service."dward" wrote:
Last, what if ${service.category} and ${service.name} have spaces in them? The ESB allows for this, but my guess would be that for a url, each space would have to be replaced with %20. Just something to make sure we test.
This is definitely something that we need to test, good point.
Kev -
38. Re: Http Gateway - requirements please...
"Kevin.Conner@jboss.com" wrote:
"dward" wrote:
First, why can't ${service.category} be the context?
This is done per esb deployment so there could easily be conflicts with other esb deployments (services in same category) or even other war deployments.
I don't see why having multiple services in the same category would cause a problem. Brainstorm:
- new ${service.category} + new ${service.name} = deploy a new war with ${service.category} as the context, which contains a servlet which dynamically routes the request to the appropriate ESB service (via ServiceInvoker) based on parsing the uri path for ${service.name}.
- existing ${service.category} + new ${service.name} = no deployment change necessary because the servlet will dynamically route based on the new ${service.name}
- existing ${service.category} + remove ${service.name} = no deployment change necessary, *unless* there are no more ${service.name}'s associated with that ${service.category}, at which point the context (webapp) is undeployed.
Concerning "other war deployments", this will always be an issue no matter what we do. Even if we come up with a single context name that sounds very ESB-specific, there's still the chance someone could have named their war that, too. We just have to have a warning in the documentation about this. -
39. Re: Http Gateway - requirements please...
What makes sense to me is something like the following...
1. Allowing the context to be the bus specific part, defined on the bus (in the provider section) and allowing it to be whatever the user decides i.e. no artifical constraints/prefixes such as "http" etc.
2. Allowing the urlPattern to be a listener specific "filter" that filters certain requests off the bus (context) referenced by the listener's busrefid. Again, this can be whatever the user decides.
In the case of EBWS, there wouldn't be an explicit bus or listener definition, so it's context and urlPattern could be something implied from the service definition e.g. context as "ebws" and listener urlPattern as "${service.category}/${service.name}" etc ? -
40. Re: Http Gateway - requirements please...
"dward" wrote:
I don't see why having multiple services in the same category would cause a problem.
Because the lifecycle of the generated war is tied to the lifecycle of the esb defining the gateways. They are not independent."dward" wrote:
Concerning "other war deployments"
Agreed.
Kev -
41. Re: Http Gateway - requirements please...
"tfennelly" wrote:
1. Allowing the context to be the bus specific part, defined on the bus (in the provider section) and allowing it to be whatever the user decides i.e. no artifical constraints/prefixes such as "http" etc.
No, please keep the context as it is for now i.e. the name of the war file matching the esb deployment."tfennelly" wrote:
2. Allowing the urlPattern to be a listener specific "filter" that filters certain requests off the bus (context) referenced by the listener's busrefid. Again, this can be whatever the user decides.
We should certainly allow the user to specify the urlPattern provided that we make sure that there are no conflicts. Adding a prefix to the url is a simple and straight forward way to make sure that these never conflict with the EBWS."tfennelly" wrote:
In the case of EBWS, there wouldn't be an explicit bus or listener definition, so it's context and urlPattern could be something implied from the service definition e.g. context as "ebws" and listener urlPattern as "${service.category}/${service.name}" etc ?
This is already how it works for EBWS, albeit without any prefix.
Kev -
44. Re: Http Gateway - requirements please...
OK, so I implemented a bit of this so as we can have something concrete to discuss. It's not in any way complete and there are things in it that I plan on refactoring (e.g. removing the ability to reference a web.xml/jboss-web.xml, as requested), as well as there being bits which are not yet implemented at all. Also, Kev has an issue with using the mep to decide whether or not a response is sent back from a Http Gateway. Plan on discussing that separately.
The main thing I wanted to look at was the common codebase for EBWS and the new HttpGateway. I have implemented the bones of a "WebModel" concept that gets built up at deploy time and is then used to construct a single war file for the .esb deployment.
See SVN: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/tfennelly/httpg2/product/rosetta/src/org/jboss/internal/soa/esb/listeners/war
So the basic idea is simple... the Deployer:
1. Creates an instance of WebDeploymentArchive. (Implemented)
2. Calls EBWS specific code for it to add it's servlets etc to the model. (Not implemented).
3. Calls HttpGateway specific code for it to add servlets etc to the model. (Implemented)
4. Creates and deploys the war sub deployment. (Implemented)
Note that where I say "Implemented"... I'm not saying that part is complete and will not change!!! Really just saying "there's something there" for that part of the equation ;)
The base context is based .esb name (as requested).
For the Http Gateway, it's currently prefixing the urlPattern with the associated http provider bus name (and not hardcoded "http", as requested). So for a provider and listener configured as follows:<http-provider name="http"> <http-bus busid="ordermgt" /> </http-provider>
<http-listener name="oml" busidref="ordermgt" urlPattern="/in/*" />
The following requests will be filtered through to that listener....http://{host:port}/{.esbname}/ordermgt/in/*
This seem OK so far?