Re: Auto discovering WSDL

[Yang ZHONG]

Comment below.

Thanks.


On 8/24/06, Jim Marino <[EMAIL PROTECTED]> wrote:



On Aug 24, 2006, at 11:08 AM, Yang ZHONG wrote:

> It has been one full day since Ant proposed a go for registry and Jim
> agreed. If no one oppose, I'm going to contribute a registry.
I think this would be great.

> The registry will support
> . different Symbol Spaces (type, top level element, message,
> portType/interface, etc.)
> . multiple scopings (ClassLoader, location, Eclipse IProject,
> composite,
> etc.)
> . different scope delegations (no delegation, PARENT_FIRST,
> PARENT_LAST)
> . multi-dimension scopings (location vs. ClassLoader/IProject, etc)
> and
> registry aggregation (NameSpace aggregation)
> . automatic locate on demand
> . automatic load on demand
> . automatic refresh on demand
> . multi-threading
> . weakly/softly referencing scopes (it's user's responsibility not
> to strong
> reference key from value directly or *indirectly*, it's recommended to
> change such strong reference if any to weak/soft one if permanent
> residency
> isn't desired)
>
> I will also contribute a scoping(SPI) implementation for
> ClassLoader and
> Eclipse IProject,
Could you explain how an IProject relates to this?



ClassLoader and IProject are just Scoping examples, I have no intention to
use them for SCA at all, from that perspective, both ClassLoader and
IProject are not related, they're not SCA specific.
The reason I put them there is just to illustrate the registry is generic
and can take any Scoping. Sorry didn't clarify that.


however we may need volunteer(s) to
> contribute/integrate/register SCA (composite) scoping.
Could you also explain a bit more about what you see as SCA composite
scoping? I was thinking the system service would be "module" scoped
(i.e. singleton per composite it is already deployed as), or
associated on the CompositeComponent directly, in which case the
classloader lookup is probably not necessary (the option of using the
property extension mechanism).



I don't have much knowledge about SCA composite scoping yet, and I have no
intention to impact that (yet).
With generic registry hat on, I don't really count on if SCA uses module or
CompositeComponent or ClassLoader or anything else for scope,
as long as there's a SPI implementation telling the generic registry what
parent scope is for delegation of a given scope. Sorry didn't clarify that.


I will contribute a refreshing checking(SPI) implementation based on
> file/ZipEntry/URL timestamp, however we may need volunteers to
> contribute/integrate/register locator(SPI) implementation and loader
> (SPI)
> implementation.
>
> I'll ask for help from Ant to change the Axis2 binding and JavaScript
> container to use the registry. Thank Ant for the offer.
> I'll also ask Jim for help with the system service part. Thank Jim
> for the
> offer.
Np thanks for doing this.
>
> I'll try to roll out API and SPI for review as soon as possible.
>
> Thanks.
>
> --
>
> Yang ZHONG


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





--

Yang ZHONG

Re: Auto discovering WSDL

[ant elder]

Hi Yang, this sounds great and very comprehensive! It could take some time
to complete it all so can i tell you the parts that would be useful to me to
have sooner rather than later to help with Axis2 and E4X, maybe you could
look at implementing some of these bits first?

For now just WSDL 1.1 support using WSDL4J.

- get a WSDL4J PortType for a portType QName and optional wsdl location

- get a WSDL4J Definition from a service QName and optional wsdl location

- get a WSDL4J Port from a service QName and port name, and an optional wsdl
location (actually, i don't really need the Port, just its endpoint location
string)

Scoping seems complicated, scoped by application seems like it would work
with all the samples I'd like to get going. I guess that means app
classloader or maybe something to do with DeploymentContext. It would be
nice to also support namespace reuse within applications when using the
optional location.

For now just locating wsdl bundled with an application is ok for me, and I'd
like it to support automatically find all wsdl anywhere within the
application folder structure, but other's don't sound so keen on that so
maybe configurable to support locating from anywhere or just a specific
folder.

How doable does all that sound?

  ...ant

On 8/24/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:


It has been one full day since Ant proposed a go for registry and Jim
agreed. If no one oppose, I'm going to contribute a registry.
The registry will support
. different Symbol Spaces (type, top level element, message,
portType/interface, etc.)
. multiple scopings (ClassLoader, location, Eclipse IProject, composite,
etc.)
. different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST)
. multi-dimension scopings (location vs. ClassLoader/IProject, etc) and
registry aggregation (NameSpace aggregation)
. automatic locate on demand
. automatic load on demand
. automatic refresh on demand
. multi-threading
. weakly/softly referencing scopes (it's user's responsibility not to
strong
reference key from value directly or *indirectly*, it's recommended to
change such strong reference if any to weak/soft one if permanent
residency
isn't desired)

I will also contribute a scoping(SPI) implementation for ClassLoader and
Eclipse IProject, however we may need volunteer(s) to
contribute/integrate/register SCA (composite) scoping.
I will contribute a refreshing checking(SPI) implementation based on
file/ZipEntry/URL timestamp, however we may need volunteers to
contribute/integrate/register locator(SPI) implementation and loader(SPI)
implementation.

I'll ask for help from Ant to change the Axis2 binding and JavaScript
container to use the registry. Thank Ant for the offer.
I'll also ask Jim for help with the system service part. Thank Jim for the
offer.

I'll try to roll out API and SPI for review as soon as possible.

Thanks.

--

Yang ZHONG

Re: Auto discovering WSDL

[Yang ZHONG]

Yes, doable.

After I roll out API and SPI (soon I hope) for review, could you provide the
Loader(SPI) implementation for WSDL please?

Thanks.


On 8/24/06, ant elder <[EMAIL PROTECTED]> wrote:


Hi Yang, this sounds great and very comprehensive! It could take some time
to complete it all so can i tell you the parts that would be useful to me
to
have sooner rather than later to help with Axis2 and E4X, maybe you could
look at implementing some of these bits first?

For now just WSDL 1.1 support using WSDL4J.

- get a WSDL4J PortType for a portType QName and optional wsdl location

- get a WSDL4J Definition from a service QName and optional wsdl location

- get a WSDL4J Port from a service QName and port name, and an optional
wsdl
location (actually, i don't really need the Port, just its endpoint
location
string)

Scoping seems complicated, scoped by application seems like it would work
with all the samples I'd like to get going. I guess that means app
classloader or maybe something to do with DeploymentContext. It would be
nice to also support namespace reuse within applications when using the
optional location.

For now just locating wsdl bundled with an application is ok for me, and
I'd
like it to support automatically find all wsdl anywhere within the
application folder structure, but other's don't sound so keen on that so
maybe configurable to support locating from anywhere or just a specific
folder.

How doable does all that sound?

  ...ant

On 8/24/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>
> It has been one full day since Ant proposed a go for registry and Jim
> agreed. If no one oppose, I'm going to contribute a registry.
> The registry will support
> . different Symbol Spaces (type, top level element, message,
> portType/interface, etc.)
> . multiple scopings (ClassLoader, location, Eclipse IProject, composite,
> etc.)
> . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST)
> . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and
> registry aggregation (NameSpace aggregation)
> . automatic locate on demand
> . automatic load on demand
> . automatic refresh on demand
> . multi-threading
> . weakly/softly referencing scopes (it's user's responsibility not to
> strong
> reference key from value directly or *indirectly*, it's recommended to
> change such strong reference if any to weak/soft one if permanent
> residency
> isn't desired)
>
> I will also contribute a scoping(SPI) implementation for ClassLoader and
> Eclipse IProject, however we may need volunteer(s) to
> contribute/integrate/register SCA (composite) scoping.
> I will contribute a refreshing checking(SPI) implementation based on
> file/ZipEntry/URL timestamp, however we may need volunteers to
> contribute/integrate/register locator(SPI) implementation and
loader(SPI)
> implementation.
>
> I'll ask for help from Ant to change the Axis2 binding and JavaScript
> container to use the registry. Thank Ant for the offer.
> I'll also ask Jim for help with the system service part. Thank Jim for
the
> offer.
>
> I'll try to roll out API and SPI for review as soon as possible.
>
> Thanks.
>
> --
>
> Yang ZHONG
>
>





--

Yang ZHONG

Re: Auto discovering WSDL

[Jim Marino]

On Aug 24, 2006, at 11:08 AM, Yang ZHONG wrote:


It has been one full day since Ant proposed a go for registry and Jim
agreed. If no one oppose, I'm going to contribute a registry.

I think this would be great.


The registry will support
. different Symbol Spaces (type, top level element, message,
portType/interface, etc.)
. multiple scopings (ClassLoader, location, Eclipse IProject,  
composite,

etc.)
. different scope delegations (no delegation, PARENT_FIRST,  
PARENT_LAST)
. multi-dimension scopings (location vs. ClassLoader/IProject, etc)  
and

registry aggregation (NameSpace aggregation)
. automatic locate on demand
. automatic load on demand
. automatic refresh on demand
. multi-threading
. weakly/softly referencing scopes (it's user's responsibility not  
to strong

reference key from value directly or *indirectly*, it's recommended to
change such strong reference if any to weak/soft one if permanent  
residency

isn't desired)

I will also contribute a scoping(SPI) implementation for  
ClassLoader and

Eclipse IProject,

Could you explain how an IProject relates to this?


however we may need volunteer(s) to
contribute/integrate/register SCA (composite) scoping.
Could you also explain a bit more about what you see as SCA composite  
scoping? I was thinking the system service would be "module" scoped  
(i.e. singleton per composite it is already deployed as), or  
associated on the CompositeComponent directly, in which case the  
classloader lookup is probably not necessary (the option of using the  
property extension mechanism).



I will contribute a refreshing checking(SPI) implementation based on
file/ZipEntry/URL timestamp, however we may need volunteers to
contribute/integrate/register locator(SPI) implementation and loader 
(SPI)

implementation.

I'll ask for help from Ant to change the Axis2 binding and JavaScript
container to use the registry. Thank Ant for the offer.
I'll also ask Jim for help with the system service part. Thank Jim  
for the

offer.

Np thanks for doing this.


I'll try to roll out API and SPI for review as soon as possible.

Thanks.

--

Yang ZHONG



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

Re: Auto discovering WSDL

[Raymond Feng]

Some comments in line.

Thanks,
Raymond

- Original Message - 
From: "Yang ZHONG" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 24, 2006 11:08 AM
Subject: Re: Auto discovering WSDL



It has been one full day since Ant proposed a go for registry and Jim
agreed. If no one oppose, I'm going to contribute a registry.
The registry will support
. different Symbol Spaces (type, top level element, message,
portType/interface, etc.)


I suggest that we use QName to represent different types of artifacts and it 
should be extensible.



. multiple scopings (ClassLoader, location, Eclipse IProject, composite,
etc.)
. different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST)
. multi-dimension scopings (location vs. ClassLoader/IProject, etc) and
registry aggregation (NameSpace aggregation)


I think we should align it with the SCA scope container concept.


. automatic locate on demand
. automatic load on demand
. automatic refresh on demand
. multi-threading
. weakly/softly referencing scopes (it's user's responsibility not to 
strong

reference key from value directly or *indirectly*, it's recommended to
change such strong reference if any to weak/soft one if permanent 
residency

isn't desired)

I will also contribute a scoping(SPI) implementation for ClassLoader and
Eclipse IProject, however we may need volunteer(s) to
contribute/integrate/register SCA (composite) scoping.
I will contribute a refreshing checking(SPI) implementation based on
file/ZipEntry/URL timestamp, however we may need volunteers to
contribute/integrate/register locator(SPI) implementation and loader(SPI)
implementation.



Probably we should get the framework in place before add more extensions.


I'll ask for help from Ant to change the Axis2 binding and JavaScript
container to use the registry. Thank Ant for the offer.
I'll also ask Jim for help with the system service part. Thank Jim for the
offer.

I'll try to roll out API and SPI for review as soon as possible.

Thanks.

--

Yang ZHONG




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

Re: Auto discovering WSDL

[Yang ZHONG]

It has been one full day since Ant proposed a go for registry and Jim
agreed. If no one oppose, I'm going to contribute a registry.
The registry will support
. different Symbol Spaces (type, top level element, message,
portType/interface, etc.)
. multiple scopings (ClassLoader, location, Eclipse IProject, composite,
etc.)
. different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST)
. multi-dimension scopings (location vs. ClassLoader/IProject, etc) and
registry aggregation (NameSpace aggregation)
. automatic locate on demand
. automatic load on demand
. automatic refresh on demand
. multi-threading
. weakly/softly referencing scopes (it's user's responsibility not to strong
reference key from value directly or *indirectly*, it's recommended to
change such strong reference if any to weak/soft one if permanent residency
isn't desired)

I will also contribute a scoping(SPI) implementation for ClassLoader and
Eclipse IProject, however we may need volunteer(s) to
contribute/integrate/register SCA (composite) scoping.
I will contribute a refreshing checking(SPI) implementation based on
file/ZipEntry/URL timestamp, however we may need volunteers to
contribute/integrate/register locator(SPI) implementation and loader(SPI)
implementation.

I'll ask for help from Ant to change the Axis2 binding and JavaScript
container to use the registry. Thank Ant for the offer.
I'll also ask Jim for help with the system service part. Thank Jim for the
offer.

I'll try to roll out API and SPI for review as soon as possible.

Thanks.

--

Yang ZHONG

Re: Auto discovering WSDL

[Yang ZHONG]

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: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL


On 8/22/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:



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

RE: Auto discovering WSDL

[Liu, Jervis]

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: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL


On 8/22/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:



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]

Re: Auto discovering WSDL

[Jim Marino]

On Aug 23, 2006, at 8:41 AM, ant elder wrote:


On 8/22/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Auto discovering WSDL

[Yang ZHONG]

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 <[EMAIL PROTECTED]> wrote:


On 8/22/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:



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

[ant elder]

On 8/22/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:



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. WAS: RE: Celtix binding

[Jim Marino]

On Aug 23, 2006, at 4:57 AM, Liu, Jervis wrote:

Thanks, ant. I did see this discussion after I sent out my email.  
However, my point was that no matter what kind of locating and  
loading mechanism we adopt, it does not appear to be an absolute  
requirement that we need to cache loaded wsdls. As once the wsdl is  
loaded and parsed, we store all info in the instance of  
WebServiceBinding, there is no need to access wsdl anymore for  
following processes.


Why don't we start with something simple and then add in  
functionality as we need it?


Of course I have to admit, without a cache or registry, it is a bit  
hard to implement refreshings


We do need a system service for example a resolve to lookup and  
load wsdls. It can be a chained resolvers, so that if resolver A  
can not load a resource successfully then the responsibility passes  
to resolver b, then c...This way Tuscany runtime can config a  
default resolving logic by registering resolovers in order,  
applications can extend this by register their own resolvers.


Yea the resolver has come up too. I think we were going to have a  
swappable system service that implemented different resolution  
strategies. Do the resolvers need to do more than just handle  
resolution?

Cheers,
Jervis




-Original Message-
From: ant elder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 6:18 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Celtix binding


There's a long thread going on about this right now:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html

   ...ant

On 8/23/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:


One thing you can try is same as what is done by axis2's
WebServiceBindingLoader, i.e., using wsdlLocation to parse

wsdl Definition

by yourself. This way wsdl Definition is not cached but it works.

I can not remember if we had a discussion on this before.

Do we still need

a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like

we did in M1?

As far as I can see, once WebServiceBinding is created,

components that use

web service binding should be able to access all wsdl

related info from

WebServiceBinding, thus there is no need to access a wsdl

cache any more.


Cheers,
Jervis


-Original Message-
From: Liu, Jervis
Sent: Wednesday, August 23, 2006 10:52 AM
To: Jim Marino; tuscany-dev@ws.apache.org
Cc: Chris Wall
Subject: RE: Celtix binding


Hi Jim, Celtix binding currently is not working yet. I got
the helloworldwsclient working with the Celtix binding with
some hacks and without using SDO. At the same time, for the
helloworldws-celtix sample, I am able to get the reference
part working, and still struggling on the service part. the
creation of WebServiceBinding is one issue among many, the
main problem is that the wsdl info is not properly cached in
WSDLDefinitionRegistry. As soon as helloworldwsclient and
helloworldws-celtix are both working, your sample should work
as well. I will let you know once I make any further progress
on these two samples.

Thanks,
Jervis


-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 4:02 PM
To: tuscany-dev@ws.apache.org
Cc: Chris Wall; Liu, Jervis
Subject: Celtix binding


Hi Jervis,

Chris and I have been trying to get the Celtix binding

bootstrapped

into a sample where it wires to Spring. I noticed
WebServiceBindingLoader line 134 originally returned a null

instead

of a WebServiceBinding, which caused another issue related to
composite wiring (I or Ignacio will need to fix). So, to

get around

this, I changed the loader to return a WebServiceBinding that
doesn't
work as I pass mostly nulls in. Ideally, we'd like to get

the Celtix

part fully working. Both of us are willing to help out

if you can

provide some direction.

The same SCDL and WSDL are attached.

Thanks,
Jim






-

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]




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

