The Web Services-Interoperability Organization has announced the publication of a final specification for the WS-I Basic Profile Version 1.0a, accompanied by statements of support from more than twenty-five WS-I member companies. The Basic Profile formally approved by the WS-I member community "consists of implementation guidelines on how core Web services specifications should be used together to develop interoperable Web services. The non-proprietary Web services specifications covered by the Basic Profile include SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and W3C XML Schema." The profile identifies and resolves "more than 200 interoperability issues" associated with the use of core Web services specifications referenced in the document. "WS-I is currently developing interoperability guidelines for SOAP with Attachments, and for the Basic Security Profile. These efforts will extend the functionality provided by the Basic Profile and will reference existing specifications." The Microsoft Prescriptive Architecture Group (PAG) has released a 133-page document Building Interoperable Web Services which surveys the contents of the Basic Profile and offers a "definitive guide on how to build and consume WS-I Basic Profile compliant Web services with Visual Studio .NET and the .NET Framework."

Bibliographic Information

Basic Profile Version 1.0a. Final Specification. Date: 2003/08/08. Revision URL: http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html. Edited by Keith Ballinger (Microsoft), David Ehnebuske (IBM), Martin Gudgin (Microsoft), Mark Nottingham (BEA Systems), and Prasad Yendluri (webMethods). Administrative contact: secretary@ws-i.org. Copyright (c) 2002-2003 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members.

Specifications Referenced by the Basic Profile

Appendix I of the Basic Profile Version 1.0a provides a list of specifications that are incorporated by reference with respect that requirements that are in scope. These specifications include:

• Simple Object Access Protocol (SOAP) 1.1
• Extensible Markup Language (XML) 1.0 (Second Edition)
• RFC2616: Hypertext Transfer Protocol -- HTTP/1.1
• RFC2965: HTTP State Management Mechanism
• Web Services Description Language (WSDL) 1.1
• XML Schema Part 1: Structures
• XML Schema Part 2: Datatypes
• UDDI Version 2.04 API Specification, Dated 19 July 2002
• UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002
• UDDI Version 2 XML Schema
• RFC2818: HTTP Over TLS
• RFC2246: The TLS Protocol Version 1.0
• The SSL Protocol Version 3.0
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Basic Profile Overview

Scope. Section 2 "Scope of the Profile" clarifies the specification's mechanism for identifying technologies that are in-scope and out-of-scope. The Profile "only attempts to improve interoperability within its own scope; initially, the Profile's scope is bounded by the specifications referenced by it... The Profile's scope is further refined by extensibility points. Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters. When identified as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use is not subject to claims of conformance to this Profile. Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement..."

Conformance. Section 3 "Profile Conformance" describes the meaning of conformance in terms of relevant requirements, targets, and conformance claims: "Requirements state the criteria for conformance to the Profile within its stated scope. They embody refinements, interpretations and clarifications that improve interoperability therein. Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of the requirement and its impact on conformance. Each requirement is individually identified (e.g., R9999) for convenience... Targets allow for the description of conformance in different contexts, to allow conformance testing and certification of artifacts (such as SOAP messages and WSDL descriptions), Web service instances, and Web service consumers. The sections below describe the Profile's conformance targets. To allow services to advertise conformance to the Profile, messages, descriptions and registry data can be annotated with conformance claims, which use a URI to assert conformance with a particular profile... The most basic level of conformance is that of an artifact. The Profile makes requirement statements about three kinds of artifacts: (1) MESSAGE - protocol elements that are exchanged, usually over a network, to effect a Web service e.g., SOAP/HTTP messages; (2) DESCRIPTION - descriptions of types, messages, interfaces and their concrete protocol and data format bindings, and the network access points associated with Web services, e.g., WSDL descriptions; (3) REGDATA - registry elements that are involved in the registration and discovery of Web services, e.g., UDDI tModels)..."

Profile Components. Principal components addressed in the Profile include Messaging, Service Description, Service Publication and Discovery, and Security:

• Messaging: XML Representation of SOAP Messages, SOAP Processing Model, use of SOAP in HTTP. Section 4 "Messaging" incorporates four specifications by reference and defines extensibility points within them: Simple Object Access Protocol (SOAP) 1.1; RFC2616: Hypertext Transfer Protocol -- HTTP/1.1; Extensible Markup Language (XML) 1.0 (Second Edition); RFC2965: HTTP State Management Mechanism. The Profile mandates the use of the SOAP 1.1 XML-based structure for transmitting messages structure and places additional constraints on its use.

• Service Description: document structure, types, messages, port types, bindings, SOAP binding, use of XML Schema. "The Profile uses Web Services Description Language (WSDL) to enable the description of services as sets of endpoints operating on messages. Section 5 incorporates three specifications by reference and defines extensibility points within them: Web Services Description Language (WSDL) 1.1; XML Schema Part 1: Structures; XML Schema Part 2: Datatypes."

