You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Deepal jayasinghe <de...@gmail.com> on 2008/05/09 08:19:56 UTC

[Axis2] Generating a wrong port address for POJO deployment

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. It is not good to have 
"SampleService.SampleServiceHttpSoap12Endpoint" as the service address. 
We did not agree anywhere about this structure. I even created a JIRA [1]

<wsdl:service name="SampleService">
    <wsdl:port name="SampleServiceHttpSoap11Endpoint" 
binding="ns:SampleServiceSoap11Binding">
               <soap:address 
location="http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint"/>
</wsdl:port>

<wsdl:port name="SampleServiceHttpSoap12Endpoint" 
binding="ns:SampleServiceSoap12Binding"><soap12:address 
location="*http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*"/></wsdl:port><wsdl:port 
name="SampleServiceHttpEndpoint" 
binding="ns:SampleServiceHttpBinding"><http:address 
location="http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint"/></wsdl:port></wsdl:service>

[1] : https://issues.apache.org/jira/browse/AXIS2-3794

Thanks
Deepal

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
Deepal Jayasinghe wrote:
> My suggestion would be to have the wsdl which look like before  , 
> meaning when we do not have then do not do any changes to port address.


Sorry .. I can't understand what you are trying to say .. can you please 
explain a bit :-)

Thanks & Regards,
Sanka


