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