WSIT Specifications

The specifications for bootstrapping and configuration, message optimization, reliable messaging, and security technologies are discussed in the following sections:

• Bootstrapping and Configuration Specifications

• Message Optimization Specifications

• Reliable Messaging Specifications

• Security Specifications

WSIT 1.0 implements the specification versions listed in Table 2–1.

Table 2–1 WSIT Specification Versions

Technology	Version
Bootstrapping	WS-MetadataExchange v1.1
Reliable Messaging	WS-ReliableMessaging v1.0  WS-ReliableMessaging Policy v1.0
Atomic Transactions	WS-AtomicTransaction v1.0  WS-Coordination v1.0
Security	WS-Security v1.1  WS-SecurityPolicy v1.1  WS-Trust v1.0  WS-SecureConversation v1.0
Policy	WS-Policy v1.2  WS-PolicyAttachment v1.2

The same versions of these specifications are also implemented in WCF in .NET 3.0. Sun will update to the standard versions of these specifications in a future release of WSIT. Those versions will coincide with the versions used in WCF in .NET 3.5.

Bootstrapping and Configuration Specifications

Bootstrapping and configuring involves a client getting a web service URL (perhaps from a service registry) and obtaining the information needed to build a web services client that is capable of accessing and consuming a web service over the Internet. This information is usually obtained from a WSDL file. Figure 2–3 shows the specifications that were implemented to support bootstrapping and configuration.

Figure 2–3 Bootstrapping and Configuration Specifications

In addition to the Core XML specifications, bootstrapping and configuration was implemented using the following specifications:

• WSDL: The Web Services Description Language (WSDL) specification was previously implemented in JAX-WS. WSDL is a standardized XML format for describing network services. The description includes the name of the service, the location of the service, and ways to communicate with the service, that is, what transport to use. WSDL descriptions can be stored in service registries, published on the Internet, or both.

• Web Services Policy: This specification provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of a web service. It provides the mechanisms needed to enable web services applications to specify policy information in a standardized way. However, this specification does not provide a protocol that constitutes a negotiation or message exchange solution for web Services. Rather, it specifies a building block that is used in conjunction with the WS-Metadata Exchange protocol. When applied in the web services model, policy is used to convey conditions on interactions between two web service endpoints. Typically, the provider of a web service exposes a policy to convey conditions under which it provides the service. A requester might use the policy to decide whether or not to use the service.

• Web Services Metadata Exchange: This specification defines a protocol to enable a consumer to obtain a web service’s metadata, that is, its WSDL and policies. It can be thought of as a bootstrap mechanism for communication.

Message Optimization Specifications

Message optimization is the process of transmitting web services messages in the most efficient manner. It is achieved in web services communication by encoding messages prior to transmission and then de-encoding them when they reach their final destination.

Figure 2–4 shows the specifications that were implemented to optimize communication between two web service endpoints.

Figure 2–4 Message Optimization Specifications

In addition to the Core XML specifications, optimization was implemented using the following specifications:

• SOAP: JAX Web Services currently supports the SOAP wire protocol. With SOAP implementations, client requests and web service responses are most often transmitted as Simple Object Access Protocol (SOAP) messages over HTTP to enable a completely interoperable exchange between clients and web services, all running on different platforms and at various locations on the Internet. HTTP is a familiar request-and response standard for sending messages over the Internet, and SOAP is an XML-based protocol that follows the HTTP request-and-response model. In SOAP 1.1, the SOAP portion of a transported message handles the following:

  • Defines an XML-based envelope to describe what is in the message and how to process the message.

  • Includes XML-based encoding rules to express instances of application-defined data types within the message.

  • Defines an XML-based convention for representing the request to the remote service and the resulting response.

    In SOAP 1.2 implementations, web service endpoint addresses can be included in the XML-based SOAP envelope, rather than in the transport header (for example in the HTTP transport header), thus enabling SOAP messages to be transport independent.

• Web Services Addressing: The Java APIs for W3C Web Services Addressing were first shipped with Java Web Services Developer’s Pack 2.0 (JWSDP 2.0). This specification defines a set of abstract properties and an XML Infoset representation that can be bound to a SOAP message so as to reference web services and to facilitate end-to-end addressing of endpoints in messages. A web service endpoint is an entity, processor, or resource that can be referenced and to which web services messages can be addressed. Endpoint references convey the information needed to address a web service endpoint. The specification defines two constructs: message addressing properties and endpoint references, that normalize the information typically provided by transport protocols and messaging systems in a way that is independent of any particular transport or messaging system. This is accomplished by defining XML tags for including web service addresses in the SOAP message, instead of the HTTP header. The implementation of these features enables messaging systems to support message transmission in a transport-neutral manner through networks that include processing nodes such as endpoint managers, firewalls, and gateways.

