axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saminda Abeyruwan" <samin...@gmail.com>
Subject Re: [Axis2] Generating a wrong port address for POJO deployment
Date Mon, 12 May 2008 18:17:05 GMT
Hi Devs,

During the Axis2 1.4 evaluating time, I have explicitly asked why this
behaviour was introduced. Reason was to get extra information without
breaking backward compatibility.

The prior semantic has introduce a hidden information in WSDL. WSDL shows
[service].[port] and it does work for [service] too. I am not an expert in
WSDL, as per my understanding [service.port] and [service] would be two
different endpoint and it should be shown in the WSDL.

Introducing a parameter would solve the problem to some extent. IMHO the
default behaviour should be showing [service].[port] and [service].

Thank you!

Saminda

On Mon, May 12, 2008 at 9:20 PM, Davanum Srinivas <davanum@gmail.com> wrote:

> Keith,
>
> That would be good, but remember the JAXWS services don't have
> service.xml's :) they specify the expected service name in the
> annotation.
>
> -- dims
>
> On Mon, May 12, 2008 at 10:53 AM, keith chapman <keithgchapman@gmail.com>
> wrote:
> > Dims,
> >
> > How about making it flexible. Introduce a service.xml property where you
> can
> > set a aliases for the endpoint urls? We may need three properties for
> the
> > tree default bindings. That way the user can have very nice URLs...
> >
> > Thanks,
> > Keith.
> >
> >
> >
> > On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas <davanum@gmail.com>
> wrote:
> > > Sanka,
> > >
> > > for one thing, i haven't seen anyone else use it. another thing, makes
> > > it *slightly* more difficult for interop work and for tck work. It
> > > also makes it more difficult for people who want to design their own
> > > URI's for their web services and need complete control (yes, there are
> > > a few of those!). Yes, we can shove it down their throats, but that
> > > does not mean we should...
> > >
> > > thanks,
> > > dims
> > >
> > >
> > >
> > >
> > > On Mon, May 12, 2008 at 7:05 AM, Sanka Samaranayake <ssanka@gmail.com>
> > wrote:
> > > > Deepal jayasinghe wrote:
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >    When I deploy a very simple POJO service it generates
> > following
> > > > as
> > > > > > > >    the service section in WSDL. As I know this is
not nice
> and
> > we
> > > > > > > >    need to fix this as soon as possible.
> > > > > > > >  Why is it not nice? This gives us the ability to
apply
> binding
> > > > level security correctly which is not possible with the endpoint
> > addresses
> > > > we used to have.
> > > > > > > >
> > > > > > > As I replied earlier , you can figure out the SOAP version
> from
> > the
> > > > SOAP message , so you do not need to send the SOAP version in the
> end
> > point
> > > > address.
> > > > > > >
> > > > > >
> > > > > > Why do you say it is redundant  code?  Previously we had
> > > > http://localhost:8080/axis2/services/foo as the SOAP 1.1 and SOAP
> 1.2
> > > > binding endpoints. Now say that client picks the SOAP 1.1 binding
> > endpoint
> > > > and accidentally sends SOAP 1.2 request.
> > > > > >
> > > > > IMO which is wrong. If he picks 1.1 then should send a 1.1
> request.
> > > > >
> > > >
> > > >  That is exactly my point. If he picks SOAP 1.1 then you *should*
> send a
> > > > SOAP 1.1 request. If he sends a SOAP 1.2 request we *should* throw
> an
> > > > exception saying incorrect SOAP version. Earlier we were *not* doing
> > that
> > > > because we had the *same* endpoint address for both bindings.
> However
> > now we
> > > > can do that because by looking at the endpoint we can decide the
> exact
> > > > binding which the client has picked.
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > > Here the right thing would be to throw an exception saying
> incorrect
> > > > SOAP version where as Axis2 server won't complain which IMO is a
> bug.
> > Now if
> > > > you use http://localhost:8080/axis2/services/foo.SOAP11Endpoint as
> the
> > SOAP
> > > > 1.1. binding endpoint we can do a prior evaluation of the request
> and
> > throw
> > > > an exception if we receive a SOAP 1.2 request which IMO is the
> correct
> > > > behavior.
> > > > > >
> > > > > Only problem I have is having the SOAP11Endpoint name in the
> address ,
> > > > >
> > > >
> > > >  Please explain why do you have a problem with [service].[port]
> format ?
> > > >
> > > >
> > > >
> > > > > I do not mind sending that as some where else.
> > > > >
> > > >
> > > >
> > > >  Where would you suggest that we should have the port name s.t. we
> can
> > > > decide the intended port (or the binding) of the request and do
> throw an
> > > > exception if the client has sent a SOAP 1.2 request by error where
> he
> > would
> > > > have actually intended the SOAP 1.1 endpoint ?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > I know that the structure of endpoint address is important that
> it
> > is
> > > > something that we should not be mess around. That is the exact
> reason
> > why I
> > > > posted[1]  it to developer mailing list. However I think we should
> be
> > > > flexible enough to change what we agreed on if there are valid
> reasons
> > to do
> > > > so and if we don't lose anything by doing it.
> > > > > >
> > > > > > One reason for using [service].[port] would be that it allows
> the
> > server
> > > > to do prior evaluations of SOAP requests hence make it less
> error-prone
> > (As
> > > > I mention in my earlier)
> > > > > >
> > > > > > Another reason would be that [service].[port] format makes lot
> of
> > sense
> > > > if we want to support multiple policy alternatives scenario at the
> Axis2
> > > > server-side. Lets say a service requires strong authentication, but
> > gives
> > > > the client multiple options of  SSL mutual authentication, username
> with
> > a
> > > > signature, SAML with a signature or Kerberos. It does it via a
> policy in
> > the
> > > > services.xml which contains an alternative for each scenario.
> > > > > >
> > > > > > Now one option would be to do some processing of the request
to
> > figure
> > > > out the option the client has chosen and then do a complete
> evaluation
> > > > against that policy alternative. But it can be very expensive
> depending
> > of
> > > > the complexity of each policy alternative and of cause the number of
> > policy
> > > > alternatives which service exposes. Further there is a possibility
> that
> > some
> > > > policy alternatives are indeterminate by only looking at the
> request.
> > > > > >
> > > > > > The other option would be to generate multiple endpoints s.t.
> each
> > > > endpoint would correspond to exactly one policy alternative during
> the
> > > > deployment time.
> > > > > >
> > > > > > e.g.
> > > > > >
> > > > > > <wsdl:service name="Version">
> > > > > > ....
> > > > > >   <wsdl:port name="VersionHttpSoap11EndpointWithSSL"
> > > > binding="ns:VersionSoap11Binding">
> > > > > >       <soap:address
> > > >
> > location="
> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSL
> "/>
> > > > > >    </wsdl:port>
> > > > > >    <wsdl:port
> > name="VersionHttpSoap11EndpointWithUsernameAndSignature"
> > > > binding="ns:VersionSoap11Binding">
> > > > > >       <soap:address
> > > >
> > location="
> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithUsernameAndSignature
> "/>
> > > > > >    </wsdl:port>
> > > > > >   <wsdl:port
> name="VersionHttpSoap11EndpointWithSAMLAndSignature"
> > > > binding="ns:VersionSoap11Binding">
> > > > > >       <soap:address
> > > >
> > location="
> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointSAMLAndSignature
> "/>
> > > > > >    </wsdl:port>
> > > > > >   <wsdl:port name="VersionHttpSoap11EndpointWithKerberos"
> > > > binding="ns:VersionSoap11Binding">
> > > > > >       <soap:address
> > > >
> > location="
> http://localhost:8080/axis2/services/Version.VersionHttpSoap11EndpointWithSSLWithKerberos
> "/>
> > > > > >    </wsdl:port>
> > > > > > .....
> > > > > >
> > > > > > </wsdl:service>
> > > > > >
> > > > > > That way we can straight way say the option client as picked
and
> > > > evaluate the quest based on the target policy alternative with IMO
> is a
> > > > better way of supporting multiple policy alternatives at the
> > server-side. We
> > > > need to use [service].[port] format if we are to implement the
> support
> > for
> > > > multiple policy alternatives feature.
> > > > > >
> > > > > Thank you so much for such a descriptive mail. I will think though
> and
> > > > send a reply soon..
> > > > >
> > > > > -Deepal
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >  --
> > > >  Sanka Samaranayake
> > > >  WSO2 Inc.
> > > >
> > > >  http://sankas.blogspot.com/
> > > >  http://www.wso2.org/
> > > >
> > > >
>  ---------------------------------------------------------------------
> > > >
> > > >  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > >  For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Davanum Srinivas :: http://davanum.wordpress.com
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> >
> > Keith Chapman
> > Senior Software Engineer
> > WSO2 Inc.
> > Oxygenating the Web Service Platform.
> > http://wso2.org/
> >
> > blog: http://www.keith-chapman.org
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org

Mime
View raw message