axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanka Samaranayake <ssa...@gmail.com>
Subject Re: [Axis2] Generating a wrong port address for POJO deployment
Date Tue, 13 May 2008 06:15:46 GMT
Hi Saminda,

Please find my comments inlined.



Saminda Abeyruwan wrote:
> 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.

No

We should not show two different endpoints in WSDL for the following 
reasons.

-- One reason is that both endpoint addresses refers to the same 
binding. Therefore it would be redundant information if both endpoint 
address is shown.
-- Another reason is that the newer format of endpoint addresses allows 
prior request evaluation hence more accurate.
-- The the reason why we allow the order format is just to preserve 
backward compatibility.


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

I can't understand which one you are suggesting :-P . And I think you 
are also a referring to an alternative solution similar to which Keith 
suggested.

Thanks & Regards,
Sanka

>
> Thank you!
>
> Saminda
>
> On Mon, May 12, 2008 at 9:20 PM, Davanum Srinivas <davanum@gmail.com 
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>     <mailto:axis-dev-unsubscribe@ws.apache.org>
>     > > > > For additional commands, e-mail:
>     axis-dev-help@ws.apache.org <mailto: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
>     <mailto:axis-dev-unsubscribe@ws.apache.org>
>     > > >  For additional commands, e-mail:
>     axis-dev-help@ws.apache.org <mailto:axis-dev-help@ws.apache.org>
>     > > >
>     > > >
>     > >
>     > >
>     > >
>     > > --
>     > > Davanum Srinivas :: http://davanum.wordpress.com
>     > >
>     > >
>     > >
>     > >
>     > >
>     ---------------------------------------------------------------------
>     > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>     <mailto:axis-dev-unsubscribe@ws.apache.org>
>     > > For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <mailto: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
>     <mailto:axis-dev-unsubscribe@ws.apache.org>
>     For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <mailto:axis-dev-help@ws.apache.org>
>
>
>
>
> -- 
> Saminda Abeyruwan
>
> Senior Software Engineer
> WSO2 Inc. - www.wso2.org <http://www.wso2.org>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 7.5.524 / Virus Database: 269.23.16/1427 - Release Date: 5/11/2008 1:08 PM
>   


-- 
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


Mime
View raw message