URI based dispatching is too tightly coupled to the HTTP transport
------------------------------------------------------------------
Key: AXIS2-4729
URL: https://issues.apache.org/jira/browse/AXIS2-4729
Project: Axis2
Issue Type: Bug
Components: kernel
Reporter: Andreas Veithen
URI based dispatching is supported for all transports that define an EPR syntax
that uses hierarchical URIs (in the sense of RFC3986) and where the path
component of the EPR is not used for transport specific information:
HTTP: Uses hierarchical URIs and the path information is exchanged as part of
the HTTP request -> URI based dispatching is always possible.
Mail: Uses the "mailto:"; scheme, which is not hierarchical -> no URI based
dispatching.
JMS: Uses hierarchical URIs, but the path component of the EPR identifies the
JMS destination -> no URI based dispatching.
UDP & TCP: Use hierarchical URIs, but they are not used by the transport
protocol itself -> URI based dispatching is possible if WS-Addressing is used.
For dispatching, Axis2 assumes that the EPRs have the following form:
<scheme>://<host>:<port>/<serviceContextPath>/<serviceName>...
serviceContextPath corresponds to the property with the same name in
ConfigurationContext and is built from the contextRoot and servicePath
parameters in axis2.xml. These two parameters take into the fact that a Web
application
* has a context root;
* may have additional servlets other than AxisServlet (e.g. the admin console
in the default Axis2 web app) and that therefore, the url-pattern of
AxisServlet is not necessarily "/*" (it is "/services/*" in the default web
app).
It is clear that this is only meaningful for the HTTP transport. There may be
other transport protocols for which the concept of a "service context path"
makes sense, but there is currently no example for this. For the UDP and TCP
transports, this concept is meaningless and one would expect that EPRs for
these protocols simply have the following form:
(udp|tcp)://<host>:<port>/<serviceName>...
What this shows is that:
* The current URI based dispatching mechanism in Axis2 is too tightly coupled
to the HTTP protocol.
* It makes the assumption that the serviceContextPath is the same for all
transports deployed in a given Axis2 instance. This is incorrect.
There are several potential solutions for this problem:
1. Introduce additional transport specific dispatchers that handle the case of
transports without serviceContextPath. Note that in most cases these
dispatchers would have to act as replacements for AddressingBasedDispatcher
(because the URI based dispatching is done at the WS-Addressing level).
Problem: doesn't solve the root cause and introduces additional complexity (the
user needs to configure these additional dispatchers to make the transport work
correctly).
2. Introduce a new MessageContext property that the TransportListener may set
to specify the serviceContextPath applicable to the transport. This property
would then be used by RequestURIBasedServiceDispatcher and
AddressingBasedDispatcher during dispatching. Problem: this only works if the
EPR used for dispatching belongs to the incoming transport. This may not be the
case with WS-Addressing: e.g. it is possible to specify an HTTP EPR in a WS-A
header of a message sent over another transport.
3. Define an extension interface that would be implemented by
TransportListeners that use hierarchical EPRs. This interface would be used by
RequestURIBasedServiceDispatcher and AddressingBasedDispatcher to query the
serviceContextPath applicable to a given transport protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
