Comment about regrep-ws-profile (recursive processing of imports)

["Andreas Veithen" <andreas.veithen@gmail.com>]

Dear all,

I have a comment about the following requirement in section 7.3 of the
ebXML Registry Profile for Web Services specification, version 1.0
draft 3:

"The input WSDL file may contain imports of other WSDL files. The WSDL
cataloging service MUST implicitly process WSDL documents that have
been imported within the explicitly submitted WSDL document as defined
in ??."

From the requirements in sections 7.4.2 to 7.4.7 it is clear that
"process" in this context means generating metadata also for the WSDL
documents imported by the explicitly submitted WSDL document. However
it is not clear whether those WSDL documents should also be added
themselves as ExtrinsicObjects or ExternalLinks (and how the
cataloging service should behave if these documents already exist in
the repository).

More importantly we have a use case where the behavior required by the
specifications will lead to difficulties in terms of SOA governance.
The use case is as follows: Among partners (companies participating)
in our project we have agreed on a common port type definition
specified in a WSDL document and a set of XML schema files. This port
type must be implemented by services provided by modules from three
different partners A, B and C. These services are then consumed by a
module implemented by a fourth partner D. We envisage to use an ebXML
registry to allow D's module to easily discover the services provided
by A, B and C. We would then also use the repository functionality to
manage the different WSDL and XSD artifacts.

A, B and C provide WSDL documents that all import the common WSDL
file. Obviously, each of A, B and C should be able to add or replace
his own WSDL files. On the other hand, the common WSDL file can only
be replaced by a new version if an agreement on the modifications is
reached by all four partners. This artifact (and the related XML
schema documents) would therefore have to be protected such that A, B
or C cannot change it on its own initiative. The behavior described by
the specifications however implies that every time A, B or C updates
his WSDL file, (the metadata extracted from) the common WSDL would
also get replaced, violating this policy.

What were actually the reasons for requiring the WSDL cataloging
service to recursively process imported documents? My feeling is that
by dropping this requirement, ebXML could satisfy a larger range of
use cases more easily. The only implication is that in cases where
there are imports, the different artifacts need to be added
separately. This might in some cases be tedious, but in return this
would give the user a higher level of control as required for more
complex scenarios.

Dropping this requirement could also have another major advantage. As
far as I can see, all the metadata described by the specification can
be extracted from the WSDL without knowledge of the content of any
imported documents. This means that this part of the specification
could be implemented using the canonical XML cataloging service and an
appropriate XSLT stylesheet. I successfully did this to work around
some other problems in the implementation of the WSDL cataloging
service in OMAR. Note however that this conclusion depends on the
exact interpretation of the concept of "imported namespaces" in
section 7.4.1. If this is to be interpreted as the namespaces
appearing in wsdl:import elements in the submitted WSDL, then this
information can indeed be extracted using a stylesheet.

Best regards,

Andreas Veithen