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 Wed, 14 May 2008 05:35:06 GMT
Hello Everyone,

Please find my comments inlined.

Tom Jordahl wrote:
>> The fact that Axis2 does this wacky thing actually made it HARDER for
>>     
>
>
> Just to chime in here - I agree with Dan that Axis2 *is* doing something
> wacky here by tacking on the port name to the endpoint.
>
> As far as the "we should throw an error if a SOAP 1.1 endpoint gets SOAP
> 1.2" argument is concerned I don't buy in to that.  "Be strict in what
> you emit and liberal in what you accept" seems to apply here.

Please consider endpoint address[2] in CustomBinding_Echo port in the 
following WSDL[1]. Now if a client application sends a SOAP 1.2 request 
to that endpoint, it will throw a fault saying incorrect SOAP version 
which IMO desired behavior and it complies with what is defined by that 
service contract. 

Now the inability to raise a fault for a SOAP 1.2 request which comes to 
SOAP 1.1 binding endpoint address which we expose through the WSDL of a 
service deployed in Axis2 server is something which we need to fix even 
if no one bothers too much for the moment.

Thanks & Regards,
Sanka


[1] http://131.107.72.15/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl
[2] 
http://131.107.72.15/WSAddressingCR_Service_WCF/WSAddressing10.svc/Soap11
>   If a
> single endpoint URL can accept both SOAP 1.1 and SOAP 1.2, that is a
> feature!
>
> +1 to eliminating the wackiness in the address.
>
> --
> Tom Jordahl
>
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org] 
> Sent: Tuesday, May 13, 2008 11:03 AM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Generating a wrong port address for POJO deployment
>
>
> Dims,
>
> On May 12, 2008, at 11:59 PM, Davanum Srinivas wrote:
>   
>> I was talking about moving JAXWS services and clients across
>> implementations. Not on the wire interop. Sorry it was not clearer.
>>     
>
> I'm not sure how that applies here.   Axis2 is the only JAX-WS  
> implementation that does this funky Endpoint.Port URL thing.   CXF  
> certainly does not and neither does the reference implementation.    
> Both of them use a deployment descriptor thing to allow the user to  
> specify the full URL that the service is deployed on.
>
> The fact that Axis2 does this wacky thing actually made it HARDER for  
> the tck stuff as Jarek had to do a bit more work to deal with the  
> different URL's that Axis uses compared to CXF and the RI (both of  
> which use the same URL's).
>
> Dan
>
>
>
>   
>> thanks,
>> -- dims
>>
>> On Mon, May 12, 2008 at 11:56 PM, Amila Suriarachchi
>> <amilasuriarachchi@gmail.com> wrote:
>>     
>>>
>>> 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.
>>>>         
>>> I don't have any experience with the tck. But I think it should not  
>>> have a
>>> problem with the
>>> interop. please see this wsdl
>>>
>>>       
> http://131.107.72.15/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl
>   
>>> This is a wsdl from .Net interop site. They generate different  
>>> ports for
>>> different bindings and if
>>> we send a wrong message (i.e soap11 to soap12 port) to a wrong port  
>>> it gives
>>> an exception.
>>>
>>> IMO it is better to have mechanism to dispatch the binding using  
>>> request url
>>> information. if we take the
>>> contract first side, one wsdl can have many Soap11 or Soap12  
>>> bindings with
>>> different polices. In that case
>>> we need to have this kind of mechanism.  At least to configure it  
>>> using
>>> services.xml as keith has mentioned.
>>>
>>> thanks,
>>> Amila.
>>>
>>>
>>>       
>>>> 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.VersionHttpSoap11
> EndpointWithSSL 
>   
>>> "/>
>>>       
>>>>>>>   </wsdl:port>
>>>>>>>   <wsdl:port
>>>>>>>               
>>> name="VersionHttpSoap11EndpointWithUsernameAndSignature"
>>>       
>>>>> binding="ns:VersionSoap11Binding">
>>>>>           
>>>>>>>      <soap:address
>>>>>>>               
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11
> EndpointWithUsernameAndSignature 
>   
>>> "/>
>>>       
>>>>>>>   </wsdl:port>
>>>>>>>  <wsdl:port name="VersionHttpSoap11EndpointWithSAMLAndSignature"
>>>>>>>               
>>>>> binding="ns:VersionSoap11Binding">
>>>>>           
>>>>>>>      <soap:address
>>>>>>>               
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11
> EndpointSAMLAndSignature 
>   
>>> "/>
>>>       
>>>>>>>   </wsdl:port>
>>>>>>>  <wsdl:port name="VersionHttpSoap11EndpointWithKerberos"
>>>>>>>               
>>>>> binding="ns:VersionSoap11Binding">
>>>>>           
>>>>>>>      <soap:address
>>>>>>>               
> location="http://localhost:8080/axis2/services/Version.VersionHttpSoap11
> EndpointWithSSLWithKerberos 
>   
>>> "/>
>>>       
>>>>>>>   </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
>>>>
>>>>
>>>>         
>>>
>>> --
>>> Amila Suriarachchi,
>>> WSO2 Inc.
>>>       
>>
>> -- 
>> 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
>>
>>     
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message