You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/07/24 22:38:54 UTC
Resolving WSDL/XSD import/include for SCA contributions
Hi,
I'm working on the artifact processing of WSDL/XSD from SCA contributions,
especially for the import/include directives. I would like to share what I
have so far to get your feedback.
Let's assume we have the following artifacts ([1][2]).
* helloworld-service.wsdl (definition) imports helloworld-interface.wsdl
* helloworld-interface.wsdl (inline schema) imports greeting.xsd
* greeting.xsd includes name.xsd
For the import/include, we could have different ways to use the "location"
attribute for a WSDL <import>. Please note the SCA spec says the explicit
location attribute should be honored. If it's not present, then we use the
namespace-based resolution defined by SCA.
1. location="helloworld-interface.wsdl" (relative to the base document where
the import is defined)
2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA
contribution)
3. location="http://example.com/helloworld-interface.wsdl" (absolute URL
pointing to an external resource)
4. location="" or location is not present: Use the namespace to resolve the
imported definition
We have two options here:
a) Plugin a tuscany-specific resolver for WSDL4J
(javax.wsdl.xml.WSDLLocator) and XmlSchema
(org.apache.ws.commons.schema.resolver.URIResolver).
This option can handle location case 1, 2 and 3. For 2, we probably need
some context from the contribution service.
The difficulty is that both resolvers expect to take an InputSource. For
location case 4 (empty or not present), we don't have a corresponding
InputSource. To make WSDL4J happy, we might be able to provide a dummy
InputSource pointing to a byte array which contains the empty definition
(AFAIK, null InputSource won't work) and then resolve the imported
definition by QName during the resolve() phase.
b) Disable the import/include resolving feature and re-link the related
artifacts by Tuscany
There are two challenges:
How to disable the aggressive resolving of import/include?
How to re-link the artifacts after the fragments are loaded?
WSDL4J: We can disable the import processing by WSDL4J and then resolve the
imported artifacts in the different step. Some of the elements are
"undefined" and we have to navigate the WSDL4J model and resolve them.
During the procedure, we can use the location as a key to constrain the
scope of resolution.
XmlSchema doesn't seem to have a way to disable the aggressive resolving.
What do you guys think? Any opinions are welcome.
Thanks,
Raymond
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/wsdl
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/xsd
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving WSDL/XSD import/include for SCA contributions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Raymond Feng wrote:
> Hi,
>
> I created a WIKI page
> (http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts)
> to track discussions around this area.
>
> I have also checked in the following algorithm in trunk for WSDL/XSDs.
>
> 1) For each WSDL file in a SCA contribution, the
> WSDLDocumentProcessor.read() method will only read the target
> namespaces for the WSDL definition and inline schemas using StAX. An
> instance of WSDLDefinition with the namespace and location is
> returned. The definition is null because the it's not fully loaded
> yet. The model is then added to the WSDLModelResolver by the
> ContributionServiceImpl.
>
> 2) During the resolve phase, when a reference to a WSDL Definition
> (from <interface.wsdl> or <binding.ws>) is resolved by an artifact
> processor (for example, WSDLInterfaceProcessor), it will be delegated
> to the WSDLModelResolver.
>
> 3) The WSDLModelResolver looks up all the WSDLDefinition(s) created
> under step 1 using the namespace of the WSDLDefintion (proxy) to be
> resolved. It then fully loads the model using WSDL4J. If there are
> multiple WSDLDefintions under the same namespace, the definitions are
> aggregated. It's achieved by creating a Definition with Import(s) for
> each of the Definitions.
>
> 4) The import/include among WSDL/XSD files follow the document-based
> resolving strategy:
> a) If the location/schemaLocation attribute is an absolute URI (for
> example, http://www.example.com/a.wsdl), it will be used as is.
> b) If the location/schemaLocation attribute is a relative URI
> without a leading / (for example, ../xsd/a.xsd), then it will be
> resolved against the base document URI.
> c) If the location/schemaLocation attribute is a relative URI with
> a leading / (for example, /wsdl/b.wsdl), then it will be resolved
> against the base URI of the containing SCA contribution.
> d) If the location/schemaLocation attribute is absent, it's not
> supported (or we can pick the 1st document in the contribution that
> matches the namespace?)
>
> I think the sample strategy can apply to other XML documents such as
> SCA componentType files and BPEL files.
>
> What do you guys think?
>
> Thanks,
> Raymond
>
I took a look at what you did and it looks good to me. I'm going to try
to apply the same technique to Composites, ConstrainingTypes and
ComponentTypes. Loading them dynamically will improve footprint, startup
time and overall experience as we won't be broken anymore by erronenous
but unused files, because we won't be loading them aggressively any more.
I also noticed that you had to hardcode some of the factories in the
WSDLModelResolver for example. I'm in the middle of fixing that simply
by passing the ModelFactory extension point to ModelResolvers. This is
going to be a pretty common requirement as ModelResolvers will have to
dynamically create instance model objects as they are resolved
(Composite, ConstainingType and ComponentType resolvers will need the
factories too).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving WSDL/XSD import/include for SCA contributions
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I created a WIKI page
(http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts)
to track discussions around this area.
I have also checked in the following algorithm in trunk for WSDL/XSDs.
1) For each WSDL file in a SCA contribution, the
WSDLDocumentProcessor.read() method will only read the target namespaces for
the WSDL definition and inline schemas using StAX. An instance of
WSDLDefinition with the namespace and location is returned. The definition
is null because the it's not fully loaded yet. The model is then added to
the WSDLModelResolver by the ContributionServiceImpl.
2) During the resolve phase, when a reference to a WSDL Definition (from
<interface.wsdl> or <binding.ws>) is resolved by an artifact processor (for
example, WSDLInterfaceProcessor), it will be delegated to the
WSDLModelResolver.
3) The WSDLModelResolver looks up all the WSDLDefinition(s) created under
step 1 using the namespace of the WSDLDefintion (proxy) to be resolved. It
then fully loads the model using WSDL4J. If there are multiple
WSDLDefintions under the same namespace, the definitions are aggregated.
It's achieved by creating a Definition with Import(s) for each of the
Definitions.
4) The import/include among WSDL/XSD files follow the document-based
resolving strategy:
a) If the location/schemaLocation attribute is an absolute URI (for
example, http://www.example.com/a.wsdl), it will be used as is.
b) If the location/schemaLocation attribute is a relative URI without a
leading / (for example, ../xsd/a.xsd), then it will be resolved against the
base document URI.
c) If the location/schemaLocation attribute is a relative URI with a
leading / (for example, /wsdl/b.wsdl), then it will be resolved against the
base URI of the containing SCA contribution.
d) If the location/schemaLocation attribute is absent, it's not
supported (or we can pick the 1st document in the contribution that matches
the namespace?)
I think the sample strategy can apply to other XML documents such as SCA
componentType files and BPEL files.
What do you guys think?
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Sunday, July 29, 2007 6:43 AM
Subject: Re: Resolving WSDL/XSD import/include for SCA contributions
> Hi,
>
> I was recently looking into
> http://issues.apache.org/jira/browse/TUSCANY-1343 and I am able to
> relate well with all of what is being discussed here. From whatever I
> understand from that JIRA it is desired that the package-processor
> that is processing an SCA contribution be given the responsibility of
> locating and loading the xsd or wsdl. i.e. the WSDLProcessor does not
> take on the locating and loading. Asking for this seems consistent
> with our overall artifact reading and resolution design but I couldn't
> quite figure out a clean way of achieving this. What Huang is
> suggesting for a way out of this seems like something worth exploring.
> Thoughts ?
>
> Thanks
>
> - Venkat
>
>
>
> On 7/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> Jean-Sebastien Delfino wrote:
>> > Comments and questions inline.
>> >
>> > Mike Edwards wrote:
>> >> Hi,
>> >>
>> >> A few thoughts....
>> >>
>> >>
>> >> <snip>
>> >> >> We have two options here:
>> >> >>
>> >> >> a) Plugin a tuscany-specific resolver for WSDL4J
>> >> >> (javax.wsdl.xml.WSDLLocator) and XmlSchema
>> >> >> (org.apache.ws.commons.schema.resolver.URIResolver).
>> >> >>
>> >> >> This option can handle location case 1, 2 and 3. For 2, we
>> >> probably need
>> >> >> some context from the contribution service.
>> >> >>
>> >> >> The difficulty is that both resolvers expect to take an
>> >> InputSource. For
>> >> >> location case 4 (empty or not present), we don't have a
>> >> >> corresponding
>> >> >> InputSource.
>> >> >
>> >> > I was going to respond with a long list of pros-cons for both
>> >> > options,
>> >> > then deleted all my comments to ask a simple question :). Why can't
>> >> > we
>> >> > return an InputSource for the contents of the imported document?
>> >> >
>> >>
>> >> > Well, for the import/include that can be resolved to a document, we
>> >> > return the InputSource. I have said that it works for location case
>> >> 1, > 2 and 3. But if the import/include only doesn't have the
>> >> > schemaLocation attribute, what InputSource should we return?
>> >>
>> >> Well, it seems valid to me to go use the SCA resolution mechanism -
>> >> it is simple enough to say, either use the WSDL or XML approach (and
>> >> require a location) but if there is no location, then this isn't
>> >> going to work and SCA takes over. I note that if the location is
>> >> left out in the case of the included/imported file being in the same
>> >> contribution as the source file, then things are simple and the SCA
>> >> rules will find it.
>> >>
>> >> If it is elsewhere, then SCA at least defines an algorithm to follow
>> >> to attempt to find the referenced file.
>> >
>> > How about this then:
>> > - if the location is not specified you get the first WSDL file we find
>> > matching the namespace in the current contribution or in a
>> > contribution imported by an SCA <import>
>> > - if you're not happy with that (because for example you have multiple
>> > WSDLs sharing the same namespace), please specify a correct location
>> > in your WSDL
>>
>> I should have said XSD here instead of WSDL as locations are mandatory
>> in WSDL...
>>
>> >
>> > Is this too simplistic? Do you see any realistic scenarios that we
>> > wouldn't be able to support with this approach?
>> >
>> >>
>> >>
>> >> > A related question, for an artifact processer that loads multiple
>> >> > artifacts following the import/include directives, how can we avoid
>> >> > the duplicate loading? For example, we have a.wsdl imports b.wsdl,
>> >> > both a.wsdl and b.wsdl are in the same contribution and they are
>> >> > processed by the WSDL artifact processor. We probably don't want to
>> >> > load b.wsdl twice in this case.
>> >>
>> >> Why actually load anything before it is clearly required?
>> >
>> > I'm not quite following yet, how does one know that file X.wsdl is
>> > clearly required?
>> >
>> >> But once it is loaded, keep it around. This should be true for all
>> >> artifacts.
>> >
>> > +1 for all artifacts that we handle ourselves, but WSDL4J and the
>> > XmlSchema lib do not seem to support this. Has anybody raised this
>> > issue to them?
>> >
>> >
>> >>
>> >> Yours, Mike.
>> >>
>>
>>
>> --
>> 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: Resolving WSDL/XSD import/include for SCA contributions
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I was recently looking into
http://issues.apache.org/jira/browse/TUSCANY-1343 and I am able to
relate well with all of what is being discussed here. From whatever I
understand from that JIRA it is desired that the package-processor
that is processing an SCA contribution be given the responsibility of
locating and loading the xsd or wsdl. i.e. the WSDLProcessor does not
take on the locating and loading. Asking for this seems consistent
with our overall artifact reading and resolution design but I couldn't
quite figure out a clean way of achieving this. What Huang is
suggesting for a way out of this seems like something worth exploring.
Thoughts ?
Thanks
- Venkat
On 7/27/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
> > Comments and questions inline.
> >
> > Mike Edwards wrote:
> >> Hi,
> >>
> >> A few thoughts....
> >>
> >>
> >> <snip>
> >> >> We have two options here:
> >> >>
> >> >> a) Plugin a tuscany-specific resolver for WSDL4J
> >> >> (javax.wsdl.xml.WSDLLocator) and XmlSchema
> >> >> (org.apache.ws.commons.schema.resolver.URIResolver).
> >> >>
> >> >> This option can handle location case 1, 2 and 3. For 2, we
> >> probably need
> >> >> some context from the contribution service.
> >> >>
> >> >> The difficulty is that both resolvers expect to take an
> >> InputSource. For
> >> >> location case 4 (empty or not present), we don't have a corresponding
> >> >> InputSource.
> >> >
> >> > I was going to respond with a long list of pros-cons for both options,
> >> > then deleted all my comments to ask a simple question :). Why can't we
> >> > return an InputSource for the contents of the imported document?
> >> >
> >>
> >> > Well, for the import/include that can be resolved to a document, we
> >> > return the InputSource. I have said that it works for location case
> >> 1, > 2 and 3. But if the import/include only doesn't have the
> >> > schemaLocation attribute, what InputSource should we return?
> >>
> >> Well, it seems valid to me to go use the SCA resolution mechanism -
> >> it is simple enough to say, either use the WSDL or XML approach (and
> >> require a location) but if there is no location, then this isn't
> >> going to work and SCA takes over. I note that if the location is
> >> left out in the case of the included/imported file being in the same
> >> contribution as the source file, then things are simple and the SCA
> >> rules will find it.
> >>
> >> If it is elsewhere, then SCA at least defines an algorithm to follow
> >> to attempt to find the referenced file.
> >
> > How about this then:
> > - if the location is not specified you get the first WSDL file we find
> > matching the namespace in the current contribution or in a
> > contribution imported by an SCA <import>
> > - if you're not happy with that (because for example you have multiple
> > WSDLs sharing the same namespace), please specify a correct location
> > in your WSDL
>
> I should have said XSD here instead of WSDL as locations are mandatory
> in WSDL...
>
> >
> > Is this too simplistic? Do you see any realistic scenarios that we
> > wouldn't be able to support with this approach?
> >
> >>
> >>
> >> > A related question, for an artifact processer that loads multiple
> >> > artifacts following the import/include directives, how can we avoid
> >> > the duplicate loading? For example, we have a.wsdl imports b.wsdl,
> >> > both a.wsdl and b.wsdl are in the same contribution and they are
> >> > processed by the WSDL artifact processor. We probably don't want to
> >> > load b.wsdl twice in this case.
> >>
> >> Why actually load anything before it is clearly required?
> >
> > I'm not quite following yet, how does one know that file X.wsdl is
> > clearly required?
> >
> >> But once it is loaded, keep it around. This should be true for all
> >> artifacts.
> >
> > +1 for all artifacts that we handle ourselves, but WSDL4J and the
> > XmlSchema lib do not seem to support this. Has anybody raised this
> > issue to them?
> >
> >
> >>
> >> Yours, Mike.
> >>
>
>
> --
> 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: Resolving WSDL/XSD import/include for SCA contributions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Comments and questions inline.
>
> Mike Edwards wrote:
>> Hi,
>>
>> A few thoughts....
>>
>>
>> <snip>
>> >> We have two options here:
>> >>
>> >> a) Plugin a tuscany-specific resolver for WSDL4J
>> >> (javax.wsdl.xml.WSDLLocator) and XmlSchema
>> >> (org.apache.ws.commons.schema.resolver.URIResolver).
>> >>
>> >> This option can handle location case 1, 2 and 3. For 2, we
>> probably need
>> >> some context from the contribution service.
>> >>
>> >> The difficulty is that both resolvers expect to take an
>> InputSource. For
>> >> location case 4 (empty or not present), we don't have a corresponding
>> >> InputSource.
>> >
>> > I was going to respond with a long list of pros-cons for both options,
>> > then deleted all my comments to ask a simple question :). Why can't we
>> > return an InputSource for the contents of the imported document?
>> >
>>
>> > Well, for the import/include that can be resolved to a document, we
>> > return the InputSource. I have said that it works for location case
>> 1, > 2 and 3. But if the import/include only doesn't have the
>> > schemaLocation attribute, what InputSource should we return?
>>
>> Well, it seems valid to me to go use the SCA resolution mechanism -
>> it is simple enough to say, either use the WSDL or XML approach (and
>> require a location) but if there is no location, then this isn't
>> going to work and SCA takes over. I note that if the location is
>> left out in the case of the included/imported file being in the same
>> contribution as the source file, then things are simple and the SCA
>> rules will find it.
>>
>> If it is elsewhere, then SCA at least defines an algorithm to follow
>> to attempt to find the referenced file.
>
> How about this then:
> - if the location is not specified you get the first WSDL file we find
> matching the namespace in the current contribution or in a
> contribution imported by an SCA <import>
> - if you're not happy with that (because for example you have multiple
> WSDLs sharing the same namespace), please specify a correct location
> in your WSDL
I should have said XSD here instead of WSDL as locations are mandatory
in WSDL...
>
> Is this too simplistic? Do you see any realistic scenarios that we
> wouldn't be able to support with this approach?
>
>>
>>
>> > A related question, for an artifact processer that loads multiple
>> > artifacts following the import/include directives, how can we avoid
>> > the duplicate loading? For example, we have a.wsdl imports b.wsdl,
>> > both a.wsdl and b.wsdl are in the same contribution and they are
>> > processed by the WSDL artifact processor. We probably don't want to
>> > load b.wsdl twice in this case.
>>
>> Why actually load anything before it is clearly required?
>
> I'm not quite following yet, how does one know that file X.wsdl is
> clearly required?
>
>> But once it is loaded, keep it around. This should be true for all
>> artifacts.
>
> +1 for all artifacts that we handle ourselves, but WSDL4J and the
> XmlSchema lib do not seem to support this. Has anybody raised this
> issue to them?
>
>
>>
>> Yours, Mike.
>>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving WSDL/XSD import/include for SCA contributions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments and questions inline.
Mike Edwards wrote:
> Hi,
>
> A few thoughts....
>
>
> <snip>
> >> We have two options here:
> >>
> >> a) Plugin a tuscany-specific resolver for WSDL4J
> >> (javax.wsdl.xml.WSDLLocator) and XmlSchema
> >> (org.apache.ws.commons.schema.resolver.URIResolver).
> >>
> >> This option can handle location case 1, 2 and 3. For 2, we probably
> need
> >> some context from the contribution service.
> >>
> >> The difficulty is that both resolvers expect to take an
> InputSource. For
> >> location case 4 (empty or not present), we don't have a corresponding
> >> InputSource.
> >
> > I was going to respond with a long list of pros-cons for both options,
> > then deleted all my comments to ask a simple question :). Why can't we
> > return an InputSource for the contents of the imported document?
> >
>
> > Well, for the import/include that can be resolved to a document, we
> > return the InputSource. I have said that it works for location case
> 1, > 2 and 3. But if the import/include only doesn't have the
> > schemaLocation attribute, what InputSource should we return?
>
> Well, it seems valid to me to go use the SCA resolution mechanism - it
> is simple enough to say, either use the WSDL or XML approach (and
> require a location) but if there is no location, then this isn't going
> to work and SCA takes over. I note that if the location is left out
> in the case of the included/imported file being in the same
> contribution as the source file, then things are simple and the SCA
> rules will find it.
>
> If it is elsewhere, then SCA at least defines an algorithm to follow
> to attempt to find the referenced file.
How about this then:
- if the location is not specified you get the first WSDL file we find
matching the namespace in the current contribution or in a contribution
imported by an SCA <import>
- if you're not happy with that (because for example you have multiple
WSDLs sharing the same namespace), please specify a correct location in
your WSDL
Is this too simplistic? Do you see any realistic scenarios that we
wouldn't be able to support with this approach?
>
>
> > A related question, for an artifact processer that loads multiple
> > artifacts following the import/include directives, how can we avoid
> > the duplicate loading? For example, we have a.wsdl imports b.wsdl,
> > both a.wsdl and b.wsdl are in the same contribution and they are
> > processed by the WSDL artifact processor. We probably don't want to
> > load b.wsdl twice in this case.
>
> Why actually load anything before it is clearly required?
I'm not quite following yet, how does one know that file X.wsdl is
clearly required?
> But once it is loaded, keep it around. This should be true for all
> artifacts.
+1 for all artifacts that we handle ourselves, but WSDL4J and the
XmlSchema lib do not seem to support this. Has anybody raised this issue
to them?
>
> Yours, Mike.
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving WSDL/XSD import/include for SCA contributions
Posted by Mike Edwards <mi...@gmail.com>.
Hi,
A few thoughts....
<snip>
>> We have two options here:
>>
>> a) Plugin a tuscany-specific resolver for WSDL4J
>> (javax.wsdl.xml.WSDLLocator) and XmlSchema
>> (org.apache.ws.commons.schema.resolver.URIResolver).
>>
>> This option can handle location case 1, 2 and 3. For 2, we probably
need
>> some context from the contribution service.
>>
>> The difficulty is that both resolvers expect to take an InputSource.
For
>> location case 4 (empty or not present), we don't have a corresponding
>> InputSource.
>
> I was going to respond with a long list of pros-cons for both options,
> then deleted all my comments to ask a simple question :). Why can't we
> return an InputSource for the contents of the imported document?
>
> Well, for the import/include that can be resolved to a document, we
> return the InputSource. I have said that it works for location case
1, > 2 and 3. But if the import/include only doesn't have the
> schemaLocation attribute, what InputSource should we return?
Well, it seems valid to me to go use the SCA resolution mechanism - it
is simple enough to say, either use the WSDL or XML approach (and
require a location) but if there is no location, then this isn't going
to work and SCA takes over. I note that if the location is left out in
the case of the included/imported file being in the same contribution as
the source file, then things are simple and the SCA rules will find it.
If it is elsewhere, then SCA at least defines an algorithm to follow to
attempt to find the referenced file.
> A related question, for an artifact processer that loads multiple
> artifacts following the import/include directives, how can we avoid
> the duplicate loading? For example, we have a.wsdl imports b.wsdl,
> both a.wsdl and b.wsdl are in the same contribution and they are
> processed by the WSDL artifact processor. We probably don't want to
> load b.wsdl twice in this case.
Why actually load anything before it is clearly required? But once it
is loaded, keep it around. This should be true for all artifacts.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving WSDL/XSD import/include for SCA contributions
Posted by Huang Kai <pr...@gmail.com>.
Hi, Raymond:
I also noticed the same problem when testing Tuscany two days ago.
I'm not familiar with WSDL4j. When I looked into the codes, my fist response is replacing WSDLLocator, as you mentioned. While the ugly thing is that WSDLLocator return InputSource instead of some sort of placeholder/delegate.
We rough thought is use some sort of lazy-import/include way to get around this problem(If you can't stop the aggressive resolveing, you cheat it).
So you might want a dummy WSDLDefinition for return instead of implementing a dummy InputSource. You just record the location of the wsdl file in the read() phase, and resolve all the recorded wsdl files in the resolve() phase, then replace the dummies with the real ones. This can promise you to have the right InputSource.
The last thing I want to do is implements your own WSDLFactory and WSDLReader by subclassing the default.
What's more, SDO has its XSDHelper to parse all the xsd files to load all SDO types they need ( That is to say, some SDO implementation may registered their own XSDDocumentProcessor).
So the Tuscany may need some kind of mechanism to allow delegating the resolving of namespace in wsdl to SDO's TypeHelper.(That is why I prefer the use of namespace to schemaLocation)
Another problem we saw in WSDL in Tuscany is WSDLOperation. Where multiple output parts is not supported explicitly. Then what if some service return an array of objects as return?
----- Original Message -----
From: "Raymond Feng" <en...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, July 25, 2007 10:29 AM
Subject: Re: Resolving WSDL/XSD import/include for SCA contributions
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, July 24, 2007 6:46 PM
> Subject: Re: Resolving WSDL/XSD import/include for SCA contributions
>
>
>> Two questions inline.
>>
>>
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> I'm working on the artifact processing of WSDL/XSD from SCA
>>> contributions, especially for the import/include directives. I would like
>>> to share what I have so far to get your feedback.
>>>
>>> Let's assume we have the following artifacts ([1][2]).
>>>
>>> * helloworld-service.wsdl (definition) imports helloworld-interface.wsdl
>>> * helloworld-interface.wsdl (inline schema) imports greeting.xsd
>>> * greeting.xsd includes name.xsd
>>>
>>> For the import/include, we could have different ways to use the
>>> "location" attribute for a WSDL <import>. Please note the SCA spec says
>>> the explicit location attribute should be honored. If it's not present,
>>> then we use the namespace-based resolution defined by SCA.
>>>
>>> 1. location="helloworld-interface.wsdl" (relative to the base document
>>> where the import is defined)
>>> 2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA
>>> contribution)
>>> 3. location="http://example.com/helloworld-interface.wsdl" (absolute URL
>>> pointing to an external resource)
>>> 4. location="" or location is not present: Use the namespace to resolve
>>> the imported definition
>>
>> Is location="" even valid? I didn't think so.
>
> I have clarified this on the follow-up e-mail. The location attribute is
> required for <import.wsdl>. "" doesn't seem to be a valid URI.
>
> The absence of schemaLocation for <xsd:import> and <xsd:include> are valid
> though.
>
>>
>>>
>>> We have two options here:
>>>
>>> a) Plugin a tuscany-specific resolver for WSDL4J
>>> (javax.wsdl.xml.WSDLLocator) and XmlSchema
>>> (org.apache.ws.commons.schema.resolver.URIResolver).
>>>
>>> This option can handle location case 1, 2 and 3. For 2, we probably need
>>> some context from the contribution service.
>>>
>>> The difficulty is that both resolvers expect to take an InputSource. For
>>> location case 4 (empty or not present), we don't have a corresponding
>>> InputSource.
>>
>> I was going to respond with a long list of pros-cons for both options,
>> then deleted all my comments to ask a simple question :). Why can't we
>> return an InputSource for the contents of the imported document?
>>
>
> Well, for the import/include that can be resolved to a document, we return
> the InputSource. I have said that it works for location case 1, 2 and 3. But
> if the import/include only doesn't have the schemaLocation attribute, what
> InputSource should we return?
>
> A related question, for an artifact processer that loads multiple artifacts
> following the import/include directives, how can we avoid the duplicate
> loading? For example, we have a.wsdl imports b.wsdl, both a.wsdl and b.wsdl
> are in the same contribution and they are processed by the WSDL artifact
> processor. We probably don't want to load b.wsdl twice in this case.
>
>>> To make WSDL4J happy, we might be able to provide a dummy InputSource
>>> pointing to a byte array which contains the empty definition (AFAIK, null
>>> InputSource won't work) and then resolve the imported definition by QName
>>> during the resolve() phase.
>>>
>>> b) Disable the import/include resolving feature and re-link the related
>>> artifacts by Tuscany
>>>
>>> There are two challenges:
>>>
>>> How to disable the aggressive resolving of import/include?
>>> How to re-link the artifacts after the fragments are loaded?
>>>
>>> WSDL4J: We can disable the import processing by WSDL4J and then resolve
>>> the imported artifacts in the different step. Some of the elements are
>>> "undefined" and we have to navigate the WSDL4J model and resolve them.
>>> During the procedure, we can use the location as a key to constrain the
>>> scope of resolution.
>>>
>>> XmlSchema doesn't seem to have a way to disable the aggressive resolving.
>>>
>>> What do you guys think? Any opinions are welcome.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> [1]
>>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/wsdl
>>> [2]
>>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/xsd
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>> 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: Resolving WSDL/XSD import/include for SCA contributions
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, July 24, 2007 6:46 PM
Subject: Re: Resolving WSDL/XSD import/include for SCA contributions
> Two questions inline.
>
>
> Raymond Feng wrote:
>> Hi,
>>
>> I'm working on the artifact processing of WSDL/XSD from SCA
>> contributions, especially for the import/include directives. I would like
>> to share what I have so far to get your feedback.
>>
>> Let's assume we have the following artifacts ([1][2]).
>>
>> * helloworld-service.wsdl (definition) imports helloworld-interface.wsdl
>> * helloworld-interface.wsdl (inline schema) imports greeting.xsd
>> * greeting.xsd includes name.xsd
>>
>> For the import/include, we could have different ways to use the
>> "location" attribute for a WSDL <import>. Please note the SCA spec says
>> the explicit location attribute should be honored. If it's not present,
>> then we use the namespace-based resolution defined by SCA.
>>
>> 1. location="helloworld-interface.wsdl" (relative to the base document
>> where the import is defined)
>> 2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA
>> contribution)
>> 3. location="http://example.com/helloworld-interface.wsdl" (absolute URL
>> pointing to an external resource)
>> 4. location="" or location is not present: Use the namespace to resolve
>> the imported definition
>
> Is location="" even valid? I didn't think so.
I have clarified this on the follow-up e-mail. The location attribute is
required for <import.wsdl>. "" doesn't seem to be a valid URI.
The absence of schemaLocation for <xsd:import> and <xsd:include> are valid
though.
>
>>
>> We have two options here:
>>
>> a) Plugin a tuscany-specific resolver for WSDL4J
>> (javax.wsdl.xml.WSDLLocator) and XmlSchema
>> (org.apache.ws.commons.schema.resolver.URIResolver).
>>
>> This option can handle location case 1, 2 and 3. For 2, we probably need
>> some context from the contribution service.
>>
>> The difficulty is that both resolvers expect to take an InputSource. For
>> location case 4 (empty or not present), we don't have a corresponding
>> InputSource.
>
> I was going to respond with a long list of pros-cons for both options,
> then deleted all my comments to ask a simple question :). Why can't we
> return an InputSource for the contents of the imported document?
>
Well, for the import/include that can be resolved to a document, we return
the InputSource. I have said that it works for location case 1, 2 and 3. But
if the import/include only doesn't have the schemaLocation attribute, what
InputSource should we return?
A related question, for an artifact processer that loads multiple artifacts
following the import/include directives, how can we avoid the duplicate
loading? For example, we have a.wsdl imports b.wsdl, both a.wsdl and b.wsdl
are in the same contribution and they are processed by the WSDL artifact
processor. We probably don't want to load b.wsdl twice in this case.
>> To make WSDL4J happy, we might be able to provide a dummy InputSource
>> pointing to a byte array which contains the empty definition (AFAIK, null
>> InputSource won't work) and then resolve the imported definition by QName
>> during the resolve() phase.
>>
>> b) Disable the import/include resolving feature and re-link the related
>> artifacts by Tuscany
>>
>> There are two challenges:
>>
>> How to disable the aggressive resolving of import/include?
>> How to re-link the artifacts after the fragments are loaded?
>>
>> WSDL4J: We can disable the import processing by WSDL4J and then resolve
>> the imported artifacts in the different step. Some of the elements are
>> "undefined" and we have to navigate the WSDL4J model and resolve them.
>> During the procedure, we can use the location as a key to constrain the
>> scope of resolution.
>>
>> XmlSchema doesn't seem to have a way to disable the aggressive resolving.
>>
>> What do you guys think? Any opinions are welcome.
>>
>> Thanks,
>> Raymond
>>
>> [1]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/wsdl
>> [2]
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/xsd
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> 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: Resolving WSDL/XSD import/include for SCA contributions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Two questions inline.
Raymond Feng wrote:
> Hi,
>
> I'm working on the artifact processing of WSDL/XSD from SCA
> contributions, especially for the import/include directives. I would
> like to share what I have so far to get your feedback.
>
> Let's assume we have the following artifacts ([1][2]).
>
> * helloworld-service.wsdl (definition) imports helloworld-interface.wsdl
> * helloworld-interface.wsdl (inline schema) imports greeting.xsd
> * greeting.xsd includes name.xsd
>
> For the import/include, we could have different ways to use the
> "location" attribute for a WSDL <import>. Please note the SCA spec
> says the explicit location attribute should be honored. If it's not
> present, then we use the namespace-based resolution defined by SCA.
>
> 1. location="helloworld-interface.wsdl" (relative to the base document
> where the import is defined)
> 2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA
> contribution)
> 3. location="http://example.com/helloworld-interface.wsdl" (absolute
> URL pointing to an external resource)
> 4. location="" or location is not present: Use the namespace to
> resolve the imported definition
Is location="" even valid? I didn't think so.
>
> We have two options here:
>
> a) Plugin a tuscany-specific resolver for WSDL4J
> (javax.wsdl.xml.WSDLLocator) and XmlSchema
> (org.apache.ws.commons.schema.resolver.URIResolver).
>
> This option can handle location case 1, 2 and 3. For 2, we probably
> need some context from the contribution service.
>
> The difficulty is that both resolvers expect to take an InputSource.
> For location case 4 (empty or not present), we don't have a
> corresponding InputSource.
I was going to respond with a long list of pros-cons for both options,
then deleted all my comments to ask a simple question :). Why can't we
return an InputSource for the contents of the imported document?
> To make WSDL4J happy, we might be able to provide a dummy InputSource
> pointing to a byte array which contains the empty definition (AFAIK,
> null InputSource won't work) and then resolve the imported definition
> by QName during the resolve() phase.
>
> b) Disable the import/include resolving feature and re-link the
> related artifacts by Tuscany
>
> There are two challenges:
>
> How to disable the aggressive resolving of import/include?
> How to re-link the artifacts after the fragments are loaded?
>
> WSDL4J: We can disable the import processing by WSDL4J and then
> resolve the imported artifacts in the different step. Some of the
> elements are "undefined" and we have to navigate the WSDL4J model and
> resolve them. During the procedure, we can use the location as a key
> to constrain the scope of resolution.
>
> XmlSchema doesn't seem to have a way to disable the aggressive resolving.
>
> What do you guys think? Any opinions are welcome.
>
> Thanks,
> Raymond
>
> [1]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/wsdl
>
> [2]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/xsd
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org