W3C Web Services Workshop

1. W3C Web Services Workshop Position Paper Marwan Sabbouh, ms@mitre.org Stu Jolly, smjolly@mitre.org Paul Denning, pauld@mitre.org Dock Allen, dock@mitre.org Paul Silvey, psilvey@mitre.org 4/11/2001 Organization: D590 Project: 03017496-00, 03016026-WA, 03016078-C0, 03014000-C2

2. Acknowledgements • The authors thank the MITRE Corporation and their sponsors for making this possible. Also, we thank those who contributed to this work. In particular, Dan Hebert, John Morris, Bede McCall, Doug Norman, Amanda Martino, Eric Chamberlin, and Vuhuy Phan for their comments.

3. Agenda • Web Model • Any to Any Computing • Extensibility • Interoperability • Description and Discovery • User’s Context • Quality of Service • Security

4. Web Model • Browser-Web Server interaction is easy, transparent, and works • Relationship: any browser to any web server interaction • No apriori knowledge by the client of the server • Standardizing on HTTP, HTML, and URL • Allows for intermediaries: proxy servers, caching servers • Disadvantage: • Web server to Web server interaction is difficult • Client must make request of various Web sites • Result: • Isolated Web islands

5. Web Services’ Potential • Web server to Web server interaction is easy • Relationship: Any-to-any • Should all Web services interact at a basic level? • Web sites collaborating on behalf of users • Extending firewalls across corporate networks • Different classes of services on the Web • Extensibility vs. Interoperability? • Made possible by adherence to standards • W3C XML Protocol • Description and Discovery of Web Services • Context • Quality of Service • Semantics

6. Extensibility • XML Protocol Architecture is based on a layered/extensible approach • Protocol binding allows for the adoption of different protocol stacks • SOAP encoding allows for the adoption of different data models • Modules allow for evolution • Intermediaries provide for reverse proxy, transfer protocol bridges, etc.

7. Interoperability • Middleware interoperability • XML Protocol, XML Schema • Syntactic interoperability • XML • Uniform way that describes how to access services • WSDL • Structural interoperability • Standardizing on a data model • SOAP encoding • Mapping different data models • RDF? • Semantic interoperability • Ultimate goal

8. Ensuring Any to Any Computing • Services must bind to standard Internet Protocols • Client must support various Internet Protocols (SMTP, HTTP, FTP) • Adopting a standard data model if possible • Else, provide mapping of distinct data models • WSDL • Strict conformance to specifications • Standards that address module extensions (XAML, reliable delivery semantics) • Tools interoperability • Standards that describe what a service does • Standards that describe users’ context information and needs • Adopting Internet security standards

9. WSDL • WSDL is used to expose Web Services by defining: • Behavior • Abstract Operations • Concrete Operations • Methods of Access • Style of Payload (RPC/Document) • WSDL files are defined using the following elements • Type • Message • PortType • Binding • Port • Service

10. UDDI • Provides yellow, green, and white pages functionality • Provides a standard API for registration and lookup of services • Security • Registry enjoys a self-supported business model • Maintains data integrity • Validates entries on registration • Requires renewal of registration periodically • Removes outdated entries

11. User’s Context • Identity • Role • Access device • Location • Time • Privacy Constraints • Must travel with request

12. Quality Of Service (QoS) for Web Services • See Usage Scenario in XMLP Requirements Document • Define QoS extensions to XMLP as multiple XMLP Modules • XMLP Blocks for QoS • Use XML Schema to standardize QoS information carried within XMLP Envelope • XMLP Handlers for QoS • QoS processing • Relates to BindingContext (see Abstract Model) • BindingContext assumed to hold parameters needed for lower layer QoS mechanisms (Diffserv, etc.) • XMLP Block propagates QoS (or Class of Service) across XMLP Intermediaries (and potentially different transports) • Preserve end-to-end QoS throughout XMLP message path

13. Example XMLP QoS Modules • SLA Module • Block Carries UUID or URI of Service Level Agreement (SLA) or ebXML Trading Partner Agreement (TPA) • XMLP Handler looks up Service Level Specification (SLS) for given SLA/TPA (cached), writes appropriate DiffServ parameters into BindingContext • Assumes Binding is QoS-aware (knows how to interpret BindingContext.QoS) • ResponseTime Module • Block Carries timestamps • Handler inserts timestamps, collects Response Time statistics • SLA Monitor Module • Uses data from ResponseTime Module to verify SLA compliance, traffic shaping via SLA Module

14. Forum for XMLP QoS Module Defintion • Propose a new W3C WG under the XMLP Activity • Specify QoS Modules using XMLP WG’s Module Template • Standardize XML Schema of XMLP Blocks for QoS • Define information model for BindingContext QoS data • Define information model for ModuleContext • Develop QoS usage scenarios • Coordinate with other groups • QoS Taxonomy (Open Group QoS Task Force) • UDDI registration of Web Service QoS capabilities • ebXML Collaboration Protocol Profile

15. Security • Web services provide new security challenges • WSDL • Web services’ infrastructure must be secure • Security model for UDDI