axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "keith chapman" <keithgchap...@gmail.com>
Subject Re: [Axis2] Generating a wrong port address for POJO deployment
Date Mon, 12 May 2008 14:53:20 GMT
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

Mime
View raw message