Ant has just mentioned two important aspects of a decent registry: multi-dimension scoping and NameSpace aggregation. I forgot to mention the registry I previously worked on supports them too, thank Ant.
Specifically, "keyed by application and the WSDL location" mentions scoping by application/ClassLoaders *and* scoping by (WSDL) location. application/ClassLoaders scoping and location scoping are *not* in parallel, e.g. one WSDL/XSD file could be shared by both WAR and EJB, or both app1 and app2. By multi-dimension, I mean the loaded symbol may need to be only one instance, e.g. "Quote" type/message from WSDL file, it's especially important to types due to instanceof and isSuperType checking (we know how painful that one .class file ends up more than one copies in memory) NameSpace aggregation is also important. e.g. WSDL file 1 may have defined NameSpace "tns" in location 1 scope, and WSDL 2 defines the same "tns" in location 2 scope, and both WSDL 1 and 2 are accessible from application scope, then a NameSpace aggregation *view* is necessary for queries from the application scope. I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. On 8/22/06, ant elder <[EMAIL PROTECTED]> wrote:
I agree a registry would be good, we need some sort of cache or registry otherwise you need to specify the wsdlLocation on every interface.wsdl and binding.ws which is quite ugly. But we had a simple registry in M1 and that caused problems with namespace reuse. We definitely need to handle the reuse of namespaces across applications, and also maybe the reuse of namespaces within an application. To handle namespace reuse within an application you need the option to specify a wsdlLocation everywhere interface.wsdl or binding.ws is used, to handle reuse across applications the registry needs to have some sort of application scope. I really like the suggestion that WSDL be automatically discovered anywhere within the application directory structure. So for now, to get the current code working without requiring wsdlLocation be used everywhere and until the spec group do something, could we have a simple registry that finds WSDL anywhere within applications and its keyed by application and the WSDL location. Then extensions could locate WSDL objects based on the name, eg portType name, DeploymentContext and an optional wsdlLocation? ...ant On 8/22/06, Jim Marino < [EMAIL PROTECTED]> wrote: > > I like Raymond's and Yang's approach and perhaps someone is willing > to propose the standardized way to the spec group? Sebastien, since > you had a bunch of other issues raised against the spec group, do you > want to do that? > > Jim > > On Aug 22, 2006, at 10:36 AM, Raymond Feng wrote: > > > I'm leaning the following: > > > > 1) Have a well-defined default scheme. I agree with Sebastien that > > the SCA spec should spell it out. > > 2) Allow extensibility to plug in new schemes (for example, > > "my:path") if the host platform desires. > > > > Thanks, > > Raymond > > > > ----- Original Message ----- From: "Jean-Sebastien Delfino" > > <[EMAIL PROTECTED] > > > To: <tuscany-dev@ws.apache.org> > > Sent: Tuesday, August 22, 2006 10:21 AM > > Subject: Re: Auto discovering WSDL > > > > > >> Raymond Feng wrote: > >>> Hi, > >>> > >>> I would suggest that we define a system service to provide the > >>> artifact resolving strategy. Then we can supply a default > >>> implementation, for example, resolve the wsdlLocation based on > >>> classpath. The embedded can choose to replace it with its own > >>> more sophisticated resolver (for exmaple, using META-INF/wsdl, > >>> scanning directory, or querying a WSDL repository). > >>> > >>> Thanks, > >>> Raymond > >>> > >> > >> Making things pluggable to support all kinds of different schemes > >> is interesting, but will that break application portability > >> between different runtimes? > >> > >> With my application developer hat on, I would expect the SCA > >> specification to tell me where I'm supposed to write my WSDL and > >> XSD files and how references from SCDL to WSDL get resolved. > >> > >> Any thoughts? > >> > >> -- > >> Jean-Sebastien > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- Yang ZHONG