> If user put a wsdl file then I do not mind doing anything.
>
> -Deepal
>> Sanka,
>>
>> #1: I specifically requested in that thread that existing code should 
>> work as-is. With this change it did not.
>> Specifically if one had existing clients in another language, they 
>> needed to be updated with a fresh endpoint since the
>> same service when deployed in Axis2 1.4 showed up at a different URL.
>>
>> #2: Because of this change, we had to jump through hoops to pass the 
>> TCK. because the user specified a service name in
>> the annotation and that is *NOT* where the service endpoint shows up.
>>
>> Thanks,
>> dims
>>
>> Sanka Samaranayake wrote:
>> | Hi,
>> |
>> | We discussed about that in a mailing thread[1] sometime back. Why 
>> do you
>> | think we should change that? IMO it is desirable to have 
>> [service].[port] in
>> | the service address since it makes valuable binding information 
>> available
>> | for request processing at service side.
>> |
>> | Sanka
>> |
>> |
>> | [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
>> |
>> | On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
>> | 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. It is not good to have
>> |> "SampleService.SampleServiceHttpSoap12Endpoint" as the service 
>> address. We
>> |> did not agree anywhere about this structure. I even created a JIRA 
>> [1]
>> |>
>> |> <wsdl:service name="SampleService">
>> |>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
>> |> binding="ns:SampleServiceSoap11Binding">
>> |>              <soap:address location="
>> |> 
>> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint 
>>
>> |> "/>
>> |> </wsdl:port>
>> |>
>> |> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
>> |> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
>> |> 
>> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*"/></wsdl:port><wsdl:port 
>>
>> |> name="SampleServiceHttpEndpoint"
>> |> binding="ns:SampleServiceHttpBinding"><http:address location="
>> |> 
>> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint 
>>
>> |> "/></wsdl:port></wsdl:service>
>> |>
>> |> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
>> |>
>> |> Thanks
>> |> Deepal
>> |>
>> |> ---------------------------------------------------------------------
>> |> 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Deepal Jayasinghe <de...@opensource.lk>.
My suggestion would be to have the wsdl which look like before  , 
meaning when we do not have then do not do any changes to port address. 
If user put a wsdl file then I do not mind doing anything.

-Deepal
> Sanka,
>
> #1: I specifically requested in that thread that existing code should 
> work as-is. With this change it did not.
> Specifically if one had existing clients in another language, they 
> needed to be updated with a fresh endpoint since the
> same service when deployed in Axis2 1.4 showed up at a different URL.
>
> #2: Because of this change, we had to jump through hoops to pass the 
> TCK. because the user specified a service name in
> the annotation and that is *NOT* where the service endpoint shows up.
>
> Thanks,
> dims
>
> Sanka Samaranayake wrote:
> | Hi,
> |
> | We discussed about that in a mailing thread[1] sometime back. Why do you
> | think we should change that? IMO it is desirable to have 
> [service].[port] in
> | the service address since it makes valuable binding information 
> available
> | for request processing at service side.
> |
> | Sanka
> |
> |
> | [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
> |
> | On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
> | 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. It is not good to have
> |> "SampleService.SampleServiceHttpSoap12Endpoint" as the service 
> address. We
> |> did not agree anywhere about this structure. I even created a JIRA [1]
> |>
> |> <wsdl:service name="SampleService">
> |>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
> |> binding="ns:SampleServiceSoap11Binding">
> |>              <soap:address location="
> |> 
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
> |> "/>
> |> </wsdl:port>
> |>
> |> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
> |> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
> |> 
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*"/></wsdl:port><wsdl:port
> |> name="SampleServiceHttpEndpoint"
> |> binding="ns:SampleServiceHttpBinding"><http:address location="
> |> 
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
> |> "/></wsdl:port></wsdl:service>
> |>
> |> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
> |>
> |> Thanks
> |> Deepal
> |>
> |> ---------------------------------------------------------------------
> |> 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
:s/10.100.1.205/localhost

On Fri, May 9, 2008 at 4:16 PM, Sanka Samaranayake <ss...@gmail.com> wrote:

>
> On Fri, May 9, 2008 at 3:56 PM, Davanum Srinivas <da...@gmail.com>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Sanka,
>>
>> #1: I specifically requested in that thread that existing code should work
>> as-is. With this change it did not.
>> Specifically if one had existing clients in another language, they needed
>> to be updated with a fresh endpoint since the
>> same service when deployed in Axis2 1.4 showed up at a different URL.
>
>
>
> Why do you have to update the client with a fresh endpoint when
> http://localhost:8080/axis2/services/Version.Version still is a valid
> endpoint
> as well as
> http://10.100.1.205:8080/axis2/services/Version.VersionHttpSoap12Endpoint.
>
>
> Sanka
>
>
>
>>
>>
>> #2: Because of this change, we had to jump through hoops to pass the TCK.
>> because the user specified a service name in
>> the annotation and that is *NOT* where the service endpoint shows up.
>
>
>>
>> Thanks,
>> dims
>>
>>
>> Sanka Samaranayake wrote:
>> | Hi,
>> |
>> | We discussed about that in a mailing thread[1] sometime back. Why do you
>> | think we should change that? IMO it is desirable to have
>> [service].[port] in
>> | the service address since it makes valuable binding information
>> available
>> | for request processing at service side.
>> |
>> | Sanka
>> |
>> |
>> | [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
>> |
>> | On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
>> | 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. It is not good to have
>> |> "SampleService.SampleServiceHttpSoap12Endpoint" as the service address.
>> We
>> |> did not agree anywhere about this structure. I even created a JIRA [1]
>> |>
>> |> <wsdl:service name="SampleService">
>> |>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
>> |> binding="ns:SampleServiceSoap11Binding">
>> |>              <soap:address location="
>> |>
>> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
>> |> "/>
>> |> </wsdl:port>
>> |>
>> |> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
>> |> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
>> |>
>> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*
>> "/></wsdl:port><wsdl:port
>> |> name="SampleServiceHttpEndpoint"
>> |> binding="ns:SampleServiceHttpBinding"><http:address location="
>> |>
>> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
>> |> "/></wsdl:port></wsdl:service>
>> |>
>> |> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
>> |>
>> |> Thanks
>> |> Deepal
>> |>
>> |> ---------------------------------------------------------------------
>> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> |>
>> |>
>> |
>> |
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (Cygwin)
>>
>> iD8DBQFIJCbMgNg6eWEDv1kRAqryAJ9FbcaKrjGjnG1P1cn2FJvcqgxz7gCgk7YE
>> png0xVXknFFHpQK29Ij1ZU0=
>> =cTor
>> -----END PGP SIGNATURE-----
>>
>>
>> ---------------------------------------------------------------------
>> 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/
>



-- 
Sanka Samaranayake
WSO2 Inc.

http://sankas.blogspot.com/
http://www.wso2.org/

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
On Fri, May 9, 2008 at 3:56 PM, Davanum Srinivas <da...@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sanka,
>
> #1: I specifically requested in that thread that existing code should work
> as-is. With this change it did not.
> Specifically if one had existing clients in another language, they needed
> to be updated with a fresh endpoint since the
> same service when deployed in Axis2 1.4 showed up at a different URL.



Why do you have to update the client with a fresh endpoint when
http://localhost:8080/axis2/services/Version.Version still is a valid
endpoint
as well as
http://10.100.1.205:8080/axis2/services/Version.VersionHttpSoap12Endpoint.


Sanka



>
>
> #2: Because of this change, we had to jump through hoops to pass the TCK.
> because the user specified a service name in
> the annotation and that is *NOT* where the service endpoint shows up.


>
> Thanks,
> dims
>
>
> Sanka Samaranayake wrote:
> | Hi,
> |
> | We discussed about that in a mailing thread[1] sometime back. Why do you
> | think we should change that? IMO it is desirable to have [service].[port]
> in
> | the service address since it makes valuable binding information available
> | for request processing at service side.
> |
> | Sanka
> |
> |
> | [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
> |
> | On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
> | 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. It is not good to have
> |> "SampleService.SampleServiceHttpSoap12Endpoint" as the service address.
> We
> |> did not agree anywhere about this structure. I even created a JIRA [1]
> |>
> |> <wsdl:service name="SampleService">
> |>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
> |> binding="ns:SampleServiceSoap11Binding">
> |>              <soap:address location="
> |>
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
> |> "/>
> |> </wsdl:port>
> |>
> |> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
> |> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
> |>
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*
> "/></wsdl:port><wsdl:port
> |> name="SampleServiceHttpEndpoint"
> |> binding="ns:SampleServiceHttpBinding"><http:address location="
> |>
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
> |> "/></wsdl:port></wsdl:service>
> |>
> |> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
> |>
> |> Thanks
> |> Deepal
> |>
> |> ---------------------------------------------------------------------
> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIJCbMgNg6eWEDv1kRAqryAJ9FbcaKrjGjnG1P1cn2FJvcqgxz7gCgk7YE
> png0xVXknFFHpQK29Ij1ZU0=
> =cTor
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> 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/

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Deepal Jayasinghe <de...@opensource.lk>.
>  Hi Dims,
>
>  I agree with Sanka that this would not effect any existing code. For 
e.g if I can a service called foo it does not really matter if I send a 
request to http://localhost:8080/axis2/services/foo or 
http://localhost:8080/axis2/services/foo.SOAP11Endpoint. Both should 
work. The latter gibes you the option of applying binding level security 
as we are able to dispatch to the endpoint directly.
>
The problem is redundant code , when you send the request you know 
whether you are sending SOAP 1.1 or SOAP 1.2 . Form that you can figure 
out about the SOAP version of the endpoint. So having end point name in 
the address does not make sense to me. And which go beyond what we agree 
about the end point address more than two years back.

-Deepal



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by keith chapman <ke...@gmail.com>.
Hi Dims,

I agree with Sanka that this would not effect any existing code. For e.g if
I can a service called foo it does not really matter if I send a request to
http://localhost:8080/axis2/services/foo or
http://localhost:8080/axis2/services/foo.SOAP11Endpoint. Both should work.
The latter gibes you the option of applying binding level security as we are
able to dispatch to the endpoint directly.

Thanks,
Keith.

On Fri, May 9, 2008 at 3:56 PM, Davanum Srinivas <da...@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sanka,
>
> #1: I specifically requested in that thread that existing code should work
> as-is. With this change it did not.
> Specifically if one had existing clients in another language, they needed
> to be updated with a fresh endpoint since the
> same service when deployed in Axis2 1.4 showed up at a different URL.
>
> #2: Because of this change, we had to jump through hoops to pass the TCK.
> because the user specified a service name in
> the annotation and that is *NOT* where the service endpoint shows up.
>
> Thanks,
> dims
>
>
> Sanka Samaranayake wrote:
> | Hi,
> |
> | We discussed about that in a mailing thread[1] sometime back. Why do you
> | think we should change that? IMO it is desirable to have [service].[port]
> in
> | the service address since it makes valuable binding information available
> | for request processing at service side.
> |
> | Sanka
> |
> |
> | [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
> |
> | On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
> | 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. It is not good to have
> |> "SampleService.SampleServiceHttpSoap12Endpoint" as the service address.
> We
> |> did not agree anywhere about this structure. I even created a JIRA [1]
> |>
> |> <wsdl:service name="SampleService">
> |>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
> |> binding="ns:SampleServiceSoap11Binding">
> |>              <soap:address location="
> |>
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
> |> "/>
> |> </wsdl:port>
> |>
> |> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
> |> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
> |>
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*
> "/></wsdl:port><wsdl:port
> |> name="SampleServiceHttpEndpoint"
> |> binding="ns:SampleServiceHttpBinding"><http:address location="
> |>
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
> |> "/></wsdl:port></wsdl:service>
> |>
> |> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
> |>
> |> Thanks
> |> Deepal
> |>
> |> ---------------------------------------------------------------------
> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIJCbMgNg6eWEDv1kRAqryAJ9FbcaKrjGjnG1P1cn2FJvcqgxz7gCgk7YE
> png0xVXknFFHpQK29Ij1ZU0=
> =cTor
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sanka,

#1: I specifically requested in that thread that existing code should work as-is. With this change it did not.
Specifically if one had existing clients in another language, they needed to be updated with a fresh endpoint since the
same service when deployed in Axis2 1.4 showed up at a different URL.

#2: Because of this change, we had to jump through hoops to pass the TCK. because the user specified a service name in
the annotation and that is *NOT* where the service endpoint shows up.

Thanks,
dims

Sanka Samaranayake wrote:
| Hi,
|
| We discussed about that in a mailing thread[1] sometime back. Why do you
| think we should change that? IMO it is desirable to have [service].[port] in
| the service address since it makes valuable binding information available
| for request processing at service side.
|
| Sanka
|
|
| [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
|
| On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
| 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. It is not good to have
|> "SampleService.SampleServiceHttpSoap12Endpoint" as the service address. We
|> did not agree anywhere about this structure. I even created a JIRA [1]
|>
|> <wsdl:service name="SampleService">
|>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
|> binding="ns:SampleServiceSoap11Binding">
|>              <soap:address location="
|> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
|> "/>
|> </wsdl:port>
|>
|> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
|> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
|> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*"/></wsdl:port><wsdl:port
|> name="SampleServiceHttpEndpoint"
|> binding="ns:SampleServiceHttpBinding"><http:address location="
|> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
|> "/></wsdl:port></wsdl:service>
|>
|> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
|>
|> Thanks
|> Deepal
|>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFIJCbMgNg6eWEDv1kRAqryAJ9FbcaKrjGjnG1P1cn2FJvcqgxz7gCgk7YE
png0xVXknFFHpQK29Ij1ZU0=
=cTor
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
Hi,

We discussed about that in a mailing thread[1] sometime back. Why do you
think we should change that? IMO it is desirable to have [service].[port] in
the service address since it makes valuable binding information available
for request processing at service side.

Sanka


[1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html

On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
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. It is not good to have
> "SampleService.SampleServiceHttpSoap12Endpoint" as the service address. We
> did not agree anywhere about this structure. I even created a JIRA [1]
>
> <wsdl:service name="SampleService">
>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
> binding="ns:SampleServiceSoap11Binding">
>              <soap:address location="
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
> "/>
> </wsdl:port>
>
> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*"/></wsdl:port><wsdl:port
> name="SampleServiceHttpEndpoint"
> binding="ns:SampleServiceHttpBinding"><http:address location="
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
> "/></wsdl:port></wsdl:service>
>
> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
>
> Thanks
> 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/

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
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
>> <am...@gmail.com> wrote:
>>     
>>>
>>> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas  
>>> <da...@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

RE: [Axis2] Generating a wrong port address for POJO deployment

Posted by Tom Jordahl <tj...@adobe.com>.
> 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.  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
> <am...@gmail.com> wrote:
>>
>>
>>
>> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas  
>> <da...@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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
I'm mostly an observer in this one  (and I honestly don't think that the
format of the URL matters as long as it is a valid url). Here are some
thoughts

1. It seems that this change is sensible in terms of endpoint policy
attachment. Some implementations don't do that right now but my guess is
they would have a adopt a similar mechanism to support this feature [at
least I don't see how else can you do this]. If we remove this behavior (for
the sake of simplicity / readability / may be to become 'less whacky' :)) I
suppose the endpoint policy attachment capabilities go down the drain! [
Sanka - What does it mean to support end point policy attachments ? I mean
is it a necessary condition to claim that we support WS-Policy ? { my
understanding is 'yes' but I am not a policy expert }]. Again it does not
make sense to have multiple bindings and not having seperate endpoints to
independently access each of those.

2. If you add an alias endpoint that serves more than one binding (I think
Saminda suggested this) I don't see a problem apart from the redundancy.
IMHO redundancy of the endpoint reference is a small price to pay. The
policies can still be attached to the EPR's and if you guys think that
things may become complex, we can leave these alias EPR's without policies.
That way the policy binding gets activated only if people use the specific
EPR.

3. If the previous suggestion is too much (in terms of user confusion
factor. There will be a number of EPR's listed for codegen and it is very
much likely that we get a complaint about the long list of EPR's!) the next
thing I can think of is to add a parameter to Axis2.xml like
"generateReadableEPRs" so that this behavior can be customized. It is
another debate whether to set this true by default or not but its a good
enough compromise to me.

Ajith

On Wed, May 14, 2008 at 2:37 AM, Sanka Samaranayake <ss...@gmail.com>
wrote:

> Hello Everyone,
>
> Please find my comments inlined.
>
> [1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg26438.html
> [2] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
>
>
>
> Daniel Kulp wrote:
>
>>
>> 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.
>>
>
> We had this feature implemented in Axis2 sometime back[1] and most of the
> concerns raised once the new endpoint format started to show in the
> generated WSDLs. Honestly I'm not bothered whether we use [service].[port]
> or [service]/[port] if the latter looks more appealing. My real concern is
> that if we switch back to previous format we will lose the only viable
> implementation to support multiple policy alternatives at the server-side. I
> would really like to hear another way of doing it if anyone can suggest.
>
>
>  CXF certainly does not and neither does the reference implementation.
>>
>
> Neither does CXF nor reference implementation support policies with
> multiple alternatives at server-side, AFAIK.
>
>    Both of them use a deployment descriptor thing to allow the user to
>> specify the full URL that the service is deployed on.
>>
>
> We should be able to provide a set of parameters in the services.xml which
> supply alias to [service].[port] from which we can have more appealing  URLs
> for the service. I am not a JAXWS expert but can't we do something similar
> for JAXWS services via annotation?
>
>
>> 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).
>>
>
> I'm bit confused. If Jarek had used the endpoint addresses from the
> generated WSDLs, then it would have been a matter of copying and pasting ..
> isn't it? If he didn't use the WSDLs, why couldn't he use the older format
> of service endpoints ?  Or am I missing something ?
>
> Thanks & Regards,
> Sanka
>
>
>
>> Dan
>>
>>
>>
>>
>>>
>>> thanks,
>>> -- dims
>>>
>>> On Mon, May 12, 2008 at 11:56 PM, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas <da...@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 <ss...@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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>>
>
> --
> 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
>
>


-- 
Ajith Ranabahu

Reading, after a certain age, diverts the mind too much from its creative
pursuits. Any man who reads too much and uses his own brain too little falls
into lazy habits of thinking - Albert Einstein

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
Hello Everyone,

Please find my comments inlined.

[1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg26438.html
[2] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html



Daniel Kulp wrote:
>
> 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.

We had this feature implemented in Axis2 sometime back[1] and most of 
the concerns raised once the new endpoint format started to show in the 
generated WSDLs. Honestly I'm not bothered whether we use 
[service].[port] or [service]/[port] if the latter looks more appealing. 
My real concern is that if we switch back to previous format we will 
lose the only viable implementation to support multiple policy 
alternatives at the server-side. I would really like to hear another way 
of doing it if anyone can suggest.


> CXF certainly does not and neither does the reference implementation.

Neither does CXF nor reference implementation support policies with 
multiple alternatives at server-side, AFAIK.

>    Both of them use a deployment descriptor thing to allow the user to 
> specify the full URL that the service is deployed on.

We should be able to provide a set of parameters in the services.xml 
which supply alias to [service].[port] from which we can have more 
appealing  URLs for the service. I am not a JAXWS expert but can't we do 
something similar for JAXWS services via annotation?

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

I'm bit confused. If Jarek had used the endpoint addresses from the 
generated WSDLs, then it would have been a matter of copying and pasting 
.. isn't it? If he didn't use the WSDLs, why couldn't he use the older 
format of service endpoints ?  Or am I missing something ?

Thanks & Regards,
Sanka

>
> Dan
>
>
>
>>
>>
>> thanks,
>> -- dims
>>
>> On Mon, May 12, 2008 at 11:56 PM, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas 
>>> <da...@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 <ss...@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
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> 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
>
>
>


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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Daniel Kulp <dk...@apache.org>.
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
> <am...@gmail.com> wrote:
>>
>>
>>
>> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas  
>> <da...@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.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
>>>
>>>
>>
>>
>>
>> --
>> 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Davanum Srinivas <da...@gmail.com>.
Amila,

I was talking about moving JAXWS services and clients across
implementations. Not on the wire interop. Sorry it was not clearer.

thanks,
-- dims

On Mon, May 12, 2008 at 11:56 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
>
> On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas <da...@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 <ss...@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
> >
> >
>
>
>
> --
> 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Amila Suriarachchi <am...@gmail.com>.
On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas <da...@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 <ss...@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
>
>


-- 
Amila Suriarachchi,
WSO2 Inc.

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
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 
> <ma...@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 <ma...@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 <ma...@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 <ma...@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
>     <ma...@ws.apache.org>
>     > > > > For additional commands, e-mail:
>     axis-dev-help@ws.apache.org <ma...@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
>     <ma...@ws.apache.org>
>     > > >  For additional commands, e-mail:
>     axis-dev-help@ws.apache.org <ma...@ws.apache.org>
>     > > >
>     > > >
>     > >
>     > >
>     > >
>     > > --
>     > > Davanum Srinivas :: http://davanum.wordpress.com
>     > >
>     > >
>     > >
>     > >
>     > >
>     ---------------------------------------------------------------------
>     > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     > > For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <ma...@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
>     <ma...@ws.apache.org>
>     For additional commands, e-mail: axis-dev-help@ws.apache.org
>     <ma...@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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Saminda Abeyruwan <sa...@gmail.com>.
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 <da...@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 <ke...@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 <da...@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 <ss...@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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Davanum Srinivas <da...@gmail.com>.
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 <ke...@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 <da...@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 <ss...@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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by keith chapman <ke...@gmail.com>.
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 <da...@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 <ss...@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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
Hello Everyone,

Please find my comments inlined.


Davanum Srinivas wrote:
> Sanka,
>
> for one thing, i haven't seen anyone else use it. 

I am bit confused here. Clients should use the endpoint address which we 
advertise through the WSDL .. shouldn't they ? In other words new client 
applications will use the newer format of endpoint address of a server 
as long as it is the endpoint address exposed through the WSDL from 
which they generated or coded the client applications. The endpoint 
address or its format,  IMO its not something that the coders can 
negotiate when they write their client applications using the WSDL of a 
service. They should stick to endpoint address that is in the WSDL as 
long as it is a valid URL and the content or the format should be 
immaterial.

However we are not enforcing the newer format because we want to 
preserve backward compatibilities. We are only enforcing it for newer 
client applications by having that format in  the generated WSDLs.


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

I agree with you completely on the fact that we should not make life 
miserable for  service authors. But my worry is that if we switch back 
to the order format we will lose the only feasible way of implementing 
support for multiple WS Policy alternatives in Axis2 server and also the 
ability do prior evaluation of request messages (i.e. Sending a SOAP 1.2 
request to SOAP 1.1 binding endpoint scenario)

So can we have a alternative solution like the one Keith mention, by 
having a set of parameters in services.xml as the aliases to service 
endpoint address if required  I am not a JAXWS expert but can't we 
service parameters like them in the annotation ?

Thanks & Regards,
Sanka
> thanks,
> dims
>
> On Mon, May 12, 2008 at 7:05 AM, Sanka Samaranayake <ss...@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
>>
>>
>>     
>
>
>
>   


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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Davanum Srinivas <da...@gmail.com>.
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 <ss...@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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Deepal jayasinghe <de...@gmail.com>.
>>>
>>>
>>>     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.
> 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 , I 
do not mind sending that as some where else.
>
> 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Sanka Samaranayake <ss...@gmail.com>.
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 <deepalk@gmail.com 
>> <ma...@gmail.com>> 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 
behavior.

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


Thanks & Regards,
Sanka







[1] http://www.mail-archive.com/axis-dev@ws.apache.org/msg40047.html
>
>>
>>     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: 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

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Hi Deepal,
>
> See comments inline
>
> On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <deepalk@gmail.com 
> <ma...@gmail.com>> 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.
>
>     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.
 
>
>     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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org

Re: [Axis2] Generating a wrong port address for POJO deployment

Posted by keith chapman <ke...@gmail.com>.
Hi Deepal,

See comments inline

On Fri, May 9, 2008 at 11:49 AM, Deepal jayasinghe <de...@gmail.com>
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.

It is not good to have "SampleService.SampleServiceHttpSoap12Endpoint" as
> the service address.


Y? I dont see any reason y its not good.

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.

Thanks,
Keith.

> I even created a JIRA [1]
>
> <wsdl:service name="SampleService">
>   <wsdl:port name="SampleServiceHttpSoap11Endpoint"
> binding="ns:SampleServiceSoap11Binding">
>              <soap:address location="
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap11Endpoint
> "/>
> </wsdl:port>
>
> <wsdl:port name="SampleServiceHttpSoap12Endpoint"
> binding="ns:SampleServiceSoap12Binding"><soap12:address location="*
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpSoap12Endpoint*"/></wsdl:port><wsdl:port
> name="SampleServiceHttpEndpoint"
> binding="ns:SampleServiceHttpBinding"><http:address location="
> http://10.100.1.132:8080/axis2/services/SampleService.SampleServiceHttpEndpoint
> "/></wsdl:port></wsdl:service>
>
> [1] : https://issues.apache.org/jira/browse/AXIS2-3794
>
> Thanks
> Deepal
>
> ---------------------------------------------------------------------
> 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