Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by LawrenceMandel: http://wiki.apache.org/ws/FrontPage/Woden/ValidationAPI ------------------------------------------------------------------------------ == 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. + - Assertion classes need to be specified to Woden in order for Woden to pick them up and use them for validation. The following are two possible ways to specify an assertion with Woden. + 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); @@ -63, +69 @@ 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> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
