Differences between revisions 9 and 10
Revision 9 as of 2008-02-08 16:11:34
Size: 6232
Editor: JohnKaputin
Comment: specified jira woden-62
Revision 10 as of 2009-09-20 22:48:07
Size: 6232
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

Woden Validation API

This page captures the goals of the Woden validation API and potential options for implementation that will achieve the goals.

Issue captured in Jira by WODEN-62.

Goals of the Validation API

  1. Enable validation with any implementation of the Woden API
  2. Enable 3rd parties to add new validation assertions to Woden
  3. Allow for specification of dependencies among assertions for the benefit of
    • Performance (only run assertions that have a chance to pass)
    • User experience (only show one error message per error)

Goal 1: Enable validation with any implementation of the Woden API

This goal requires that the validation API and assertions only reference Woden's API. No references can be made to Woden's implementation classes.

Goal 2: Enable 3rd parties to add new validation assertions to Woden

This goal requires a public assertion interface that adopters can implement and contribute to Woden.

The following are two potential assertion interfaces with pros and cons:

  1. public Interface Assertion {
      public void validate(Description desc, ErrorReporter errorReporter);
    }
    • Pros:
      • Strongly typed
      • One interface for every assertion
    • Cons:
      • Every assertion must traverse the WSDL tree (performance)
  2. public Interface Assertion {
      public void validate(Object wsdlObj, Description desc, ErrorReporter errorReporter);
    }
    • Pros:
      • Weak typing allows the specific WSDL object the assertion requires to be passed (the assertion does not have to walk the tree - good for performance)
    • Cons:
      • Each assertion must declare the type that it asserts
      • Each assertion must cast to the correct type
      • The description component must still be passed to allow referencing elements other than the element's children

Goal 3: Allow for specification of dependencies among assertions

While it's possible to check every assertion when validating a WSDL document there are two benefits of only checking assertions whose prerequisites have been met:

  • Performance (only run assertions that have a chance to pass)
  • User experience (only show one error message per error)

In order to specify an assertion's requirement a list of dependent assertions will need to be provided. In the case of WSDL 2.0 assertions, a dependency matrix does not exist so one will need to be created by analyzing the assertions specified in the specification. Note that the requirement for specifying dependent assertions requires that each assertion register with a unique id. Unique ids are easy to maintain for the WSDL 2.0 specification (which provides unique identifiers). Duplicate id definitions may be specified by extenders. One potential solution for this problem is to namespace or otherwise qualify assertion ids. This will add complexity to the API and to Woden and does not guarantee that extenders will not specify the same namespace. This problem may be solved largely be good documentation about assertion id convention.

Assertion classes need to be specified to Woden in order for Woden to pick them up and use them for validation. Dependencies among assertions can be specified at the same time. The following are two possible ways to specify an assertion with Woden.

  1. An assertion can be registered via a method on ExtensionRegistry such as

    public void registerAssertion(IAssertion assertion, String id, String dependencies);

    where id is the assertion id and dependencies is a comma separated list of assertion ids for assertions that this assertion depends.

    • Pros:
      • Allows for multiple instances of the WSDL 2.0 validating parser to be configured differently within the same runtime
      • This approach makes it very clear what assertions have been registered as they must all be registered manually (note that Woden can register all of the WSDL 2.0 assertions internally so clients will not have to reference all of the Woden assertion classes)
    • Cons:
      • This approach requires work by clients as they must manually register all extensions
  2. Assertions can be automatically discovered by Woden at runtime. Automatic discovery will still require some way of specifying dependencies. Dependencies can be specified using an Assertion XML file (such as the service XML file Axis2 uses for registering services):

    <assertions xmlns="http://ws.apache.org/woden/assertion">
      <assertion id="ASSERTION_ID" 
                 class="org.apache.woden.internal.validation.Assertion" 
                 depends="ASSERTION_ID1,ASSERTION_ID2"/>
    </assertions>

    Alternatively dependencies can be worked into the Assertion interface (by having a getDependencies() method) such as:

    public String getDependencies();

An alternative approach to specifying assertions is to have consumers or extenders specify the execution order of assertions. This approach was presented on a Woden status call. The primary limitation of this approach is that Woden will support multiple extenders. It is not reasonable to expect these extenders to communicate among themselves to resolve the runtime order of assertions. Because it is not reasonable for expect extenders to speak the burden must fall on Woden consumers. This is a significant burden as it requires intimate knowledge of WSDL 2.0 and extension assertions, knowledge Woden consumers are not expected to have. This would likely be a serious obstacle to Woden's adoption.

Use with OSGi and Eclipse's Plug-in Registry

All of the approaches defined in goals 2 and 3 above should fit nicely with the OSGi bundle mechanism and the Eclipse plug-in registry. In the case of bundles, extensions can register with Woden directly after declaring a dependency. In the case of the plug-in registry, Woden can define an extension point for contributing assertions, the use of which might look like the following:

<plugin>
  <extension point="org.apache.woden.assertion">
    <assertion id="ASSERTION_ID"
               class="org.apache.woden.internal.validation.Assertion"
               depends="ASSERTION_ID1,ASSERTION_ID2"/>
  </extension>
</plugin>

FrontPage/Woden/ValidationAPI (last edited 2009-09-20 22:48:07 by localhost)