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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[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. 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] > > > > > > > > > > > > > > -- > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org
