You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/08/22 16:34:32 UTC
Auto discovering WSDL
In a C++ thread [1] Jean-Sebastien talked about having WSDL files
automatically picked up by the C++ runtime instead of having to specify a
wsdlLocation attribute somewhere in the SCDL. I'd really like the Java SCA
runtime to also do this, do people agree or anyone have any concerns with
that?
Something like having a specific folder like META-INF/wsdl and in there any
resources ending with .wsdl get automatically loaded into the WSDL
registry. And I guess this could be implemented with a Builder that gets
run when a composite is loaded.
Any comments or suggestions?
...ant
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06221.htm
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 22, 2006, at 7:34 AM, ant elder wrote:
> In a C++ thread [1] Jean-Sebastien talked about having WSDL files
> automatically picked up by the C++ runtime instead of having to
> specify a
> wsdlLocation attribute somewhere in the SCDL. I'd really like the
> Java SCA
> runtime to also do this, do people agree or anyone have any
> concerns with
> that?
I believe Jeremy had concerns with that. I mention that since he is
out the next few days.
>
> Something like having a specific folder like META-INF/wsdl and in
> there any
> resources ending with .wsdl get automatically loaded into the WSDL
> registry. And I guess this could be implemented with a Builder
> that gets
> run when a composite is loaded.
>
I'm not sure this would be a builder. Probably a system service.
Also, does this bring up the issue of namespace clashes and whether
to cache at all? Are we going to attempt to handle the reuse of
namespaces across applications? If so, we'll need a better solution
than what we had in M1 (caching by classloader) as that had memory
leaks.
Jim
> Any comments or suggestions?
>
> ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> msg06221.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> In a C++ thread [1] Jean-Sebastien talked about having WSDL files
> automatically picked up by the C++ runtime instead of having to specify a
> wsdlLocation attribute somewhere in the SCDL. I'd really like the Java
> SCA
> runtime to also do this, do people agree or anyone have any concerns with
> that?
>
> Something like having a specific folder like META-INF/wsdl and in
> there any
> resources ending with .wsdl get automatically loaded into the WSDL
> registry. And I guess this could be implemented with a Builder that gets
> run when a composite is loaded.
>
> Any comments or suggestions?
>
> ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06221.htm
>
Yes, I suggest to allow the application developer to place WSDL files
wherever he wants under his application instead of forcing a specifc
META-INF/wsdl folder. Typically application developers will want to put
related Cpp, Java, Wsdl and Xsd files together in a structure that makes
sense to them as they are developing their application instead of
spreading them across directories imposed by a runtime.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Simon Laws <si...@googlemail.com>.
On 8/22/06, ant elder <an...@gmail.com> wrote:
>
> In a C++ thread [1] Jean-Sebastien talked about having WSDL files
> automatically picked up by the C++ runtime instead of having to specify a
> wsdlLocation attribute somewhere in the SCDL. I'd really like the Java SCA
> runtime to also do this, do people agree or anyone have any concerns with
> that?
>
> Something like having a specific folder like META-INF/wsdl and in there
> any
> resources ending with .wsdl get automatically loaded into the WSDL
> registry. And I guess this could be implemented with a Builder that gets
> run when a composite is loaded.
>
> Any comments or suggestions?
>
> ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06221.htm
Hi Ant
My only concern would be versioning, i.e. are we sure we can auto-load WSDL
and make sure we are applying the right versions to the right services.
Maybe this is a justification for doing it, i.e. if auto-loading is adopted
we can point out redefinitions and name clashes within wsdl and xsd for a
composite.
Regards
Simon
Re: Auto discovering WSDL
Posted by Yang ZHONG <le...@gmail.com>.
Some product I previously worked on has such registry, furthermore, it loads
resources on demand instead of loading everything at beginning to improve
performance, not every execution path needs *all* resources after all.
The way it works is
1. client queries the registry with some criterias such as Symbol Space
(type vs. message vs. interface/portType ...), NameSpace and symbol name
2. the registry locates corresponding resources (resource indexing and
caching are also done for future queries)
3. the registry loads the resources and returns the result(s) meeting the
query (symbol indexing and caching are also done for future queries)
4. another query involves cached resource
5. the registry reloads *if* the resource has been updated
In a word, the registry automatically locates, loads and refreshes resources
on demand. It makes simplest client Programming Model and loosely couples
query, locating, loading and refreshing. The refreshing helps a lot in
authoring/debuging environments where resources may be updated from time to
time.
The locating, loading and update checking are all extensible.
If any one is interested in such service, I sure can contribute.
On 8/22/06, Raymond Feng <en...@gmail.com> 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
>
> ----- Original Message -----
> From: "ant elder" <an...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, August 22, 2006 7:34 AM
> Subject: Auto discovering WSDL
>
>
> > In a C++ thread [1] Jean-Sebastien talked about having WSDL files
> > automatically picked up by the C++ runtime instead of having to specify
> a
> > wsdlLocation attribute somewhere in the SCDL. I'd really like the Java
> SCA
> > runtime to also do this, do people agree or anyone have any concerns
> with
> > that?
> >
> > Something like having a specific folder like META-INF/wsdl and in there
> > any
> > resources ending with .wsdl get automatically loaded into the WSDL
> > registry. And I guess this could be implemented with a Builder that
> gets
> > run when a composite is loaded.
> >
> > Any comments or suggestions?
> >
> > ...ant
> >
> > [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06221.htm
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 22, 2006, at 4:53 PM, Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
>> <snip/>
>>
>>> I really like the suggestion that WSDL be automatically discovered
>>> > anywhere
>>> > within the application directory structure.
>>> I pretty much have the same concerns as mentioned by Raymond on
>>> this.
>>
>>
>> I'm confused by this thread, you're concerns are the same as
>> Raymonds,
>> Raymond says Sebastien points out the problems, but AFAICT
>> Sebastien likes
>> the auto discovery approach and I think this is how the C++ guys
>> are going
>> to implemented it. What alternative approaches do you like - must use
>> wsdlLocation on every interface.wsdl and binding.ws? Only auto
>> discover in a
>> specific folder such as META-INF/wsdl? Re-instate import.wsdl?
>> Something
>> else ? I'd just like to get something going, especially while Yang is
>> sounding so keen to help out.
>>
>> ...ant
>>
>
> Just to confirm what Ant is saying, I think that the application
> developer should be free to place WSDLs and XSDs wherever it makes
> sense for him under the structure where he installs his other
> development artifacts. With my application developer hat on, I
> don't like to have to write an extra config file or extra XML
> elements in SCDL to list the WSDLs and or XSDs that I just put
> there, my view is that in 2006 a modern runtime should be able to
> find my WSDL files for me without any hand holding. Whether this is
> the adopted scheme or not I think the SCA specification should
> define the packaging structure and how references to WSDL from SCDL
> get resolved (just using qnames or locations as well? per
> composite? per packaging / installable unit? or per system...).
Yea I think this is important for the spec to do. I'd prefer to have
a default location where WSDLs are placed to avoid picking random
ones up from the classpath.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
> <snip/>
>
>> I really like the suggestion that WSDL be automatically discovered
>> > anywhere
>> > within the application directory structure.
>> I pretty much have the same concerns as mentioned by Raymond on this.
>
>
> I'm confused by this thread, you're concerns are the same as Raymonds,
> Raymond says Sebastien points out the problems, but AFAICT Sebastien
> likes
> the auto discovery approach and I think this is how the C++ guys are
> going
> to implemented it. What alternative approaches do you like - must use
> wsdlLocation on every interface.wsdl and binding.ws? Only auto
> discover in a
> specific folder such as META-INF/wsdl? Re-instate import.wsdl? Something
> else ? I'd just like to get something going, especially while Yang is
> sounding so keen to help out.
>
> ...ant
>
Just to confirm what Ant is saying, I think that the application
developer should be free to place WSDLs and XSDs wherever it makes sense
for him under the structure where he installs his other development
artifacts. With my application developer hat on, I don't like to have to
write an extra config file or extra XML elements in SCDL to list the
WSDLs and or XSDs that I just put there, my view is that in 2006 a
modern runtime should be able to find my WSDL files for me without any
hand holding. Whether this is the adopted scheme or not I think the SCA
specification should define the packaging structure and how references
to WSDL from SCDL get resolved (just using qnames or locations as well?
per composite? per packaging / installable unit? or per system...).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Rick <cr...@gmail.com>.
Something else that just occurred to me with regard to this --- error reporting.
If wsdl is cached and could be located in different locations and that may even
be changed by replacing some pluggable system component, when errors arise will
there be a means to specifically state which WSDL participated in that error? I
could see an very large deployment this could be a real pain point if wsdl not
being referenced where the use *thinks* it is.
Rick wrote:
> I can see in having a default location or via searching for wsdl in
> resources, but I'm still in favor of have the ability to give specific
> location control in the scdl.
>
>
> Does it seem reasonable the actual location can/should be specified by
> url? Not on the local machine itself? Could it be generated? change in
> time to change an endpoint address ? If yes will a caching scheme take
> that into account?
>
> I'm assuming caching will be hierarchical with each classloader on each
> composite having its own cache and delegating if not found to the
> containing composite to finally a global one. If I'm understanding
> correctly the aspects of this I think this is where we went wrong in M1
> (global across all webapps). If this is the case I think at each level
> it would be nice to have a scdl parameter to block the delegating to the
> next level.
>
> Generally I like the idea of making it simple by having less to specify,
> but not if it's at the expense of not having control when it's needed.
>
>
> Jim Marino wrote:
>>
>> On Aug 22, 2006, at 4:31 PM, ant elder wrote:
>>
>>> On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
>>> <snip/>
>>>
>>>> I really like the suggestion that WSDL be automatically discovered
>>>> > anywhere
>>>> > within the application directory structure.
>>>> I pretty much have the same concerns as mentioned by Raymond on this.
>>>
>>>
>>> I'm confused by this thread, you're concerns are the same as Raymonds,
>>> Raymond says Sebastien points out the problems, but AFAICT Sebastien
>>> likes
>> Yea actually I thought Sebastien liked it some I'm a bit confused too.
>> Outside of that, I don't like when things are magically picked up on a
>> classpath. For example, fragments caused all sorts of problems.
>>> the auto discovery approach and I think this is how the C++ guys are
>>> going
>>> to implemented it. What alternative approaches do you like - must use
>>> wsdlLocation on every interface.wsdl and binding.ws?
>> I think this was Jeremy's preference. I'm not the hard line
>>> Only auto discover in a
>>> specific folder such as META-INF/wsdl?
>> I prefer a specific folder as well as potentially reinstating
>> import.wsdl since that may be more portable.
>>> Re-instate import.wsdl? Something
>>> else ? I'd just like to get something going, especially while Yang is
>>> sounding so keen to help out.
>>>
>>> ...ant
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Rick <cr...@gmail.com>.
I can see in having a default location or via searching for wsdl in resources,
but I'm still in favor of have the ability to give specific location control in
the scdl.
Does it seem reasonable the actual location can/should be specified by url? Not
on the local machine itself? Could it be generated? change in time to change an
endpoint address ? If yes will a caching scheme take that into account?
I'm assuming caching will be hierarchical with each classloader on each
composite having its own cache and delegating if not found to the containing
composite to finally a global one. If I'm understanding correctly the aspects
of this I think this is where we went wrong in M1 (global across all webapps).
If this is the case I think at each level it would be nice to have a scdl
parameter to block the delegating to the next level.
Generally I like the idea of making it simple by having less to specify, but not
if it's at the expense of not having control when it's needed.
Jim Marino wrote:
>
> On Aug 22, 2006, at 4:31 PM, ant elder wrote:
>
>> On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
>> <snip/>
>>
>>> I really like the suggestion that WSDL be automatically discovered
>>> > anywhere
>>> > within the application directory structure.
>>> I pretty much have the same concerns as mentioned by Raymond on this.
>>
>>
>> I'm confused by this thread, you're concerns are the same as Raymonds,
>> Raymond says Sebastien points out the problems, but AFAICT Sebastien
>> likes
> Yea actually I thought Sebastien liked it some I'm a bit confused too.
> Outside of that, I don't like when things are magically picked up on a
> classpath. For example, fragments caused all sorts of problems.
>> the auto discovery approach and I think this is how the C++ guys are
>> going
>> to implemented it. What alternative approaches do you like - must use
>> wsdlLocation on every interface.wsdl and binding.ws?
> I think this was Jeremy's preference. I'm not the hard line
>> Only auto discover in a
>> specific folder such as META-INF/wsdl?
> I prefer a specific folder as well as potentially reinstating
> import.wsdl since that may be more portable.
>> Re-instate import.wsdl? Something
>> else ? I'd just like to get something going, especially while Yang is
>> sounding so keen to help out.
>>
>> ...ant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 22, 2006, at 4:31 PM, ant elder wrote:
> On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
> <snip/>
>
>> I really like the suggestion that WSDL be automatically discovered
>> > anywhere
>> > within the application directory structure.
>> I pretty much have the same concerns as mentioned by Raymond on this.
>
>
> I'm confused by this thread, you're concerns are the same as Raymonds,
> Raymond says Sebastien points out the problems, but AFAICT
> Sebastien likes
Yea actually I thought Sebastien liked it some I'm a bit confused
too. Outside of that, I don't like when things are magically picked
up on a classpath. For example, fragments caused all sorts of problems.
> the auto discovery approach and I think this is how the C++ guys
> are going
> to implemented it. What alternative approaches do you like - must use
> wsdlLocation on every interface.wsdl and binding.ws?
I think this was Jeremy's preference. I'm not the hard line
> Only auto discover in a
> specific folder such as META-INF/wsdl?
I prefer a specific folder as well as potentially reinstating
import.wsdl since that may be more portable.
> Re-instate import.wsdl? Something
> else ? I'd just like to get something going, especially while Yang is
> sounding so keen to help out.
>
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by ant elder <an...@gmail.com>.
On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
<snip/>
> I really like the suggestion that WSDL be automatically discovered
> > anywhere
> > within the application directory structure.
> I pretty much have the same concerns as mentioned by Raymond on this.
I'm confused by this thread, you're concerns are the same as Raymonds,
Raymond says Sebastien points out the problems, but AFAICT Sebastien likes
the auto discovery approach and I think this is how the C++ guys are going
to implemented it. What alternative approaches do you like - must use
wsdlLocation on every interface.wsdl and binding.ws? Only auto discover in a
specific folder such as META-INF/wsdl? Re-instate import.wsdl? Something
else ? I'd just like to get something going, especially while Yang is
sounding so keen to help out.
...ant
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 22, 2006, at 1:39 PM, ant elder 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.
I pretty much have the same concerns as mentioned by Raymond on this.
>
> 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
If it is keyed by composite or anything that references a
classloader, we will have a memory leak. We also probably shouldn't
have the system service hold a key to anything that needs to be
dereferenced when a composite is removed. Thinking about this, we
probably want to use the property extensibility mechanism Jeremy was
putting in place which would scope things within a composite.
> 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 <ji...@gmail.com> 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"
>> > <js...@apache.org>
>> > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 23, 2006, at 8:41 AM, ant elder wrote:
> On 8/22/06, Yang ZHONG <le...@gmail.com> 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 sounds like a a good idea. We just need to be careful about back
references to keys. If you need help with the system service part,
let me know.
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Yang ZHONG <le...@gmail.com>.
I personally like Ant's optional wsdlLocation attribute idea, it's flexible
enough to address many requirements, and just like what XSD/WSDL
specification has done - optional schemaLocation attribute: if present,
option to use the specified location; if not present, to be resolved by
loader (registry, repository, whatever)
On 8/23/06, ant elder <an...@gmail.com> wrote:
>
> On 8/22/06, Yang ZHONG <le...@gmail.com> 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
>
>
--
Yang ZHONG
Re: Auto discovering WSDL
Posted by ant elder <an...@gmail.com>.
On 8/22/06, Yang ZHONG <le...@gmail.com> 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
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
As you mentioned WeakReferences work as long as values do not contain
pointers back to the classloader, which I have found is difficult to
avoid and error prone. I'd prefer to see if we could avoid keying on
classloader. I also think having to flush a system service may be
more complicated than just treating it within the context of a
composite.
Jim
On Aug 22, 2006, at 4:58 PM, Yang ZHONG wrote:
> Keying can be done by WeakReference or SoftReference, as long as no
> strong
> reference from value to key (value sure can have weak/soft
> reference to
> key).
> The registry I worked on, Eclipse Modeling Framework, and many
> other Java
> caches, use Java Reference.
>
>
> On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> 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 <an...@gmail.com> 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 < jim.marino@gmail.com> 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"
>> >> > > <jsdelfino@apache.org >
>> >> > > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> >> > >> For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> > >
>> >> > >
>> >> > >
>> >>
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > > For additional commands, e-mail: tuscany-dev-
>> help@ws.apache.org
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Yang ZHONG
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Yang ZHONG <le...@gmail.com>.
Keying can be done by WeakReference or SoftReference, as long as no strong
reference from value to key (value sure can have weak/soft reference to
key).
The registry I worked on, Eclipse Modeling Framework, and many other Java
caches, use Java Reference.
On 8/22/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> 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 <an...@gmail.com> 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 < jim.marino@gmail.com> 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"
> >> > > <jsdelfino@apache.org >
> >> > > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> >> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > >
> >> > >
> >> > >
> >> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > >
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >>
> >
> >
> > --
> >
> > Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Auto discovering WSDL
Posted by Jim Marino <jm...@myromatours.com>.
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 <an...@gmail.com> 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 < jim.marino@gmail.com> 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"
>> > > <jsdelfino@apache.org >
>> > > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Yang ZHONG <le...@gmail.com>.
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 <an...@gmail.com> 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 < jim.marino@gmail.com> 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"
> > > <jsdelfino@apache.org >
> > > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
--
Yang ZHONG
Re: Auto discovering WSDL
Posted by Raymond Feng <en...@gmail.com>.
I prefer not to blindly discover WSDLs in the application archive without
any control expressed by the application developer. By my experience, this
is a big trap and Sebastien has pointed out a bunch of issues with that
proposal. I do agree in some cases, it should be possible to omit the
"wsdlLocation" if it can be resolved by some means. An "import.wsdl" at the
composite level can help to some degree.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, August 22, 2006 1:39 PM
Subject: Re: Auto discovering WSDL
>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 <ji...@gmail.com> 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"
>> > <js...@apache.org>
>> > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by ant elder <an...@gmail.com>.
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 <ji...@gmail.com> 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"
> > <js...@apache.org>
> > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Auto discovering WSDL
Posted by Jim Marino <ji...@gmail.com>.
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"
> <js...@apache.org>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Auto discovering WSDL
Posted by Raymond Feng <en...@gmail.com>.
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
----- Original Message -----
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, August 22, 2006 7:34 AM
Subject: Auto discovering WSDL
> In a C++ thread [1] Jean-Sebastien talked about having WSDL files
> automatically picked up by the C++ runtime instead of having to specify a
> wsdlLocation attribute somewhere in the SCDL. I'd really like the Java SCA
> runtime to also do this, do people agree or anyone have any concerns with
> that?
>
> Something like having a specific folder like META-INF/wsdl and in there
> any
> resources ending with .wsdl get automatically loaded into the WSDL
> registry. And I guess this could be implemented with a Builder that gets
> run when a composite is loaded.
>
> Any comments or suggestions?
>
> ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06221.htm
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org