WS-I Basic Profile

Web Services-Interoperability (WS-I) Basic Profile is a set of non-proprietary Web services specifications that promote interoperability. WebSphere Application Server v7 conforms to...

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 that are 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...

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. You can read more about the WS-I Basic Profile at the WS-I Organization Web site.

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.

New feature: Building on the support for...

...you can implement Web services with WAS V7.0 using the following current emerging standard WS-I profiles...


  1. WS-I Basic Profile V1.2

    Builds on...

    • WS-I Basic Profile V1.0
    • WS-I Basic Profile V1.1

    ...and adds support for...

    • WS-Addressing (WS-A)
    • SOAP Message Transmission Optimization Mechanism (MTOM)

    The WS-Addressing spec enables the asynchronous message exchange pattern so that you 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, you 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, you can send and receive binary data optimally within a SOAP message.


  2. WS-I Basic Profile V2.0

    builds on top of Basic Profile V1.2 with the addition of support for SOAP 1.2.


  3. WS-I Basic Security Profile V1.1

    extends the WS-I Basic Security Profile V1.0 standard by profiling the latest WS-Security V1.1 specification.


  4. 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 you can read about in more detail at the WS-I Organization Web site. 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 that is 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... <?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: 562


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 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 concepts

Differences in SOAP versions
Web Services Addressing support
Basic Security Profile compliance tips
What is new for securing Web services


Related tasks


Change SOAP message encoding to support WSI-Basic Profile
Enable MTOM for JAX-WS Web services


Related reference

Web services specifications and APIs