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:[EMAIL PROTECTED]
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
<[EMAIL PROTECTED]> wrote:
On Mon, May 12, 2008 at 5:48 PM, Davanum Srinivas
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Sanka Samaranayake
WSO2 Inc.
http://sankas.blogspot.com/
http://www.wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Amila Suriarachchi,
WSO2 Inc.
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Sanka Samaranayake
WSO2 Inc.
http://sankas.blogspot.com/
http://www.wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
