axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: WSDL generation for the services exposed only in local transport
Date Tue, 14 Jun 2011 19:57:39 GMT
On Tue, Jun 14, 2011 at 08:48, Heshan Suriyaarachchi
<> wrote:
> Hi Devs,
> I am opening up this thread to discuss $subject.
> Recently, I did some improvements [1] to the Axis2 local transport, inorder
> to get it working against Synapse nhttp transport. Now the local transport
> is working fine against the nhttp transport.

To me the statement "getting transport A working against transport B"
doesn't make sense. Two distinct transports A and B never interact
directly. Each of them interacts with the Axis2 engine through (in
principle) well defined APIs. If a component (Synapse in this case)
based on Axis2 has an issue when using A and B together, then either
transport A, transport B, the component or the Axis2 engine has an
issue (or multiple components have an issue), but saying that
transport A needs to be fixed to work with transport B doesn't make
sense and is an indication that the fundamental issue has not been
identified properly.

At this point, what we know is this:
* NHTTP doesn't work as a transport sender in a standard Axis2 setup
[1]. It only works in Synapse. That means that from the point of view
of Axis2, the NHTTP transport is broken. That is of course OK, because
NHTTP is shipped with Synapse and nobody claims that it is supported
in a plain Axis2 setup.
* At some point I tried to figure out what would need to be changed to
make the NHTTP transport work in Axis2. IIRC the conclusion was that
one can make it work in Axis2, but then it no longer works in Synapse.
This would indicate that Synapse actually uses the transport API in a
way it was not designed for.
* As indicated in AXIS2-4944, the current version of
NonBlockingLocalTransportSender doesn't work in Axis2. Unless somebody
can come up with a valid unit test that exercises this piece of code,
this would mean that we introduced a broken piece of code in Axis2 in
order to work around another broken piece of code in a downstream
project. That is of course not OK.

Note that the issue with NonBlockingLocalTransportSender is also
blocking the review of other issues such as AXIS2-4991, because it is
not possible to construct a unit test that validates (or invalidates)
the proposed patch. That is BTW a general issue with the recent
patches for the local transport. As far as I can tell, none of them
added any new unit tests.

[1] At least that was my conclusion when I last looked at it. I'm
ready to retract that claim if somebody comes up with an example that
shows how to set up a simple Axis2 client that uses NHTTP as outgoing

> Now, my requirement is to expose an Synapse Proxy Service only in local
> transport. The reason behind is that, these proxy services which are exposed
> only in local transport will be used by other proxy services and will not be
> available for outside parties. Earlier, axis2 local transport did not have a
> TransportListener.
> With a TransportListener
> ====================
> I introduced [2] a TransportListener to the local transport. The transport
> listener's methods are used to calculate the endpoints for the service which
> will be used in generating the WSDL for the service. Therefore, now if the
> service exposed in the local transport, the local endpoint is also shown in
> the WSDL. Although the local endpoints are shown in the WSDL, outside
> parties can not access the local endpoint.
> The problem this patch introduce is, now the WSDL shows the local transport
> endpoints. Which is wrong since external users can not access local
> transport.
> So the solution is not to show the local transport endpoints in generated
> wsdl. For that we may have to change Axis2 code.
> eg: As an example, I am attaching the following resources to prove my point.
> The synapse-config.xml is the Synapse Configuration and the attached WSDLs
> are for the proxy servivces, LocalTransportProxy and SecondProxy. The
> SecondProxy is exposed only via the local transport and the local endpoints
> are shown in the WSDL which is wrong IMV.
> Without a TransportListener
> ======================
> If we did not have a LocalTransportListener and if a service is exposed
> through local transport only, the WSDL for the service will not be
> generated. The reason behind is that; inorder to generate the WSDL, there
> should be a mechanism to derive the endpoints for the service. Since, the
> TransportListener is not there, there is no mechanism to derive the
> endpoints for the service(which is only exposed through the local
> transport).
> In case the service exposed through http,https,local transports; this wont
> be the case. Then the WSDL will be generated and only the http,https
> endpoints will be shown.
> Without the listener, if we expose a service only in local transport, WSDL
> generation fails since the endpoints can not be derived for that particular
> service.
> Your ideas and feedback on $subject is much appreciated.
> [1] -
> [2] -
> --
> Regards,
> Heshan Suriyaarachchi
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message