You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by Lawrence Mandel <lm...@ca.ibm.com> on 2008/04/02 17:45:46 UTC
Re: Assertions
Hi Peter,
Sorry for the delay in responding.
You've raised a good issue, one for which I don't think we currently have
a good answer. An alternate approach to the validation framework that we
had discussed involved having each assertion walk the tree itself to pick
up the elements it needs. In this approach the framework doesn't do the
walking but passes that responsibility on to the assertion classes. This
approach has the benefit of simplicity in adding and calling assertions as
each assertion is simply called in turn by the framework. The major
drawback is that each assertion has to walk the tree itself. However,
another nice benefit of this assertion is it will easily allow the
framework to implement dependencies among assertions so that an assertion
would only be run if all its dependencies have been met.
Thoughts?
Lawrence
"Peter Danielsen" <wi...@gmail.com>
03/26/2008 08:15 PM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Assertions
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 <wi...@gmail.com> 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 <KA...@uk.ibm.com> wrote:
Lawrence,
sorry, I just replied to Peter before I noticed you had already replied.
John Kaputin
Lawrence Mandel <lm...@ca.ibm.com> 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" <wi...@gmail.com>
> 03/19/2008 07:24 PM
> Please respond to
> woden-dev@ws.apache.org
>
>
> To
> woden-dev@ws.apache.org
> 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Assertions
Posted by Peter Danielsen <wi...@gmail.com>.
Lawrence,
I've opened Woden-207 for this issue. See
https://issues.apache.org/jira/browse/WODEN-207
Peter
On Wed, Apr 9, 2008 at 12:03 PM, Lawrence Mandel <lm...@ca.ibm.com> wrote:
> Thanks for the feedback Peter. It's good to know what you're thinking as
> as assertion author.
>
> I discussed this issue with John Kaputin during yesterday's Woden status
> call. While we don't yet have an answer as to how we will handle this case
> John (who wrote the validation framework) is going to take a look at the
> issue and see what he can come up with. In order to ensure this is handled
> can you open a Jira issue with your comments? We can then follow up in the
> Jira. You can access Woden's Jira at [1].
>
> [1] http://issues.apache.org/jira/browse/Woden
>
> Thanks again,
>
> Lawrence
>
>
>
>
> "Peter Danielsen" <wi...@gmail.com>
> 04/09/2008 12:07 PM
> Please respond to
> woden-dev@ws.apache.org
>
>
> To
> woden-dev@ws.apache.org
> cc
>
> Subject
> Re: Assertions
>
>
>
>
>
>
> Lawrence,
>
> Thanks for replying. I've just returned from vacation, so I apologize for
> not responding sooner.
>
> One concern I have with the dependency approach is that it adds another
> task to the assertion author's job. It's clear that they have to verify
> that the assertion is met, but I'm not sure I see the value an author gets
> by also having to identify and specify the assertions upon which it
> depends. It seems tedious and error-prone.
>
> Another concern is that if an assertion doesn't run because one of the
> assertions it depends upon has failed then we get into one of those
> situations from compilers of long ago: just when you think you've
> addressed the last error a new crop suddenly springs up because that error
> had "hidden" them. Maybe this isn't how you saw the dependency approach
> working, but I thought I should mention it anyway.
>
> I like the current approach of an assertion being handed the element it's
> supposed to check. While it's unavoidable for an assertion to walk the
> tree "up", in an ad-hoc fashion, to perform cross-checks with ancestors or
> relatives (e.g. a binding message reference with its interface message
> reference), it seems like checking assertions on descendants is something
> common to all elements and should be taken care of by the framework. This
> could be done in WSDLValidator, a utility class, or in an abstract class
> implementation of Assertion. Having it in WSDLValidator ensures that all
> elements will be visited and removes another task from an assertion
> author's job. I also think that the validation phase would run quicker
> when the top-down tree walking is done in one place, rather than being
> done by each assertion. I'm guessing that that might really add up on a
> large document if each assertion had to do it starting from the top
> <description>.
>
> Hope this is helpful.
>
> Peter
>
> On Wed, Apr 2, 2008 at 10:45 AM, Lawrence Mandel <lm...@ca.ibm.com>
> wrote:
> Hi Peter,
>
> Sorry for the delay in responding.
>
> You've raised a good issue, one for which I don't think we currently have
> a good answer. An alternate approach to the validation framework that we
> had discussed involved having each assertion walk the tree itself to pick
> up the elements it needs. In this approach the framework doesn't do the
> walking but passes that responsibility on to the assertion classes. This
> approach has the benefit of simplicity in adding and calling assertions as
> each assertion is simply called in turn by the framework. The major
> drawback is that each assertion has to walk the tree itself. However,
> another nice benefit of this assertion is it will easily allow the
> framework to implement dependencies among assertions so that an assertion
> would only be run if all its dependencies have been met.
>
> Thoughts?
>
> Lawrence
>
>
>
>
>
> "Peter Danielsen" <wi...@gmail.com>
> 03/26/2008 08:15 PM
> Please respond to
> woden-dev@ws.apache.org
>
>
> To
> woden-dev@ws.apache.org
> cc
>
> Subject
> Re: Assertions
>
>
>
>
>
>
> 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 <wi...@gmail.com> 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 <KA...@uk.ibm.com> wrote:
> Lawrence,
> sorry, I just replied to Peter before I noticed you had already replied.
>
> John Kaputin
>
>
> Lawrence Mandel <lm...@ca.ibm.com> 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" <wi...@gmail.com>
> > 03/19/2008 07:24 PM
> > Please respond to
> > woden-dev@ws.apache.org
> >
> >
> > To
> > woden-dev@ws.apache.org
> > 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: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
>
>
>
>
>
>
> 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
Re: Assertions
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
Thanks for the feedback Peter. It's good to know what you're thinking as
as assertion author.
I discussed this issue with John Kaputin during yesterday's Woden status
call. While we don't yet have an answer as to how we will handle this case
John (who wrote the validation framework) is going to take a look at the
issue and see what he can come up with. In order to ensure this is handled
can you open a Jira issue with your comments? We can then follow up in the
Jira. You can access Woden's Jira at [1].
[1] http://issues.apache.org/jira/browse/Woden
Thanks again,
Lawrence
"Peter Danielsen" <wi...@gmail.com>
04/09/2008 12:07 PM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Assertions
Lawrence,
Thanks for replying. I've just returned from vacation, so I apologize for
not responding sooner.
One concern I have with the dependency approach is that it adds another
task to the assertion author's job. It's clear that they have to verify
that the assertion is met, but I'm not sure I see the value an author gets
by also having to identify and specify the assertions upon which it
depends. It seems tedious and error-prone.
Another concern is that if an assertion doesn't run because one of the
assertions it depends upon has failed then we get into one of those
situations from compilers of long ago: just when you think you've
addressed the last error a new crop suddenly springs up because that error
had "hidden" them. Maybe this isn't how you saw the dependency approach
working, but I thought I should mention it anyway.
I like the current approach of an assertion being handed the element it's
supposed to check. While it's unavoidable for an assertion to walk the
tree "up", in an ad-hoc fashion, to perform cross-checks with ancestors or
relatives (e.g. a binding message reference with its interface message
reference), it seems like checking assertions on descendants is something
common to all elements and should be taken care of by the framework. This
could be done in WSDLValidator, a utility class, or in an abstract class
implementation of Assertion. Having it in WSDLValidator ensures that all
elements will be visited and removes another task from an assertion
author's job. I also think that the validation phase would run quicker
when the top-down tree walking is done in one place, rather than being
done by each assertion. I'm guessing that that might really add up on a
large document if each assertion had to do it starting from the top
<description>.
Hope this is helpful.
Peter
On Wed, Apr 2, 2008 at 10:45 AM, Lawrence Mandel <lm...@ca.ibm.com>
wrote:
Hi Peter,
Sorry for the delay in responding.
You've raised a good issue, one for which I don't think we currently have
a good answer. An alternate approach to the validation framework that we
had discussed involved having each assertion walk the tree itself to pick
up the elements it needs. In this approach the framework doesn't do the
walking but passes that responsibility on to the assertion classes. This
approach has the benefit of simplicity in adding and calling assertions as
each assertion is simply called in turn by the framework. The major
drawback is that each assertion has to walk the tree itself. However,
another nice benefit of this assertion is it will easily allow the
framework to implement dependencies among assertions so that an assertion
would only be run if all its dependencies have been met.
Thoughts?
Lawrence
"Peter Danielsen" <wi...@gmail.com>
03/26/2008 08:15 PM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Assertions
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 <wi...@gmail.com> 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 <KA...@uk.ibm.com> wrote:
Lawrence,
sorry, I just replied to Peter before I noticed you had already replied.
John Kaputin
Lawrence Mandel <lm...@ca.ibm.com> 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" <wi...@gmail.com>
> 03/19/2008 07:24 PM
> Please respond to
> woden-dev@ws.apache.org
>
>
> To
> woden-dev@ws.apache.org
> 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Assertions
Posted by Peter Danielsen <wi...@gmail.com>.
Lawrence,
Thanks for replying. I've just returned from vacation, so I apologize for
not responding sooner.
One concern I have with the dependency approach is that it adds another task
to the assertion author's job. It's clear that they have to verify that the
assertion is met, but I'm not sure I see the value an author gets by also
having to identify and specify the assertions upon which it depends. It
seems tedious and error-prone.
Another concern is that if an assertion doesn't run because one of the
assertions it depends upon has failed then we get into one of those
situations from compilers of long ago: just when you think you've addressed
the last error a new crop suddenly springs up because that error had
"hidden" them. Maybe this isn't how you saw the dependency approach
working, but I thought I should mention it anyway.
I like the current approach of an assertion being handed the element it's
supposed to check. While it's unavoidable for an assertion to walk the tree
"up", in an ad-hoc fashion, to perform cross-checks with ancestors or
relatives (e.g. a binding message reference with its interface message
reference), it seems like checking assertions on descendants is something
common to all elements and should be taken care of by the framework. This
could be done in WSDLValidator, a utility class, or in an abstract class
implementation of Assertion. Having it in WSDLValidator ensures that all
elements will be visited and removes another task from an assertion author's
job. I also think that the validation phase would run quicker when the
top-down tree walking is done in one place, rather than being done by each
assertion. I'm guessing that that might really add up on a large document
if each assertion had to do it starting from the top <description>.
Hope this is helpful.
Peter
On Wed, Apr 2, 2008 at 10:45 AM, Lawrence Mandel <lm...@ca.ibm.com> wrote:
> Hi Peter,
>
> Sorry for the delay in responding.
>
> You've raised a good issue, one for which I don't think we currently have
> a good answer. An alternate approach to the validation framework that we
> had discussed involved having each assertion walk the tree itself to pick
> up the elements it needs. In this approach the framework doesn't do the
> walking but passes that responsibility on to the assertion classes. This
> approach has the benefit of simplicity in adding and calling assertions as
> each assertion is simply called in turn by the framework. The major
> drawback is that each assertion has to walk the tree itself. However,
> another nice benefit of this assertion is it will easily allow the
> framework to implement dependencies among assertions so that an assertion
> would only be run if all its dependencies have been met.
>
> Thoughts?
>
> Lawrence
>
>
>
>
>
> "Peter Danielsen" <wi...@gmail.com>
> 03/26/2008 08:15 PM
> Please respond to
> woden-dev@ws.apache.org
>
>
> To
> woden-dev@ws.apache.org
> cc
>
> Subject
> Re: Assertions
>
>
>
>
>
>
> 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 <wi...@gmail.com> 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 <KA...@uk.ibm.com> wrote:
> Lawrence,
> sorry, I just replied to Peter before I noticed you had already replied.
>
> John Kaputin
>
>
> Lawrence Mandel <lm...@ca.ibm.com> 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" <wi...@gmail.com>
> > 03/19/2008 07:24 PM
> > Please respond to
> > woden-dev@ws.apache.org
> >
> >
> > To
> > woden-dev@ws.apache.org
> > 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: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
>
>
>
>
>
>
> 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>