axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: WSDL generation for the services exposed only in local transport
Date Tue, 26 Jul 2011 12:37:57 GMT
So, the bottom line is that it is OK to introduce a component into
Axis2 that violates the Axis2 API (NonBlockingLocalTransportSender
sets an incorrect value for the serverSide property) and it is not
worth trying to understand how this can be fixed such that it works
both in a pure Axis2 context and in Synapse?
NonBlockingLocalTransportSender actually works just fine with the
ServiceClient API if the incorrect code is changed so that it sets
serverSide=false. Did somebody actually check what happens in Synapse
when NonBlockingLocalTransportSender is made compliant with the Axis2
API? Some time ago there was a similar problem with other transports
(WSCOMMONS-444) and the conclusion was that it required a change in
Synapse to make these transports work properly with both Axis2 and
Synapse. It is likely that this fix in Synapse also covers the case of
NonBlockingLocalTransportSender.

Andreas

On Tue, Jul 26, 2011 at 11:22, Amila Suriarachchi
<amilasuriarachchi@gmail.com> wrote:
>
>
> On Mon, Jul 25, 2011 at 10:55 PM, Andreas Veithen
> <andreas.veithen@gmail.com> wrote:
>>
>> Just to summarize:
>>
>> * We have added a NonBlockingLocalTransportSender into the Axis2 code
>> base that doesn't respect the Axis2 APIs and that only works in
>> Synapse (see AXIS2-4944).
>> * I took us 5 JIRA issues (AXIS2-4967, AXIS2-5035, AXIS2-5036,
>> AXIS2-5037 and AXIS2-5043) to add a TransportListener for the local
>> transport. That TransportListener only implements the methods to
>> calculate the EPR, but it actually calculates the wrong EPR (see
>> AXIS2-5043).
>> * Now the proposal is to hardcode something into the kernel to exclude
>> these EPRs from WSDL generation.
>>
>> Can somebody please explain me what we are trying to achieve here?
>
> If you go through this thread you can see the answers. But let me tell you
> again.
>
> 1. Exposing a service only with local transport. The motivation is the
> security. When you expose a service only with local transport then that
> service is automatically secured. Can you suggest a way to do this with
> Axis2 1.6?
>
> 2. Second is to improve the existing local transport to work within a
> synapse proxy service. This does not have a use case only at axis2 level
> (same as axis2 can't use synapse nhttp transport to send/receive messages).
> But I think improving the existing thing rather than having a separate
> transport in synapse does not make any problem.
>
> thanks,
> Amila.
>
>
>>
>> Andreas
>>
>> On Mon, Jul 4, 2011 at 15:06, Heshan Suriyaarachchi
>> <heshan.suriyaarachchi@gmail.com> wrote:
>> > Hi Amila,
>> >
>> > On Sat, Jun 25, 2011 at 12:29 PM, Amila Suriarachchi
>> > <amilasuriarachchi@gmail.com> wrote:
>> >>
>> >>
>> >> On Mon, Jun 20, 2011 at 10:55 AM, Heshan Suriyaarachchi
>> >> <heshan.suriyaarachchi@gmail.com> wrote:
>> >>>
>> >>> Hi Andreas,
>> >>> So, in that case does that mean, we are going to
>> >>> 1) revert all the improvements did to the local transport OR
>> >>> 2) just remove the NonBlockingTransportListener class only?
>> >>> If it is the first option, then we have to improve the local transport
>> >>> in
>> >>> such a way that a user should be able to extended the local transport
>> >>> implementation and write a custom implementation. That will help us
to
>> >>> move
>> >>> the Synapse specific local transport to Synapse itself.
>> >>> If it is the second option, then we wont have to change that much of
>> >>> code
>> >>> level change.
>> >>> Although we have discussed about local transport here, my original
>> >>> question still remains ie. improving WSDL generation logic to support
>> >>> WSDL
>> >>> generation for serivces that is only exposed in local transport.
>> >>
>> >> Can you please test the given patch with the attached local transport
>> >> sender. This should allow you to export the service with only local
>> >> transport.
>> >>
>> >> It has hard coded the name local. but if you see this method same thing
>> >> has done for http and https as well.
>> >
>> > I tested your patch and with the given patch, the local endpoints are
>> > not
>> > shown in the generated WSDL. I have created a jira [1] to track the
>> > issue.
>> > There were some test failures and I will fix them and attach the patch
>> > to
>> > the jira.
>> >
>> > [1] - https://issues.apache.org/jira/browse/AXIS2-5085
>> >>
>> >> thanks,
>> >> Amila.
>> >>>
>> >>> On Thu, Jun 16, 2011 at 1:09 PM, Andreas Veithen
>> >>> <andreas.veithen@gmail.com> wrote:
>> >>>>
>> >>>> Since there is a consensus that NonBlockingLocalTransportSender
>> >>>> doesn't work with a pure Axis2 setup, is not unit testable and is
>> >>>> only
>> >>>> relevant for Synapse, the logical conclusion would be that it should
>> >>>> not be included in Axis2 but in Synapse.
>> >>>>
>> >>>> Andreas
>> >>>>
>> >>>> On Thu, Jun 16, 2011 at 08:43, Heshan Suriyaarachchi
>> >>>> <heshan.suriyaarachchi@gmail.com> wrote:
>> >>>> >
>> >>>> >
>> >>>> > On Wed, Jun 15, 2011 at 1:27 AM, Andreas Veithen
>> >>>> > <andreas.veithen@gmail.com>
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> On Tue, Jun 14, 2011 at 08:48, Heshan Suriyaarachchi
>> >>>> >> <heshan.suriyaarachchi@gmail.com> 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
>> >>>> >> transport.
>> >>>> >
>> >>>> > As Amila has pointed out earlier, NonBlockingLocalTransportSender
>> >>>> > is
>> >>>> > used to
>> >>>> > talk to a proxy service from another proxy service. Since the
nhttp
>> >>>> > transport is written in a non blocking manner,
>> >>>> > NonBlockingLocalTransport
>> >>>> > will work seamlessly against nhttp transport. Since, we are
using
>> >>>> > this
>> >>>> > TransportSender to talk between proxy services, it's difficult
to
>> >>>> > come
>> >>>> > up
>> >>>> > with a test case (test client) for this particular usecase.
>> >>>> >
>> >>>> >>
>> >>>> >> > 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] - https://issues.apache.org/jira/browse/AXIS2-4944
>> >>>> >> > [2] - https://issues.apache.org/jira/browse/AXIS2-5043
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > --
>> >>>> >> > Regards,
>> >>>> >> > Heshan Suriyaarachchi
>> >>>> >> >
>> >>>> >> > http://heshans.blogspot.com/
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > ---------------------------------------------------------------------
>> >>>> >> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>>> >> > For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>> >> >
>> >>>> >>
>> >>>> >>
>> >>>> >> ---------------------------------------------------------------------
>> >>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > Regards,
>> >>>> > Heshan Suriyaarachchi
>> >>>> >
>> >>>> > http://heshans.blogspot.com/
>> >>>> >
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>> Heshan Suriyaarachchi
>> >>>
>> >>> http://heshans.blogspot.com/
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Heshan Suriyaarachchi
>> >
>> > http://heshans.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message