There is also the practice that meta data is being added to WSDL (i.e. xmlns:sdojava="commonj.sdo/java .. sdojava:package="foobar.fake.com") This *may* be unique to client or server. I don't like this practice but I suspect will see more in the future.
Jeremy Boynes wrote: > I'm not sure I fully follow but as I'm making changes in this area > (switching over to using a central WSDLDefinitionRegistry) I'll bite. > > What I think you're suggesting is that the registry should not cache > WSDL by location but by target namespace and that it should merge the > various definitions it loads into one cached entry. In other words, it > doesn't matter how many files we parse, all the information gets merged > together and we return the union. Is that right? > > The thing that would concern me about that approach is that I am not > sure how strict people are about not re-using namespaces in incompatible > ways. I realise the intention is to use them to uniquely identify sets > of definitions but I can't help but fear that in many cases the reality > is they get reused. If that happens then I would be afraid the merging > approach may lead to unexpected problems. Does anyone have more > information here? > > Perhaps we can have a way in which namespaces can be tagged as "unique" > or "reused" and in the first we support merging the definitions together > into one entry but in the second we key solely off the physical location. > > -- > Jeremy > > Scott Kurz wrote: >> Hi, >> >> This is my first post. I work on SCA for IBM. >> >> I found an issue (which I mentioned on the phone to Sebastien today). I'm >> not sure if it was a purposeful or accidental design decision, so before >> opening up a JIRA I thought I'd write this up. >> >> In short.. do you really want to cache the URLs along with the WSDL >> Definitions for both EntryPoints and ExternalServices (for WS binding) >> together? >> >> In detail: >> >> When invoking over a WS binding, it might be nice to say that, although both >> client and server have a copy of the WSDL, that only the client URL matters, >> but not the server's. >> >> I'm talking about the <wsdlsoap:address> tag, for example in sample >> HelloWorldWSClient as: >> >> <wsdlsoap:address location=" >> http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService"/> >> >> As long as the client is invoked from a separate J2SE environment, you don't >> have to match your server-side WSDL's <wsdlsoap:address> URL with the actual >> deployment location and you can set the server-side WSDL to a URL that can't >> receive HTTP requests. >> >> However, when you call the same service over an external service WS binding >> from a service co-hosted in the same Tomcat server as the module with the WS >> Binding entry point, you have a new issue. You generally must keep three >> pieces of data in synch: client URL, server URL, and deployment URL. >> >> Unless you are lucky enough for the client module to be started up first. >> In that case the server URL no longer matters. Generally speaking, I >> don't know when the order of module loading is allowed to matter, but I >> wonder if this is unintended. >> >> The low-level reason is the definitionsByNamespace map used by the method >> org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions >> , >> which maps namespaces to WSDL Definitions. >> >> If the map and WSDL Definition processing were refactored somehow to save >> the common portion of the Definition but to only cache the URL portion for >> ExternalServices, not for EntryPoints, (or something like that), we could >> eliminate the extra piece of redundant data. >> >> Thanks, >> Scott Kurz >> > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
