WS-I Basic Profile
The Web Services-Interoperability (WS-I) Basic Profile is a set of non-proprietary web services specifications that promote interoperability. WebSphere Application Server conforms to the WS-I Basic Profile Version 1.1 and WS-I Basic Security Profile Version 1.0.
The WS-I Basic Profile is governed by a consortium of industry-leading corporations, including IBM, under direction of the WS-I Organization. The profile consists of a set of principles that relate to bringing about open standards for web services technology. All organizations interested in promoting interoperability among web services are encouraged to become members of the Web Services Interoperability Organization.
Several technology components are used in the composition and implementation of web services, including messaging, description, discovery, and security. Each of these components are supported by specifications and standards, including SOAP 1.1, XML 1.0, HTTP 1.1, Web Services Description Language (WSDL) 1.1, and Universal Description, Discovery and Integration (UDDI). The WS-I Basic Profile specifies how these technology components are used together to achieve interoperability, and mandates specific use of each of the technologies when appropriate. We can read more about the WS-I Basic Profile at the WS-I Organization website.
As technology components are updated, these components are also used in the composition and implementation of web services. One example is that both SOAP 1.1 and SOAP 1.2 are now supported.
Building on the support for WS-I Basic Profile Version 1.0, WS-I Basic Profile V1.1, Attachment Profile V1.0, Basic Security Profile (BSP) V1.0, and WS-I Basic Security Profile V1.1, we can implement web services with this product using the following active WS-I profiles:
- WS-I Basic Profile V1.2 builds on WS-I Basic Profile V1.0 and WS-I Basic Profile V1.1 and adds support for WS-Addressing (WS-A) and SOAP Message Transmission Optimization Mechanism (MTOM). The WS-Addressing specification enables the asynchronous message exchange pattern so that we can decouple the service request from the service response. The SOAP header of the sender's request contains the wsa:ReplyTo value that defines the endpoint reference to which the provider's response is sent. Decoupling the request from the response enables long running web services interactions. Leveraging the asynchronous programming model support in JAX-WS v2.1 in combination with WS-Addressing, we can now take advantage of the ability to create web services invocations where the client can continue to process work without waiting for a response to return. This provides for a more dynamic and efficient model to invoke web services. Using MTOM, we can send and receive binary data optimally within a SOAP message.
- WS-I Basic Profile V2.0 builds on Basic Profile V1.2 with the addition of support for SOAP 1.2.
- WS-I Reliable Secure Profile 1.0 builds on WS-I Basic Profile V1.2, WS-I Basic Profile V2.0, WS-I Basic Security Profile V1.0, and WS-I Basic Security Profile V1.1 and adds support for WS-Reliable Messaging 1.1, WS-Make Connection 1.0, and WS-Secure Conversation 1.3. WS-Reliable Messaging 1.1 is a session-based protocol that provides message level reliability for web services interactions. WS-Make Connection 1.0 was developed by the WS-Reliable Messaging workgroup to address scenarios where a web services endpoint is behind a firewall or the endpoint has no visible endpoint reference. If a web services endpoint loses connectivity during a reliable session, WS-Make Connection provides an efficient method to re-establish the reliable session. Additionally, WS-Secure Conversation V1.3 is a session-based security protocol that uses an efficient symmetric key based encryption algorithm for message level security. WS-I Reliable Secure Profile V1.0 provides secure reliable session-oriented web services interactions.
Each of the technology components has requirements that we can read about in more detail at the WS-I Organization website. For example, support for Universal Transformation Format (UTF)-16 encoding is required by WS-I Basic Profile. UTF-16 is a kind of Unicode encoding scheme that uses 16-bit values to store Universal Character Set (UCS) characters. UTF-8 is the most common encoding used on the Internet; UTF-16 encoding is typically used for Java and Windows product applications; and UTF-32 is used by various Linux and UNIX systems. Unlike UTF-8, UTF-16 has issues with big-endian and little-endian, and often involves Byte Order Mark (BOM) to indicate the endian. BOM is mandatory for UTF-16 encoding and it can be used in UTF-8.
The application server only supports UTF-8 and UTF-16 encoding of SOAP messages.
See the information on changing SOAP message encoding to support WSI-Basic Profile to learn how to modify the encoding from UTF-8 to UTF-16.
Bytes Encoding form EF BB BF UTF-8 FF FE UTF-16, little-endian FE FF UTF-16, big-endian 00 00 FE FF UTF-32, big-endian FF FE 00 00 UTF-32, little-endian BOM is written prior to the XML text, and it indicates to the parser how the XML is encoded. The XML declaration contains the encoding, for example: <?xml version=xxx encoding="utf-xxx"?>. BOM is used with the encoding to determine how to interpret the XML. Here is an example of a SOAP message and how BOM and UTF encoding are used:
POST http://www.whitemesa.net/soap12/add-test-rpc HTTP/1.1 Content-Type: application/soap+xml; charset=utf-16; action="" SOAPAction: Host: localhost: 8080 Content-Length: 562OxFF0xFE<?xml version="1.0" encoding="utf-16"?> <soap:Envelope xmlns:soap="http://www.w3.org/2002/12/soap-envelope" xmlns:soapenc="http://www.w3.org/2002/12/soap-encoding xmlns:tns="http://whitemesa.net/wsdl/soap12-test" xmlns:types="http://whitemesa.net/wsdl/soap12-test/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <q1:echoString xmlns:q1="http://soapinterop.org/"> <inputString soap:encodingStyle="http://example.org/unknownEncoding" xsi:type="xsd:string"> Hello SOAP 1.2 </inputString> </q1:echoString> </soap:Body> </soap:Envelope>In the example code, 0xFF0xFE represents the byte codes, while the <?xml> declaration is the textual representation.
Support for styleEncoding is not supported in SOAP 1.2 so here is the same example of the SOAP message but without the encoding information:
OxFF0xFE<?xml version="1.0" encoding="utf-16"?> <soap:Envelope xmlns:soap="http://www.w3.org/2002/12/soap-envelope" xmlns:soapenc="http://www.w3.org/2002/12/soap-encoding xmlns:tns="http://whitemesa.net/wsdl/soap12-test" xmlns:types="http://whitemesa.net/wsdl/soap12-test/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <q1:echoString xmlns:q1="http://soapinterop.org/"> <inputString xsi:type="xsd:string"> Hello SOAP 1.2 </inputString> </q1:echoString> </soap:Body> </soap:Envelope>For a complete list of the supported standards and specifications, see the web services specifications and API documentation.
Related:
Differences in SOAP versions Web Services Addressing support Basic Security Profile compliance tips Change SOAP message encoding to support WSI-Basic Profile Enable MTOM for JAX-WS web services Web services specifications and APIs