• Web Services Secure Conversation: This specification provides better message-level security and efficiency in multiple-message exchanges in a standardized way. It defines basic mechanisms on top of which secure messaging semantics can be defined for multiple-message exchanges and allows for contexts to be established and potentially more efficient keys or new key material to be exchanged, thereby increasing the overall performance and security of the subsequent exchanges.

• SOAP MTOM: The SOAP Message Transmission Optimization Mechanism (MTOM), paired with the XML-binary Optimized Packaging (XOP), provides standard mechanisms for optimizing the transmission and/or wire format of SOAP messages by selectively encoding portions of the SOAP message, while still presenting an XML Infoset to the SOAP application. This mechanism enables the definition of a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path so as to facilitate the efficient pass-through of optimized data contained within headers or bodies of SOAP messages that are relayed by an intermediary. Further, it enables message optimization to be done in a binding independent way.

Reliable Messaging Specifications

Reliability is measured by a system’s ability to deliver messages from point A to point B without error. Figure 2–5 shows the specifications that were implemented to ensure reliable delivery of messages between two web services endpoints.

Figure 2–5 Reliable Messaging Specifications

In addition to the Core XML specifications and supporting standards (Web Services Security and Web Services Policy, which are required building blocks), the reliability feature is implemented using the following specifications:

• Web Services Reliable Messaging: This specification defines a standardized way to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination, so as to recover from failures caused by messages being lost or received out of order. The specification is also extensible so it allows additional functionality, such as security, to be tightly integrated. The implementation of this specification integrates with and complements the Web Services Security, and the Web Services Policy implementations.

• Web Services Coordination: This specification defines a framework for providing protocols that coordinate the actions of distributed applications. This framework is used by Web Services Atomic Transactions. The implementation of this specification enables the following capabilities:

  • Enables an application service to create the context needed to propagate an activity to other services and to register for coordination protocols.

  • Enables existing transaction processing, workflow, and other coordination systems to hide their proprietary protocols and to operate in a heterogeneous environment.

  • Defines the structure of context and the requirements so that context can be propagated between cooperating services.

• Web Services Atomic Transactions: This specification defines a standardized way to support two-phase commit semantics such that either all operations invoked within an atomic transaction succeed or are all rolled back. Implementations of this specification require the implementation of the Web Services Coordination specification.

Security Specifications

Figure 2–6 shows the specifications implemented to secure communication between two web service endpoints and across intermediate endpoints.

Figure 2–6 Web Services Security Specifications

In addition to the Core XML specifications, the security feature is implemented using the following specifications:

• Web Services Security: This specification defines a standard set of SOAP extensions that can be used when building secure web services to implement message content integrity and confidentiality. The implementation provides message content integrity and confidentiality even when communication traverses intermediate nodes, thus overcoming a short coming of SSL. The implementation can be used within a wide variety of security models including PKI, Kerberos, and SSL and provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies.

• Web Services Policy: This specification provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of a web service. It provides a framework and a model for the expression of these properties as policies and is a building block for Web Services Security policy.

• Web Services Trust: This specification supports the following capabilities in a standardized way:

  • Defines extensions to Web Services Security that provide methods for issuing, renewing, and validating security tokens used by Web services security.

  • Establishes, assesses the presence of, and brokers trust relationships.

• Web Services Secure Conversation: This specification defines a standardized way to provide better message-level security and efficiency in multiple-message exchanges. The WSIT implementation provides basic mechanisms on top of which secure messaging semantics can be defined for multiple-message exchanges and allows for contexts to be established along with more efficient keys or new key material. This approach increases the overall performance and security of the subsequent exchanges. While the Web Services Security specification, described above, focuses on the message authentication model, it does leave openings for several forms of attacks. The Secure Conversation authentication specification defines a standardized way to authenticate a series of messages, thereby addressing the short comings of Web Services Security. With the Web Services Security Conversation model, the security context is defined as a new Web Services security token type that is obtained using a binding of Web Services Trust.

• Web Services Security Policy: This specification defines a standard set of patterns or sets of assertions that represent common ways to describe how messages are secured on a communications path. The WSIT implementation allows flexibility in terms of tokens, cryptography, and mechanisms used, including leveraging transport security, but is specific enough to ensure interoperability based on assertion matching by web service clients and web services providers.