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: <[email protected]>
>> > > 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: tuscany-dev-
[EMAIL PROTECTED]
>> > >
>> > >
>> > >
>>
---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: tuscany-dev-
[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]
