This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Resolving WSDL and XSD artifacts
Skip to end of metadata
Go to start of metadata

How to resolve WSDL and XSD artifacts in SCA?

The Tuscany mailing list discussion thread

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20806.html

A simple usage scenario

1) helloworld.composite

<service name="HellloWorld">
<interface.wsdl interface="http://helloworld#wsdl.interface(HelloWorld)"/>
<binding.ws wsdlElement="http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)" />
</service>

The composite model references WSDL portTypes and service/port by QName.

2) wsdl/helloworld-service.wsdl (defines Service/Port: HelloWorldService/HelloWorldSoapPort)

<wsdl:import location="helloworld-interface.wsdl" namespace="http://helloworld"/>

3) wsdl/helloworld-interface.wsdl (defines PortType: HelloWorld)

<wsdl:types>
<schema ...>
<import namespace="http://greeting" schemaLocation="../xsd/greeting.xsd" />
...
</schema>
</wsdl:types>

4) xsd/greeting.xsd (defines the Greeting complex type)

The resolving algorithm

The SCA assembly spec 1.0 has the following statement:

Loading artifacts on demand when they are referenced by the composite

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.