Re: [regrep-comment] Comment about regrep-ws-profile (recursive processingof imports)

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

Andreas Veithen wrote:
> 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).
>   

The intended behavior is for all imported WSDL documents to be processed 
implicitly as if they had been explicitly submitted. This implies 
generating all ebRIM metadata defined by the specification for each 
imported WSDL document.

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

The original rationale for the requirement was to make sure that *ALL* 
of the WSDL document including its imports were *completely* cataloged 
and all structural relationships within and across WSDL documents were 
preserved and supported in discovery queries.

Experience from users of freebXML Registry supports your feedback above.

Perhaps a good resolution may be to relax the spec and say that:

   1. By default, imported and included documents MUST only be cataloged
      as slots on the ExtrinsicObject representing the WSDL document
      being cataloged. Specifically, the imported or included documents
      MUST NOT be processed by default.
   2. A WSDL document MAY be published before its dependency WSDL or XML
      Schema documents are published.
   3. If a process-imports option is specified via a transient slot then
      a registry MUST implicitly process any documents referenced via
      wsdl:import or xs:include elements

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

Above would be made difficult if we required support for process-imports 
as suggested in (3).
It seems (3) is quite important as a convenience and that we should 
retain it in some form.

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

I think we should consider style sheet vs. code an implementation issue
and focus on the requirements.

I agree with the following new requirements your email suggests:

* Ability to submit a WSDL document before its dependency WSDL and XMl 
Schema documents
* Support a WSDL document to be submitted by different user than its 
dependency WSDL and XMl Schema documents

I see the need to retain the support for following requirements:

* Metadata MUST keep track of inter-document dependencies at the 
document level by mapping wsdl:import, xsd:import and xs:include.
* Metadata MUST keep track of inter-document dependencies at the object 
level (service, port, binding, portType, type)

Above requirements would not easily be met by an XSLT based 
implementation but I feel they are important usability requirements.

What do you and others think?



> Best regards,
>
> Andreas Veithen
>
> This publicly archived list offers a means to provide input to the
> OASIS ebXML Registry TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: regrep-comment-subscribe@lists.oasis-open.org
> Unsubscribe: regrep-comment-unsubscribe@lists.oasis-open.org
> List help: regrep-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/regrep-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
>
>   


-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com