• Service Publication and Discovery: bindingTemplates, tModels. Section 6 incorporates three specifications by reference and defines extensibility points within them: UDDI Version 2.04 API Specification, Dated 19 July 2002; UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002; UDDI Version 2 XML Schema. "When publication or discovery of Web services is required, UDDI is the mechanism the Profile has adopted to describe Web service providers and the Web services they provide. Business, intended use, and Web service type descriptions are made in UDDI terms; detailed technical descriptions are made in WSDL terms. Where the two specifications define overlapping descriptive data and both forms of description are used, the Profile specifies that the descriptions must not conflict. Registration of Web service instances in UDDI registries is optional. By no means do all usage scenarios require the kind of metadata and discovery UDDI provides, but where such capability is needed, UDDI is the sanctioned mechanism..."

• Security: use of HTTPS. Section 7 "Security" incorporates four specifications by reference and defines extensibility points within them: RFC2818: HTTP Over TLS; RFC2246: The TLS Protocol Version 1.0; The SSL Protocol Version 3.0; RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile. "For Web services, as for other information technologies, security consists of understanding the potential threats an attacker may mount and applying operational, physical, and technological countermeasures to reduce the risk of a successful attack to an acceptable level. Because an 'acceptable level of risk' varies hugely depending on the application, and because costs of implementing countermeasures is also highly variable, there can be no universal 'right answer' for securing Web services...there are common patterns of countermeasures that experience shows reduce the risks to acceptable levels for many Web services. The Profile adopts, but does not mandate use of, the most widely used of these: HTTP secured with either TLS 1.0 or SSL 3.0 (HTTPS). That is, conformant Web services may use HTTPS; they may also use other countermeasure technologies or none at all. HTTPS is widely regarded as a mature standard for encrypted transport connections to provide a basic level of confidentiality. HTTPS thus forms the first and simplest means of achieving some basic security features that are required by many real-world Web service applications. HTTPS may also be used to provide client authentication through the use of client-side certificates..."

Basic Profile Design Principles

Section 1.1 articulates a set of principles that was used in the design of the Basic Profile's interoperability goals. Excerpts:

"It is impossible to completely guarantee the interoperability of a particular service. However, the Profile does address the most common problems that implementation experience has revealed to date... Although communication of application semantics can be facilitated by the technologies that comprise the Profile, assuring the common understanding of those semantics is not addressed by it... When possible, the Profile makes statements that are testable. However, such testability is not required. Preferably, testing is achieved in a non-intrusive manner (e.g., examining artifacts 'on the wire')... When possible, the Profile aligns its requirements with in-progress revisions to the specifications it references (e.g., SOAP 1.2, WSDL 1.2). This aids implementers by enabling a graceful transition, and assures that WS-I does not 'fork' from these efforts. When the Profile cannot address an issue in a specification it references, this information is communicated to the appropriate body to assure its consideration... Backwards compatibility with deployed Web services is not a goal for the Profile, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced specification unless doing so addresses specific interoperability issues... Where possible, the Profile places requirements on artifacts (e.g.,, WSDL descriptions, SOAP messages) rather than the producing or consuming software's behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone... The Profile speaks to interoperability at the application layer; it assumes that interoperability of lower-layer protocols (e.g.,, TCP, IP, Ethernet) is adequate and well-understood. Similarly, statements about application-layer substrate protocols (e.g., SSL/TLS, HTTP) are only made when there is an issue affecting Web services specifically; WS-I does not attempt to assure the interoperability of these protocols as a whole. This assures that WS-I's expertise in and focus on Web services standards is used effectively..." [adapted from the Introduction, 'Guiding Principles']

From the Announcement

"Starting today, every Web service developer and provider will have a common framework for implementing interoperable solutions, and buyers will have a common reference point for purchasing decisions," said Tom Glover, chairman of WS-I. "WS-I has resolved more than 200 interoperability issues associated with using the core Web services specifications together. The Basic Profile 1.0 will significantly simplify the task of implementing interoperable Web services solutions within and across enterprise boundaries."

"Support for the Basic Profile is the baseline for interoperable Web services," said Dan Sholler, vice president of Technology Research Services at the META Group. "Customers should demand that all of their Web services-enabled technology be compliant with the Basic Profile, and that in turn will lay the foundation for Web services to fulfill their promise and provide technology independent interoperability."

Later this Fall, WS-I will release Test Tools and Sample Applications supporting the Basic Profile 1.0. The Test Tools, available in both C# and Java implementations, are designed to inspect and validate that a Web service meets the interoperability requirements of the Basic Profile. The Sample Applications demonstrate the Basic Profile at work, including the design, implementation, test and deployment of Web services, based upon selected business scenarios and implemented on 10 different platforms.

In parallel with the release of the Test Tools, WS-I will announce how Web services software vendors, hardware vendors, and services providers will be able to claim conformance of their products to the Basic Profile 1.0.

About WS-I

"WS-I is an open, industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages. The organization works across the industry and standards organizations to respond to customer needs by providing guidance, best practices, and resources for developing Web services solutions. WS-I was formed specifically for the creation, promotion, or support of Generic Protocols for Interoperable exchange of messages between services. Generic Protocols are protocols that are independent of any specific action indicated by the message beyond actions necessary for the secure, reliable, or efficient delivery of messages; "Interoperable" means suitable for and capable of being implemented in a neutral manner on multiple operating systems and in multiple programming languages." [from the WS-I homepage]