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 <[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.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: [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]







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

Reply via email to