On Tue, May 19, 2009 at 11:29, Andrew Clegg <[email protected]> wrote: > Nope... It's analogous to an interface with different implementations > in an OO language. A client written to the common WSDL spec can talk > to any of the services just by changing endpoints. And new services > can be added with minimal extra work.
> We *could* put them in different WSDL files, and maintain these by > hand, but that would feel like introducing duplication... And going by > what WSDL file a service is described in, seems like a hacky way to > identify/describe that service and its operations. You could, and you could have the data types in common XSD files that are imported. But we'll investigate this further on what would be a better way to >> We can argue if it's good design or not to have several port types >> with the same operation name inside, as I guess this could be >> troublesome for many other clients as well. > > Hasn't been a problem with any we've tried, although we're only > claiming to support WS-I BP-compliant tools. I think the EMBRACE > Registry gets a little confused, but that's only a stopgap. > >>> Is this intentional? If so, it seems a bit strange -- multiple-service >>> WSDLs are schema-valid, and compliant with the WS-I interop >>> guidelines. And the URL of a WSDL file is surely an entirely arbitrary >>> construct that doesn't really describe what's in it. The URI of each >>> service in the WSDL would be a better discriminator, right? >> >> No, the binding address would be much worse as a discriminator, > > I didn't mean that but you've seen my next mail with the correction by now :-) > >> I think a good discriminator would be wsdl location, port type and >> operation name. > > Using the WSDL location still seems odd. It implies that a service > imported from a locally-cached WSDL is a different entity from the > same service described in the same WSDL read from a remote URL. Well - all the data types etc. are defined by the WSDL - so there could be two WSDL specifications (an older and newer version?) that share the same endpoint but with different data types - in which case it would be quite important on constructing data types etc. which of them to use. Also we do need to store the WSDL location anyway if we are to be able to find information about parameters and data types on re-loading of the workflow. The two WSDLs *are* different - the one on the web server could change later. If we don't store the WSDL location we would have to store the whole WSDL specification, and then run into various issues on what happens when it no longer matches. (In a way we already do this with the XML splitters - not sure exactly why - so my argument here is not very strong!) If a user edits a local WSDL file and add it to Taverna it would no longer be 'the same' as the server one either. I think it is quite seldom that a server WSDL changes with say a new binding address, where the old binding address continues to work. Even if the WSDL file location was not used as an identifier it should be saved so it could later be re-read. Remember - The main goal as you know is to be able to run the workflow. :-) The workflow would run nicely no matter which URL of the WSDL is given - but of course a file:/// reference would not be very shareable. A related question is what Taverna should do if there are several matching bindings for the same service/port type - should we try each one in order (like the Failover mechanism)? Should the workflow designer be allowed to control which one is used - possibly even typing in his own? > I reported this to them earlier too, but I think it's different as it > has a problem with another one of ours with only a single service > element. Yeah, there could be several problems there, but as far as I've seen BioCatalogue have not exposed several data types and service bindings yet. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ taverna-hackers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/taverna-hackers Developers Guide: http://www.mygrid.org.uk/usermanual1.7/dev_guide.html FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq
