Exactly, locating, loading, caching and refreshing will all be loosely coupled *and* extensible.
On 8/23/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
As Yang has pointed out, there are probably four things we can do in this area: locating, loading, caching and refreshing. We should not mix the responsibilities of locating/loading with caching. To satisfy your use case described below (wsdlLocation attribute becomes optional), we actually only need some kind of resolver chain to resolve wsdl, a cache is not needed here. The first resolver in the chain should resolve wsdl using wsdlLocation specified in scdl, if the first resolved failed (e.g., because the wsdllocation is null), then the second resolver should try to resolve wsdl from a default location, and so on. The implementation Yang proposed might be different, but the principle should be same. The WSDL registry should only responsible for caching wsdls and provide query APIs to query against cache. How WSDL registry loads a wsdl if that wsdl is not in cache yet should be a call delegated to the resource resolver service. The benefit of this separation is that we can start with sth simple and small, i.e., in the component loader, initially we can only use the resource resolver service without cache. Cheers, Jervis -----Original Message----- From: ant elder [mailto:[EMAIL PROTECTED] Sent: 2006?8?23? 23:42 To: [email protected] Subject: Re: Auto discovering WSDL On 8/22/06, Yang ZHONG <[EMAIL PROTECTED]> wrote: <snip/> I have quite some experience working on such registry, I'd like to > contribute if it's the way Tuscany wants to go. How about we take Yang up on this offer. We could have a WSDL registry as an optional system service, and define the wsdlLocation attribute on both the interface.wsdl and binding.ws elements. If you don't configure your system with a WSDL registry then it will be null and the wsdlLocation attribute must be specified, if you do configure a WSDL registry in your system then the wsdlLocation attribute becomes optional and if you leave it out the registry is used to locate the wsdl. The registry could have configurable wsdl locating strategies such as looking in a specific folder or scanning all folders or something completely different. This seems like it gives everyone what they want. Yang could have a go at coming up with a registry impl that works and doesn't cause memory leaks and works across applications etc. I'd be happy to help, and I'd change the Axis2 binding and JavaScript container to use the registry if we can get it to work. Yang sounds like he has lots of experience with this type of thing, and has volunteered, so it would be good to encourage a new contributor. ...ant --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Yang ZHONG