Re: Auto discovering WSDL

[Jim Marino]

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 <[EMAIL PROTECTED]> 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 <[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 ex

Re: Auto discovering WSDL

[Rick]

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 <[EMAIL PROTECTED]> wrote:



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: [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]

Re: Auto discovering WSDL

[Rick]

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 <[EMAIL PROTECTED]> wrote:



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




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

Re: Auto discovering WSDL. WAS: RE: Celtix binding

[ant elder]

I agree its not an absolute requirement, but it makes things simpler (in
some respects). Take a simple example of a service using both interface.wsdland
binding.ws without any caching:

   
   
   
   HelloWorldServiceComponent
   

That requires the same wsdl be defined twice which seems a  bit unnecessary.


More complex examples which also include components using interface.wsdl and
composites including other composites and wanting wsdl shared between both
composites and you end up having to specify  the same wsdl lots of times.

Compare that to say , you don't
have to tell that where to find the class as it just comes from the
application class loader. Some sort of WSDL registry could be similar to the
application class loader.

  ...ant

On 8/23/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:


Thanks, ant. I did see this discussion after I sent out my email. However,
my point was that no matter what kind of locating and loading mechanism we
adopt, it does not appear to be an absolute requirement that we need to
cache loaded wsdls. As once the wsdl is loaded and parsed, we store all info
in the instance of WebServiceBinding, there is no need to access wsdl
anymore for following processes. Of course I have to admit, without a cache
or registry, it is a bit hard to implement refreshings

We do need a system service for example a resolve to lookup and load
wsdls. It can be a chained resolvers, so that if resolver A can not load a
resource successfully then the responsibility passes to resolver b, then
c...This way Tuscany runtime can config a default resolving logic by
registering resolovers in order, applications can extend this by register
their own resolvers.

Cheers,
Jervis



> -Original Message-
> From: ant elder [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 23, 2006 6:18 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Celtix binding
>
>
> There's a long thread going on about this right now:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html
>
>...ant
>
> On 8/23/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> >
> > One thing you can try is same as what is done by axis2's
> > WebServiceBindingLoader, i.e., using wsdlLocation to parse
> wsdl Definition
> > by yourself. This way wsdl Definition is not cached but it works.
> >
> > I can not remember if we had a discussion on this before.
> Do we still need
> > a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like
> we did in M1?
> > As far as I can see, once WebServiceBinding is created,
> components that use
> > web service binding should be able to access all wsdl
> related info from
> > WebServiceBinding, thus there is no need to access a wsdl
> cache any more.
> >
> > Cheers,
> > Jervis
> >
> > > -Original Message-
> > > From: Liu, Jervis
> > > Sent: Wednesday, August 23, 2006 10:52 AM
> > > To: Jim Marino; tuscany-dev@ws.apache.org
> > > Cc: Chris Wall
> > > Subject: RE: Celtix binding
> > >
> > >
> > > Hi Jim, Celtix binding currently is not working yet. I got
> > > the helloworldwsclient working with the Celtix binding with
> > > some hacks and without using SDO. At the same time, for the
> > > helloworldws-celtix sample, I am able to get the reference
> > > part working, and still struggling on the service part. the
> > > creation of WebServiceBinding is one issue among many, the
> > > main problem is that the wsdl info is not properly cached in
> > > WSDLDefinitionRegistry. As soon as helloworldwsclient and
> > > helloworldws-celtix are both working, your sample should work
> > > as well. I will let you know once I make any further progress
> > > on these two samples.
> > >
> > > Thanks,
> > > Jervis
> > >
> > > > -Original Message-
> > > > From: Jim Marino [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, August 22, 2006 4:02 PM
> > > > To: tuscany-dev@ws.apache.org
> > > > Cc: Chris Wall; Liu, Jervis
> > > > Subject: Celtix binding
> > > >
> > > >
> > > > Hi Jervis,
> > > >
> > > > Chris and I have been trying to get the Celtix binding
> > > bootstrapped
> > > > into a sample where it wires to Spring. I noticed
> > > > WebServiceBindingLoader line 134 originally returned a null
> > > instead
> > > > of a WebServiceBinding, which caused another issue related to
> > > > composite wiring (I or Ignacio will need to fix). So, to
> > > get around
> > > > this, I changed the loader to return a WebServiceBinding that
> > > > doesn't
> > > > work as I pass mostly nulls in. Ideally, we'd like to get
> > > the Celtix
> > > > part fully working. Both of us are willing to help out
> if you can
> > > > provide some direction.
> > > >
> > > > The same SCDL and WSDL are attached.
> > > >
> > > > Thanks,
> > > > Jim
> > > >
> > > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> --

Re: Auto discovering WSDL. WAS: RE: Celtix binding

[Liu, Jervis]

Thanks, ant. I did see this discussion after I sent out my email. However, my 
point was that no matter what kind of locating and loading mechanism we adopt, 
it does not appear to be an absolute requirement that we need to cache loaded 
wsdls. As once the wsdl is loaded and parsed, we store all info in the instance 
of WebServiceBinding, there is no need to access wsdl anymore for following 
processes. Of course I have to admit, without a cache or registry, it is a bit 
hard to implement refreshings

We do need a system service for example a resolve to lookup and load wsdls. It 
can be a chained resolvers, so that if resolver A can not load a resource 
successfully then the responsibility passes to resolver b, then c...This way 
Tuscany runtime can config a default resolving logic by registering resolovers 
in order, applications can extend this by register their own resolvers. 

Cheers,
Jervis 



> -Original Message-
> From: ant elder [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 23, 2006 6:18 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Celtix binding
> 
> 
> There's a long thread going on about this right now:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html
> 
>...ant
> 
> On 8/23/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> >
> > One thing you can try is same as what is done by axis2's
> > WebServiceBindingLoader, i.e., using wsdlLocation to parse 
> wsdl Definition
> > by yourself. This way wsdl Definition is not cached but it works.
> >
> > I can not remember if we had a discussion on this before. 
> Do we still need
> > a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like 
> we did in M1?
> > As far as I can see, once WebServiceBinding is created, 
> components that use
> > web service binding should be able to access all wsdl 
> related info from
> > WebServiceBinding, thus there is no need to access a wsdl 
> cache any more.
> >
> > Cheers,
> > Jervis
> >
> > > -Original Message-
> > > From: Liu, Jervis
> > > Sent: Wednesday, August 23, 2006 10:52 AM
> > > To: Jim Marino; tuscany-dev@ws.apache.org
> > > Cc: Chris Wall
> > > Subject: RE: Celtix binding
> > >
> > >
> > > Hi Jim, Celtix binding currently is not working yet. I got
> > > the helloworldwsclient working with the Celtix binding with
> > > some hacks and without using SDO. At the same time, for the
> > > helloworldws-celtix sample, I am able to get the reference
> > > part working, and still struggling on the service part. the
> > > creation of WebServiceBinding is one issue among many, the
> > > main problem is that the wsdl info is not properly cached in
> > > WSDLDefinitionRegistry. As soon as helloworldwsclient and
> > > helloworldws-celtix are both working, your sample should work
> > > as well. I will let you know once I make any further progress
> > > on these two samples.
> > >
> > > Thanks,
> > > Jervis
> > >
> > > > -Original Message-
> > > > From: Jim Marino [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, August 22, 2006 4:02 PM
> > > > To: tuscany-dev@ws.apache.org
> > > > Cc: Chris Wall; Liu, Jervis
> > > > Subject: Celtix binding
> > > >
> > > >
> > > > Hi Jervis,
> > > >
> > > > Chris and I have been trying to get the Celtix binding
> > > bootstrapped
> > > > into a sample where it wires to Spring. I noticed
> > > > WebServiceBindingLoader line 134 originally returned a null
> > > instead
> > > > of a WebServiceBinding, which caused another issue related to
> > > > composite wiring (I or Ignacio will need to fix). So, to
> > > get around
> > > > this, I changed the loader to return a WebServiceBinding that
> > > > doesn't
> > > > work as I pass mostly nulls in. Ideally, we'd like to get
> > > the Celtix
> > > > part fully working. Both of us are willing to help out 
> if you can
> > > > provide some direction.
> > > >
> > > > The same SCDL and WSDL are attached.
> > > >
> > > > Thanks,
> > > > Jim
> > > >
> > > >
> > >
> > > 
> -
> > > 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]

Re: Auto discovering WSDL

[Jim Marino]

On Aug 22, 2006, at 4:53 PM, Jean-Sebastien Delfino wrote:


ant elder wrote:

On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




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

Re: Auto discovering WSDL

[Jim Marino]

On Aug 22, 2006, at 4:31 PM, ant elder wrote:


On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Auto discovering WSDL

[Yang ZHONG]

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 <[EMAIL PROTECTED]> 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 <[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: 
>> > > Sent: Tuesday, August 22, 2006 10:21 AM
>> > > Subject: Re: A

Re: Auto discovering WSDL

[Jean-Sebastien Delfino]

ant elder wrote:

On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:



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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Auto discovering WSDL

[ant elder]

On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:



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

[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: 
> > 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

Re: Auto discovering WSDL

[Jim Marino]

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 <[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: 
> 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]





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

Re: Auto discovering WSDL

[Yang ZHONG]

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: 
> > 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

Re: Auto discovering WSDL

[Raymond Feng]

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" <[EMAIL PROTECTED]>

To: 
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 <[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: 
> 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]







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

Re: Auto discovering WSDL

[ant elder]

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: 
> 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]

Re: Auto discovering WSDL

[Jim Marino]

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: 
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]

Re: Auto discovering WSDL

[Raymond Feng]

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: 
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]

Re: Auto discovering WSDL

[Jean-Sebastien Delfino]

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]

Re: Auto discovering WSDL

[Yang ZHONG]

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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
To: 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--

Yang ZHONG

Re: Auto discovering WSDL

[Raymond Feng]

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" <[EMAIL PROTECTED]>

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

Re: Auto discovering WSDL

[Simon Laws]

On 8/22/06, ant elder <[EMAIL PROTECTED]> 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

[Jean-Sebastien Delfino]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Auto discovering WSDL

[Jim Marino]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]