axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanka Samaranayake <>
Subject Re: [Axis2] Generating a wrong port address for POJO deployment
Date Mon, 12 May 2008 09:30:59 GMT
Hello Everyone,

Please find my comments inlined.

Deepal Jayasinghe wrote:
>> Hi Deepal,
>> See comments inline
>> On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe < 
>> <>> wrote:
>>     Hi Sanka and all,
>>     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. 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 

>>     It is not good to have
>>     "SampleService.SampleServiceHttpSoap12Endpoint" as the service
>>     address.
>> Y? I dont see any reason y its not good.
> Well , we had a long discussion a long time ago and we agreed the 
> structure we had before. So something like structure of the end point 
> address we should not change.

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 

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.


<wsdl:service name="Version">
    <wsdl:port name="VersionHttpSoap11EndpointWithSSL" 
     <wsdl:port name="VersionHttpSoap11EndpointWithUsernameAndSignature" 
    <wsdl:port name="VersionHttpSoap11EndpointWithSAMLAndSignature" 
    <wsdl:port name="VersionHttpSoap11EndpointWithKerberos" 


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.

Thanks & Regards,

>>     We did not agree anywhere about this structure.
>> As Sanka has pointed out this has been discussed in the List. Nobody 
>> had any objections to it. The only concern was not to break existing 
>> code.
> I am sorry for that , and I will go though that back and reply .
> -Deepal
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Sanka Samaranayake
WSO2 Inc. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message