John, Lawrence,
I looked at the validation structure some more and have a few comments and
suggestions.
It looks like the following steps are involved:
a. Select a target to validate
b. Determine assertion selection criteria (target's role, e.g. "
Interface.class")
c. Determine a set of assertions meeting the criteria
d. For each assertion in set
Check target against assertion
(i.e. WSDLValidator.checkAssertions calls assertion.validate(target,
wodenContext))
Steps a-d are all done by WSDLValidator.
What if an assertion needs to do the same process on its target's
descendants? Imagine an extension element with descendants that have their
own assertions. Those descendant element assertions can be registered
through the ExtensionRegistry method, but they won't be checked by
WSDLValidator since it doesn't know the tree structure below the required
WSDL components and elements. An extension element assertion must then walk
the tree of its element's descendants to check their assertions.
It's possible to keep all the tree walking in WSDLValidator by including a
target's extension element children found by looking at
target.getExtensionProperties().getContent(). That leaves the question of
how to do (b). It would be nice if there was a way to do it automatically
within WSDLValidator.
One way is to have a new WSDLValidator method:
private void checkAssertions(Object target)
that looks at the Java interfaces implemented by a target's class to see
which role's it's declared to play. For each interface, the new method
calls the existing checkAssertions(Class, Object) method. This would ensure
that the caller doesn't omit a (b) criteria. This method can also include
the extension tree walking mentioned above and can be called by "validate"
directly.
Some advantages of this approach:
1. WSDLValidator takes care of tree-walking to visit all required elements
and all extensions. This includes extensions to extensions.
2. Extension assertions are registered for the classes they need to check,
rather than a required element that's an ancestor of the target class.
3. Extension assertions become simpler because they don't need to walk the
tree from a required element down to their extension.
4. Keeping the tree-walking in WSDLValidator results in less redundant code
in different assertions that apply to the same extension.
5. Unit tests are smaller and faster because some assertions can be less
dependent on an extension's context.
Some disadvantages:
1. The reliance on reflection may have a performance impact.
2. If an assertion needs to walk its element's descendants, it still won't
be able to take advantage of the WSDLValidator's assertion registry. It
will have to find the assertions on its own.
I know the version of WSDLValidator that's currently in trunk isn't complete
and maybe you've thought of these issues, but in case you haven't I hope
these suggestions are useful. I have a version of this that works with some
extension-related assertions I've created.
Peter
On Thu, Mar 20, 2008 at 8:10 AM, Peter Danielsen <[EMAIL PROTECTED]> wrote:
> John, Lawrence,
> Thank you for your replies. I'll try to take a deeper look at assertion
> implementation and see how it goes.
>
> Thanks for the links to the Wiki pages. The one on WSDLExtensions has
> been very useful to me in the past, but it could benefit from an update (it
> still says that the HTTP binding has not been done). It would also be
> valuable for it to mention the ExtensionRegistrar mechanism. That will be
> helpful for the next person who's interested in extending Woden.
>
> Thanks for all your efforts.
>
> Peter
>
>
> On Thu, Mar 20, 2008 at 5:12 AM, John Kaputin <[EMAIL PROTECTED]> wrote:
>
> > Lawrence,
> > sorry, I just replied to Peter before I noticed you had already replied.
> >
> > John Kaputin
> >
> >
> > Lawrence Mandel <[EMAIL PROTECTED]> wrote on 20/03/2008 00:51:18:
> >
> > > Hi Peter,
> > >
> > > The validation framework is indeed at an early stage and we're working
> > out
> > > some details while implementing assertions. I think your statement
> > about
> >
> > > assertions that require checks of multiple elements int he WSDL
> > document
> >
> > > is correct. Your example with binding and interface is my current
> > thinking
> > > about these types of assertions.
> > >
> > > I captured some of our initial ideas about the validation API that
> > we're
> >
> > > working off of at [1]. Information about Woden extensions other than
> > the
> >
> > > validation extension can be found at [2].
> > >
> > > Does this information answer your questions?
> > >
> > > [1] http://wiki.apache.org/ws/FrontPage/Woden/ValidationAPI
> > > [2] http://wiki.apache.org/ws/FrontPage/Woden/WSDLExtensions
> > >
> > > Lawrence
> > >
> > >
> > >
> > >
> > > "Peter Danielsen" <[EMAIL PROTECTED]>
> > > 03/19/2008 07:24 PM
> > > Please respond to
> > > [email protected]
> > >
> > >
> > > To
> > > [email protected]
> > > cc
> > >
> > > Subject
> > > Assertions
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > I'm curious about the stability of the Assertion design in Woden.
> > >
> > > I've been looking at it from the point of view of an extension and I
> > think
> > > this is the procedure:
> > >
> > > 1. Create a class that implements
> > > org.apache.woden.wsdl20.validation.Assertion
> > > for each class that is affected by an assertion.
> > > a. Implement "getId()"
> > > b. Implement "validate(Object, WodenContext)"
> > >
> > > 2. Register each Assertion class by calling
> > > ExtensionRegistry.registerAssertion passing an instance of the
> > Assertion
> >
> > > class and the affected class. This would likely be done from an
> > > ExtensionRegistrar.
> > >
> > > That seems reasonable, but the reason I asked about the stability is
> > that
> > > when I look at the validate method of
> > > org.apache.woden.internal.wsdl20.validation.WSDLValidator
> > > I see that it's not checking assertions on Binding or Service
> > elements.
> > > Their absence made me wonder whether this is still in an early design
> > > stage?
> > >
> > > Also, I'm assuming that cross-checks between elements (e.g.
> > <interface>
> > > and <binding> ) will be the responsibility of the "more detailed"
> > element
> > > (<binding> in this case) and that that element's Assertion may require
> > > navigation of the containing elements to do its work. Is that
> > correct?
> > >
> > > Any references or explanations on the conventions and use of
> > Assertions
> > > would be very useful.
> > >
> > > Thanks,
> > >
> > > Peter
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
