ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "FrontPage/Woden/ValidationAPI" by LawrenceMandel
Date Thu, 24 Jan 2008 17:49:10 GMT
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: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message