WS Protocol Workshop Process The Path to Real-world Interoperability Jorgen Thelin, Microsoft Corporation

Workshops – The Path to Real- World Interoperability Purpose:  Applying software testing practices to Web Services specs  Provide review, testing and validation of WS-* specifications earlier in the spec development cycle Goal: INTEROPERABLE SPECS  Find and fix problems in the specs before they are widely implemented and adopted  Gather feedback from implementers, vendors and other interested parties on spec interoperability and usability problems  Demonstrate and test of the interoperability achievable using the spec(s) Result:  Community consultation and involvement in the spec development process  Proven interoperability among spec implementations

Workshops - Attendance Open to EVERYONE  Anyone who signs a feedback agreement can attend  For example Spec authors Companies with known interest in the spec Authors of competing specs, if they wish Researchers / University staff

Types of Workshop Feedback Workshop  Gather comments from implementers and interested parties  Equivalent to: Code review / walkthrough Interop Workshop  Exercise spec implementations  Equivalent to: System / integration testing for software

Spec State Transitions Feedback Workshops Interop Draft Author Draft Release Interop Workshops Workshop Pipeline Spec States Published Draft

Compare: Software State Transitions Code Review Internal Milestone Release WIP Code External Release System and Integration Testing Review / Test Pipeline Software States Committed Code

Feedback Workshop Details Audience: all interested parties  Just sign the feedback agreement Goal: Gathering feedback on published drafts Format - 1-day event  Presentations for half a day  Feedback discussion for half a day Deliverables  Feedback to spec authors  Suggestions for future interop scenarios

Interop Workshop Details Audience: spec implementers  Sign the feedback agreement and bring your own implementation Goal: Achieving interoperability between implementations Format - 2-day event  Round-table interoperability lab - 1 room, many implementations  Hands-on peer-to-peer testing - BYO Laptop  Test cases created in advance – included in invite pack Deliverables  Feedback to spec authors on implementability of spec(s)  Broad levels of interoperability between implementations  Suggestions for future interop scenarios  (If possible) Live endpoints from ongoing testing

Workshop Tracks TrackSpecs Infrastructure / Metadata WS-Addressing, WS-Policy, WS-PolicyAssertions, WS- PolicyAttachment, WS-MetadataExchange Reliable Messaging WS-ReliableMessaging SecurityWS-Security, WS-Trust, WS-SecureConversation, WS- SecurityPolicy, WS-SecurityKerberos, WS-Federation, WS-Federation Active and Passive Client Profiles TransactionsWS-Coordination, WS-AtomicTransaction, WS- BusinessActivity EventingWS-Eventing

Workshop History Feedback Workshops  Policy + Security (Trust) – Feb 2003  Policy + Security (Trust) – March 2003  Reliable Messaging – July 2003  Security (Federation) – Nov 2003 Interop Workshops  Reliable Messaging – Oct 2003  Security (Secure Conv and Trust) – Nov 2003

Why the incremental approach? Rome wasn’t built in a day  Neither was the Internet, or any major IT infrastructure! Specs take time to settle in and usage experiences develop Building the higher layers of the architecture can point out changes required in lower levels For example: HTML didn’t jump straight to v4.0 – it took time to see what worked and what didn’t

Workshops – More Info Workshops Home Page on MSDN  nity/workshops/ nity/workshops/

Ways to get involved Visit Workshop web pages for more info Join the workshop mailing lists on Yahoo  WS-RM-Workshops  WS-Security-Workshops  WS-TX-Workshops  WS-Eventing-Workshops Come to future Feedback and/or Interop Workshops and give us your input