[jira] Commented: (AXIS2-4729) URI based dispatching is too tightly coupled to the HTTP transport

["Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873550#action_12873550 ] 

Amila Chinthaka Suriarachchi commented on AXIS2-4729:
-----------------------------------------------------

I thought, axis2 uses servicePath as a delimiter of service/operation part.

i.e for any uri it can search for 'services' (or as given in axis2.xml) and find the service/operation part.    

But as you have given it combines this with context root. Further thinking in the way you have given, these properties should belongs to transport parameters rather than axis2.xml top level parameters.

What I would like to suggest is to do what I was thinking :)

use service part as a delimiter. Then is is transport independent and any one can have any thing before it.

e.g. http://localhost:8080/axis2/services/Myservice
       tcp://localhost:6060/services/Myservic



> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org