Re: Auto discovering WSDL

[Jim Marino]

On Aug 22, 2006, at 2:46 PM, Yang ZHONG wrote:
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.

Yea it sure sounds like it. I'm wondering that this should not be a  
system component by something scoped within the application composite  
as you mentioned classloaders are referenced. We could potentially do  
something with the property extension mechanism. I'm a little behind  
so if you can figure out how the keying could work, I could offer  
some suggestions on how to plug the registry into the runtime.


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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]