Resolving references in S-RAMP (e.g. WSDL imports)
eric.wittmann Mar 4, 2013 11:29 AMAn issue that still needs to be solved in the S-RAMP repository is how to resolve references between artifacts. For the purpose of this post I will use WSDL as an example, but the problem is generic across multiple artifact types (any artifact type that can have references to other artifact instances).
As you know, a WSDL may refer to another WSDL (import, include, redefine). Various systems (tooling, runtime systems, etc) have different strategies for resolving these external references. The purpose of this post is to discuss the resolution strategy in S-RAMP.
For context, here is a typical import statement from a WSDL:
<import namespace="http://example.com/stockquote/schemas" location="../common/stockquote.xsd"/>
For tooling, resolution is usually straightforward - just follow the location as though it were a file path. In runtime systems, the strategy usually varies, but often involves a registry of resources keyed by namespace.
The S-RAMP repository may contain multiple artifacts that match the given namespace (but with different version numbers). When adding a WSDL, we need to implement an appropriate strategy for resolving the WSDL imports/includes.
Straw Man Proposal: Resolution should be done using the namespace (look up a WSDL artifact in the repo by its targetNamespace property). If multiple artifacts are found, use the one most recently added (assuming it is the one with the highest version number). I don't think version number can be used, given that the version property is free-form.
An additional consideration is scoping. If a WSDL is being added as part of a batch, then perhaps resolution should happen within that scope. For instance, if an S-RAMP package (spec-defined ZIP format) is being added, and a number of WSDLs and Schemas are included in that package, then we should first attempt to resolve references by looking in the package (first by location path and then by namespace).
I'm considering addig a "linker" phase to the core S-RAMP repository that would follow the "deriver" phase. This would allow content to be derived into the repository first, and then relationships between artifacts could be resolved after.