[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rampart-dev
Subject:    [jira] Commented: (AXIS2-4729) URI based dispatching is too tightly
From:       "Amila Chinthaka Suriarachchi (JIRA)" <jira () apache ! org>
Date:       2010-05-31 5:41:36
Message-ID: 31024093.77261275284496329.JavaMail.jira () thor
[Download RAW message or body]


    [ 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


[prev in list] [next in list] [prev in thread] [next in thread]