W3C home > Mailing lists > Public > www-ws-desc@w3.org > December 2006

RE: WSDL 2.0 component model tests

From: Jonathan Marsh <jonathan@wso2.com>
Date: Tue, 5 Dec 2006 10:02:21 -0800
To: "'Arthur Ryman'" <ryman@ca.ibm.com>
Cc: <www-ws-desc@w3.org>
Message-ID: <006301c71897$83ddfbc0$3401a8c0@DELLICIOUS>
I went around on that a couple of times, but it made most sense to me to
only list the extensions that are required by the test in the test metadata.
For instance, an implementation that didn't support the HTTP binding, would
still be able to run the WSAddressing-1G test.


The implementations.xml file lists all the extensions supported by a
particular implementation, and if the TestMetadata indicates an extension is
required that the implementation doesn't support, it will fill in the table
with an "unsupported extension".  For instance here's wsdl-xslt's
implementation manifest.


      <implementation name="WSDL XSLT" results-folder="wsdl-xslt">

            <supports extension="http://www.w3.org/2006/01/wsdl-extensions"

            <supports extension="http://www.w3.org/2006/01/wsdl/http"

            <supports extension="http://www.w3.org/2006/01/wsdl/rpc"

            <supports extension="http://www.w3.org/2006/01/wsdl/soap"

            <supports extension="http://example.org/unknown-wsdl-extension"
engaged="always"/> <!-- assumes it's a dummy extension -->

            <supports extension="http://www.w3.org/2006/05/addressing/wsdl"



There are a few interesting things here.  You can see that wsdl-xslt claims
to support the unknown-wsdl-extension (so does Woden).  This isn't really
true, unless the definition of unknown-wsdl-extension paradoxically happens
to be "no change to component model", as I've assumed here.  Canon doesn't
support this extension, as indicated by the fact that they refuse to
generate any interchange results for a document that requires this


As you recall, Echo-2G, which introduces this extension, was cloned into the
Bad documents bucket (should fail validation if the extension is really
unknown), but for test purposes I left a copy in the Good documents to test
and illustrate the extension matching logic.  We might want to get rid of
this testcase and remove the claims that our extensions support it.


Implementations.xml also has an attribute engaged="always|on demand" which
is not used at present, although it describes the capabilities of the
implementations accurately, as I changed my build process to engage the
WS-Addressing extension for the one test that needs it (manually, rather
than based on the implementations.xml metadata, at this point).


As I think I mentioned, the ability to mix and match extension support in an
implementation with a testcase isn't fully generalized.  Since our 3
implementations all support virtually identical sets of implementations, we
maintain only a single set of Baselines rather than a separate baseline for
each combination of supported extensions.  That's good enough for now, but
if I ran my stylesheet with WS-Addressing engaged always, I'd end up with a
different set of results (with {action} properties on each operation) that
would hopefully be correct but not match the current Baseline.


Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com



From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Monday, December 04, 2006 8:10 PM
To: Jonathan Marsh
Cc: [WS-A]; www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: WSDL 2.0 component model tests



Nice work. I see you've made creative use of the <Input> element to specify
the extensions: 

<Input role="root">wsaTestService2.wsdl</Input> 
<Input role="required-extension">http://www.w3.org/2006/01/wsdl/soap</Input>


Why are you explicitly specifying SOAP and not the other extensions from
Part 2? I think we should be consistent, i.e. assume the presence of ALL the
Part 2 extensions OR explicitly list them. BTW, Woden cannot selectively
turn off the other extensions at present. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca 

"Jonathan Marsh" <jonathan@wso2.com> 
Sent by: www-ws-desc-request@w3.org 

12/01/2006 07:10 PM 


"[WS-A]" <public-ws-addressing@w3.org> 




WSDL 2.0 component model tests




I've updated my WSDL 2.0 "implementation" to handle WS-Addressing
Wsdl-xslt is a stylesheet that transforms WSDL documents to a so-called
"interchange" format which is a direct, and verbose, serialization of the
component model.  It's used to verify that WSDL 2.0 parsers are acting
consistently.  My stylesheet provides a baseline against which to compare
other, more sophisticated, implementations (as well as putting another set
of implementer eyes on the spec.) 
With the WS-Addressing extension support, one can browse the component model
directly and verify that WS-Addressing properties were included
I also generated a WSDL 2.0 form of one of the WS-Addressing WSDL tests to
work with [1].  The component model results can be viewed at [2]. 
I hope this encourages other implementations (e.g. Woden ;-) of the
WS-Addressing extensions to WSDL 2.0. 
As the WS-Addressing WG develops WSDL 2.0 test cases, please submit them to
the WSDL 2.0 test suite as well.  In addition, we're close to getting an
automated system in place for analyzing message logs wrt a WSDL 2.0
document.  It is easy to imagine extending that framework to handle
WS-Addressing extensions as well (e.g. verify that the wsa:Action in the
message conforms to the {action} property in the component model.) 
Jonathan Marsh -  <http://www.wso2.com/> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com/> http://auburnmarshes.spaces.live.com

Received on Tuesday, 5 December 2006 18:02:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:03 UTC