Loading ...
Sorry, an error occurred while loading the content.

ANNOUNCEMENT: W3C Web Services Addressing Interoperability Event

Expand Messages
  • Mark Nottingham
    The W3C Web Services Addressing Working Group plans to hold an Interoperability Event to test the Web Services Addressing family of W3C Technical Reports in
    Message 1 of 4 , Dec 5, 2005
    • 0 Attachment
      The W3C Web Services Addressing Working Group plans to hold an
      Interoperability Event to test the Web Services Addressing family of
      W3C Technical Reports in January 2006, and invites participation from
      interested parties who have an implementation of one or more of the
      following specifications;

      - Web Services Addressing 1.0 - Core, 2005-08-17 Candidate
      Recommendation [1]
      - Web Services Addressing 1.0 - SOAP Binding, 2005-08-17 Candidate
      Recommendation [2]
      - Web Services Addressing 1.0 - WSDL Binding Editors' Draft) [3]

      * Technical Plans and Requirements

      Testing will focus on satisfying the Candidate Recommendation
      criteria for the Core and SOAP Binding documents, as expressed in the
      Test Suite [4]. If time permits, additional testing may take place.

      It is expected that you will bring a laptop computer capable of
      networking wirelessly using 802.11b (preferred) or through Ethernet,
      with an instance of your implementation ready for testing.

      Interested parties should join the public-ws-addressing-tests@...
      mailing list [5], where the test plan and other specifics will be
      discussed. Note that testing may take place against subsequent
      revisions to the documents, and that the test suite is not yet final.

      * Logistics

      The event will take place at the Opus Hotel [6] in Vancouver, BC
      Canada on January 17th and 18th, 2006 from 9am until 5pm each day.
      Note that a special rate is available at the hotel; more information
      will be provided after registration.

      * Registration

      Please register using the following form:
      http://www.w3.org/2002/09/wbs/1/addr-event/

      If your organisation is not a W3C Member, please request an account
      first, at:
      http://cgi.w3.org/MemberAccess/Public

      Registration closes on 2006-01-03.

      Kind Regards,

      Mark Nottingham, W3C Web Services Addressing Working Group Chair
      Hugo Haas, W3C Web Services Addressing Working Group Team Contact


      1. http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
      2. http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/
      3. http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-
      wsdl.html?content-type=text/html;%20charset=utf-8
      4. http://www.w3.org/2002/ws/addr/testsuite/
      5. http://lists.w3.org/Archives/Public/public-ws-addressing-tests/
      6. http://www.opushotel.com/
    • Steve Loughran
      ... Mark, I see we have a whole twenty test cases that define the required behaviour of a WS-A stack. Above and beyond those 20 test cases, if two stacks fail
      Message 2 of 4 , Dec 6, 2005
      • 0 Attachment
        On 12/6/05, Mark Nottingham <mark.nottingham@...> wrote:
        > The W3C Web Services Addressing Working Group plans to hold an
        > Interoperability Event to test the Web Services Addressing family of
        > W3C Technical Reports in January 2006, and invites participation from
        > interested parties who have an implementation of one or more of the
        > following specifications;
        >
        > - Web Services Addressing 1.0 - Core, 2005-08-17 Candidate
        > Recommendation [1]
        > - Web Services Addressing 1.0 - SOAP Binding, 2005-08-17 Candidate
        > Recommendation [2]
        > - Web Services Addressing 1.0 - WSDL Binding Editors' Draft) [3]
        >
        > * Technical Plans and Requirements
        >
        > Testing will focus on satisfying the Candidate Recommendation
        > criteria for the Core and SOAP Binding documents, as expressed in the
        > Test Suite [4]. If time permits, additional testing may take place.
        >
        > It is expected that you will bring a laptop computer capable of
        > networking wirelessly using 802.11b (preferred) or through Ethernet,
        > with an instance of your implementation ready for testing.
        >
        > Interested parties should join the public-ws-addressing-tests@...
        > mailing list [5], where the test plan and other specifics will be
        > discussed. Note that testing may take place against subsequent
        > revisions to the documents, and that the test suite is not yet final.
        >
        > * Logistics
        >
        > The event will take place at the Opus Hotel [6] in Vancouver, BC
        > Canada on January 17th and 18th, 2006 from 9am until 5pm each day.
        > Note that a special rate is available at the hotel; more information
        > will be provided after registration.
        >
        > * Registration
        >
        > Please register using the following form:
        > http://www.w3.org/2002/09/wbs/1/addr-event/
        >
        > If your organisation is not a W3C Member, please request an account
        > first, at:
        > http://cgi.w3.org/MemberAccess/Public
        >
        > Registration closes on 2006-01-03.
        >
        > Kind Regards,
        >
        > Mark Nottingham, W3C Web Services Addressing Working Group Chair
        > Hugo Haas, W3C Web Services Addressing Working Group Team Contact
        >
        >
        > 1. http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
        > 2. http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/
        > 3. http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-
        > wsdl.html?content-type=text/html;%20charset=utf-8
        > 4. http://www.w3.org/2002/ws/addr/testsuite/
        > 5. http://lists.w3.org/Archives/Public/public-ws-addressing-tests/
        > 6. http://www.opushotel.com/

        Mark,


        I see we have a whole twenty test cases that define the required
        behaviour of a WS-A stack.

        Above and beyond those 20 test cases, if two stacks fail to
        interoperate, who is going to be at fault? In the absence of any
        broad, normative test suite, its going to devolve to blame assigment
        or the more agile/niche stacks having to adapt to the de-facto
        standards set by the mainstream implementations. This is
        unsatisfactory, as the normative specification will end up being
        supplemented by the informal rules as how to work with WSA-3.0,
        indigo, Axis1.4, etc.

        Have the WS-A WG group noticed that inconsistent implementations of
        the spec is a inevitable outcome of having no test suite developed
        alongside the specification, and do they or the W3C plan to change
        their process to be more test-driven in future?

        -steve
      • Paul Downey
        Hi Steve! ... The test suite is still a matter of work in progress, and the Working Group invites people to contribute more test cases:
        Message 3 of 4 , Dec 6, 2005
        • 0 Attachment
          Hi Steve!

          > I see we have a whole twenty test cases that define the required
          > behaviour of a WS-A stack.

          The test suite is still a matter of work in progress, and the
          Working Group invites people to contribute more test cases:

          http://www.w3.org/2002/ws/addr/testsuite/#contributing

          However, the primary focus of 'CR' is to prove it is possible
          to build implementations based up in the specifications, but
          most importantly, that it enjoys support from four or more
          vendors (two for features identified as being optional).

          That is, the 20 or so tests (expect more) are not intended as
          a conformance suite to test a single implementation, rather as
          a vehicle for demonstrating multiple implementations
          interoperating based upon the Candidate Recommendations for
          WS-Addressing.

          > Above and beyond those 20 test cases, if two stacks fail to
          > interoperate, who is going to be at fault? In the absence of any
          > broad, normative test suite, its going to devolve to blame assigment
          > or the more agile/niche stacks having to adapt to the de-facto
          > standards set by the mainstream implementations. This is
          > unsatisfactory, as the normative specification will end up being
          > supplemented by the informal rules as how to work with WSA-3.0,
          > indigo, Axis1.4, etc.

          That's an interesting discussion for SOAPbuilders in general. I've
          heard several people I know, who should know better, assert that the
          WS-I performs 'bake-offs' in the manor that SOAPbuilders undertook
          a few years ago. Others believe it is a certification organisation.
          In reality, little could be further from the truth.

          There is a need for more testing and test-driven work in Web
          services in general. I'm not sure how to achieve that given the
          current attitude from the industry. Then there is the sad but
          true fact that most everybody wants to interop with one defacto
          implementation, and many see that as being somehow 'good enough'.

          Whilst I think this kind of one-off event is going to have its
          part to play, I hope the test-suite, public end-points provided
          by vendors and logs of example messages will go at least some way
          to improving interoperability. And let's face it 'interoperability'
          is the only reason to even consider using this stuff.

          > Have the WS-A WG group noticed that inconsistent implementations of
          > the spec is a inevitable outcome of having no test suite developed
          > alongside the specification, and do they or the W3C plan to change
          > their process to be more test-driven in future?

          FWIW I personally agree 100% with the notion of "test driven
          specifications" and as Chair of the XML Schema Patterns for
          Databinding WG*, that's something I'd like to promote - that we
          don't have anything in the spec that isn't testable, and for which
          we don't have a test-case. But that is a far more constrained
          specification, without the multiplicity of 'bindings' and
          message exchanges with which WS-Addressing may be used.

          * http://www.w3.org/2002/ws/databinding/

          For WS-Addressing, features which don't result in implementations
          interoperating or are not testable will generate CR comments as
          a direct outcome of the interoperability testing and therefore be
          under risk of being reworked or removed from the specification.

          To that end, I would encourage comments on the suite, contribution
          of tests and above all participation at the WS-Addressing event.

          Paul
          --
          http://blog.whatfettle.com
        • Steve Loughran
          ... Hello ... Well thats it you see. Demonstrates that systems can be made to interoperate in controlled circumstances is fundamentally different from
          Message 4 of 4 , Dec 6, 2005
          • 0 Attachment
            On 12/6/05, Paul Downey <paul.downey@...> wrote:
            > Hi Steve!

            Hello

            >
            > > I see we have a whole twenty test cases that define the required
            > > behaviour of a WS-A stack.
            >
            > The test suite is still a matter of work in progress, and the
            > Working Group invites people to contribute more test cases:
            >
            > http://www.w3.org/2002/ws/addr/testsuite/#contributing
            >
            > However, the primary focus of 'CR' is to prove it is possible
            > to build implementations based up in the specifications, but
            > most importantly, that it enjoys support from four or more
            > vendors (two for features identified as being optional).
            >
            > That is, the 20 or so tests (expect more) are not intended as
            > a conformance suite to test a single implementation, rather as
            > a vehicle for demonstrating multiple implementations
            > interoperating based upon the Candidate Recommendations for
            > WS-Addressing.

            Well thats it you see. "Demonstrates that systems can be made to
            interoperate in controlled circumstances" is fundamentally different
            from "passes standard conformance suite", and also "demonstrates that
            interoperability is possible in the field".


            > > Above and beyond those 20 test cases, if two stacks fail to
            > > interoperate, who is going to be at fault? In the absence of any
            > > broad, normative test suite, its going to devolve to blame assigment
            > > or the more agile/niche stacks having to adapt to the de-facto
            > > standards set by the mainstream implementations. This is
            > > unsatisfactory, as the normative specification will end up being
            > > supplemented by the informal rules as how to work with WSA-3.0,
            > > indigo, Axis1.4, etc.
            >
            > That's an interesting discussion for SOAPbuilders in general. I've
            > heard several people I know, who should know better, assert that the
            > WS-I performs 'bake-offs' in the manor that SOAPbuilders undertook
            > a few years ago. Others believe it is a certification organisation.
            > In reality, little could be further from the truth.

            WS-I punted on the entire problem of which subsets of XSD people
            should be using. The SOAPBuilder rounds are the only reliable things
            to test out there, and all that WS-I has done is that they have caused
            it to stagnate. Where are the WS-A EPRs from SOAPBuilders. Where are
            the WSRF endpoints? Whose endpoints are supporting one-way MTOM. Whose
            two-way endponts take 3 minutes and 15 seconds to respond, just to see
            what timeouts the callers and the proxy servers have turned on?


            >
            > There is a need for more testing and test-driven work in Web
            > services in general. I'm not sure how to achieve that given the
            > current attitude from the industry. Then there is the sad but
            > true fact that most everybody wants to interop with one defacto
            > implementation, and many see that as being somehow 'good enough'.

            Test-driven software development has currently the lead in modern
            software development processes. The technical term used to describe
            other processes is "behind schedule".

            To move it into the standards arena, we need to adopt the same notion
            of write-test-first, as a formalisation of the specification. More to
            the point, we, the stack implementors need to be ruthelss and bounce
            back to the standards authority those specifications that get released
            without any tests. It wont take long for the message to get through:
            Any standard without tests doesnt exist.


            > Whilst I think this kind of one-off event is going to have its
            > part to play, I hope the test-suite, public end-points provided
            > by vendors and logs of example messages will go at least some way
            > to improving interoperability. And let's face it 'interoperability'
            > is the only reason to even consider using this stuff.

            A one-off propaganda event to demonstrate interop between vendors does
            make for good PR, but where are the regression tests?

            >
            > > Have the WS-A WG group noticed that inconsistent implementations of
            > > the spec is a inevitable outcome of having no test suite developed
            > > alongside the specification, and do they or the W3C plan to change
            > > their process to be more test-driven in future?
            >
            > FWIW I personally agree 100% with the notion of "test driven
            > specifications" and as Chair of the XML Schema Patterns for
            > Databinding WG*, that's something I'd like to promote - that we
            > don't have anything in the spec that isn't testable, and for which
            > we don't have a test-case. But that is a far more constrained
            > specification, without the multiplicity of 'bindings' and
            > message exchanges with which WS-Addressing may be used.

            Well I'm pleased to see a standard that is being test driven; I hear
            that some of the RDF work is done that way too.

            We are currently working on the test infrastructure for our
            distributed deployment standard. The language for describing
            configurations is relatively testable, all you need is a wrapper XSD
            to describe inputs and outputs, consistent fault codes across
            implementations, and a test runner to push JUnit to its limits. By the
            end of the week all three java impls will be using the same junit test
            classes, leaving the .NET implementation to reimplement that bit from
            scratch.

            http://cvs.sourceforge.net/viewcvs.py/*checkout*/deployment/deployment/doc/steve/test_driven_standards.doc

            Developing that test system has shown up all the bits we forgot from
            the spec: those consistent fault codes, reference importation rules,
            other surprises. If we had written the tests earlier, we would have
            found the problems earlier.

            IMO, it is competitive pressure to get a version 1.0 'standard' out
            the door that places emphasis on a code-frozen XSD, WSDL and matching
            document. However that is just the classic old waterfall process, and
            the lack of tests increases the delay between gold standard and
            compliant implementation.



            > For WS-Addressing, features which don't result in implementations
            > interoperating or are not testable will generate CR comments as
            > a direct outcome of the interoperability testing and therefore be
            > under risk of being reworked or removed from the specification.
            >
            > To that end, I would encourage comments on the suite, contribution
            > of tests and above all participation at the WS-Addressing event.

            I do plan to contribute tests. Given that the team has gone from 0 to
            20 twenty tests since September, with a few contributions they should
            be at, what, thirty, by Christmas!

            Testingly,

            -steve
          Your message has been successfully submitted and would be delivered to recipients shortly.