Tutorial:Review of WSIT for the Web Service Developer Exam
In this article, we will provide an overview of Web Service Interoperability Technologies (WIST). We will describe what is WIST, discuss its features and the standards of WIST. This is part of a larger series of articles to help you prepare for the web service developer exam. You can review the first article, “Tutorial:Review of Building Web Services for the Web Service Developer Exam” in order to understand the concepts discussed here.
Achieving Interoperability between Different Platforms
Achieving “connected systems” that can facilitate intelligent, stand-alone systems capable of communicating with each other using a universal language is a long held ideal in the IT market. This is one of the core SOA principals. Any enterprise in the world generally consist of multiple software platforms where the stakeholders of the enterprise have made significant investments in existing solutions based on Java, COM, Unix, Linux and other legacy technologies.
The task for cross-platform interoperability is to leverage standards as published by industry-supported and industry-controlled committees. Still, each vendor has the tendency to implement its own “interpretation” of the standard. Microsoft’s platform of choice is Windows Communication Foundation (WCF). Windows Communication Foundation (WCF) is Microsoft’s unified programming model for building connected systems and is now available as part of the .NET Framework 3.0 product. It includes application programming interfaces (APIs) for building secure, reliable, transacted web services that interoperate with non-Microsoft platforms. To achieve a neutral perspective, Microsoft’s Windows Communication Foundation team generated many compatibility tests for a subset of the different vendor implementations. It also created internal testing and the WCF Interoperability Plug-Fest program to work with stack vendors to achieve greater compliance and compatibility.
The Advent of WSIT
As one of the participants in the Plug-Fest program for achieving enhanced interoperability WCF was Sun Microsystems. The Sun web services team worked with the WCF team on a number of occasions and then publicly released an open source framework focused primarily on interoperability with WCF. This framework started as Project Tango but has now evolved into Web Services Interoperability Technology (WSIT). The goal of this effort is to produce web services consumers and producers that support platform independence, and then to test and deliver products to market that interoperate across different platforms.
WSIT is the product of Sun’s web services interoperability initiative. In this joint effort, Sun Microsystems and Microsoft are testing WSIT against WCF to ensure that Sun web service clients (consumers) and web services (producers) do in fact interoperate with WCF web services applications and vice versa. The testing will ensure that the following interoperability goals are realized:
- WSIT web services clients can access and consume WCF web services.
- WCF web services clients can access and consume WSIT web services.
Sun is building WSIT on the Java platform and Microsoft is building WCF on the .NET 3.0 platform. The sections that follow describe the web services specifications implemented by Sun Microsystems in Web Services Interoperability Technologies (WSIT) and provide high-level descriptions of how each WSIT technology works. This framework is now available in open source form. WIST’s main capabilities and standards are the following:
- Bootstrapping communication (WS-MetaDataExchange)
- Securing communication (WS-SecurityPolicy, WS-Security, and WS-Trust)
- Optimizing communication (MTOM and WS-SecureConversation)
- Enabling reliability (WS-ReliableMessaging)
- Enabling atomic transactions (WS-Coordination and WS-AtomicTransactions)
Note that because WSIT-based clients and services are interoperable, you are able to realize the benefits of WSIT without using WCF. Also above supporting enterprise features related to web services specifications, WIST also covers message optimization, reliable messaging, and security, WSIT includes a bootstrapping and configuration technology. The figure below shows the underlying services that were implemented for each technology:
Most web services initially relied on transport-based security such as SSL to provide point-to-point security. WSIT uses WS-Security to provide interoperable message content integrity and confidentiality, even when messages pass through intermediary nodes before reaching their destination endpoint. You can use WS-Security along with transport-level security for your system’s needs.
WSIT enhances security by also implementing WS-Secure Conversation that enables a consumer and provider to establish a shared security context when a multiple-message-exchange sequence is first initiated. All subsequent messages then use derived session keys, which increase overall security while reducing the security processing overhead for each message. We have discussed WS-Secure Conversation in the article, “Tutorial:Review of Web Service Security for the Web Service Developer Exam”. WSIT also implements two other additional features to improve security in web services:
- Web Services Security Policy—that enables web services to use security assertions to clearly represent security preferences and requirements for web service endpoints.
- Web Services Trust—that enables web service applications to use SOAP messages to request security tokens which can then be used to establish trusted communications between a client and a web service.
The WSIT implementation of these features ensures that web service binding security requirements, defined in the WSDL file, can interoperate with and be consumed by WSIT and WCF endpoints.
How WSIT Relates to Windows Communication Foundation (WCF)
We will be discussing the specifications for bootstrapping and configuration, message optimization, reliable messaging, and security technologies below. WSIT 1.0 implements the following versions of these specifications:
- WS-ReliableMessaging v1.0
- WS-ReliableMessaging Policy v1.0
- WS-AtomicTransaction v1.0
- WS-Coordination v1.0
- WS-Security v1.1
- WS-SecurityPolicy v1.1
- WS-Trust v1.0
- WS-SecureConversation v1.0
- WS-Policy v1.2
- WS-PolicyAttachment v1.2
In order to ensure interoperability the same versions of these specifications are implemented in WCF in .NET 3.0. Sun updated to these standard versions of these specifications in project Metro. These versions coincide with the versions used in WCF in .NET 3.5.
Bootstrapping and Configuration Specifications
Bootstrapping and Configuring is when a client obtaining a web service URL from possibly a service registry and getting the information required to build a web services client that is capable of accessing and consuming a web service over the Internet. Normally this information is found in a WSDL file. The figure below shows the specifications that were implemented to support bootstrapping and configuration:
￼Attachment 3282 Figure:Specifications Implemented Supporting Bootstrapping and Configuration
Bootstrapping and configuration implements the Core XML specifications as well as the following specifications:
- WSDL Web Services Description Language (WSDL) specification was 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 the means for communicating with the service via a particular transport. WSDL descriptions are normally stored in service registries and sometimes published on the Internet.
- Web Services Policy this specification provides a flexible and extensible grammar for expressing a web services’ capabilities, requirements, and general characteristics. It provides the mechanisms required for web services applications to specify policy information in a standardized way. The specification does not provide a protocol that constitutes a negotiation or message exchange solution for Web services, but specifies a building block that is used in conjunction with the WS-Metadata Exchange protocol. The policy is applied in the web services model in order to convey conditions on interactions between two web service endpoints. A typical scenario is for the provider of a web service to expose a policy to convey conditions under which it provides the service. The requester then 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 efficiently over the network. It is realized when web services communication uses messages that are encoded prior to transmission and then de-encoded when they reach their final destination. The figure below shows the specifications that were implemented to optimize communication between two web service endpoints:
Optimization implements the Core XML specifications as well as the following specifications:
- SOAP - JAX Web Services supports the SOAP wire protocol. SOAP implementations, transmits client requests and web service responses using Simple Object Access Protocol (SOAP) messages over HTTP to enable a completely interoperable exchange between clients and web services, irrespective of the platform the web service or client is running as well as at various locations on the Internet. HTTP is one of the foundational protocols of the internet based on its familiar request-and response standard for sending messages over the Internet. SOAP is an XML-based protocol that follows the HTTP request-and-response model. In SOAP 1.2 implementations, web service endpoint addresses can now be included in the XML-based SOAP envelope instead of in the transport header enabling SOAP messages to be transport independent.
- Web Services Addressing - this specification defines a set of abstract properties and an XML Infoset representation that can be bound to a SOAP message in order to reference web services and 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 provide the information needed to address a web service endpoint. The specification defines two constructs: message addressing properties and endpoint references, that normalize the information provided typically by transport protocols and messaging systems so that it is independent of any particular transport or messaging system. This is done by defining XML tags for including web service addresses in the SOAP message rather than in the HTTP header. These features enables messaging systems to support message transmission in a transport-neutral manner through networks including the various types of processing nodes such as endpoint managers, firewalls, and gateways.
- Web Services Secure Conversation - this specification provides enhanced message-level security and efficiency in multiple-message exchanges in a standardized way. It defines the basic mechanisms on which secure messaging semantics can be defined for multiple-message exchanges and allows for contexts to be established while facilitating more efficient keys or new key material to be exchanged. The benefit of all of this is increased overall performance and security of the subsequent exchanges.
- SOAP MTOM - this specification stands for SOAP Message Transmission Optimization Mechanism (MTOM). In conjunction with the XML-binary Optimized Packaging (XOP) it provides standard mechanisms for optimizing the transmission and/or wire format of SOAP messages by encoding selectively certain portions of the SOAP message while still presenting an XML Infoset to the SOAP application. This mechanism enables the definition of hop by hop contract between a SOAP node and the next SOAP node in the SOAP message path in order 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.
The Inner Workings of Message Optimization
Message optimization is all about efficiency. It ensures web services messages are transmitted over the Internet as efficiently as possible. As XML is a textual format, binary files can only be represented using character sequences before being embedded in an XML document. One of the more frequently used encoding algorithms that permits embedding is known as base64 encoding. This corresponds to the XML Schema data type xsd:base64Binary. Any web services toolkit supporting a binding framework, a base64 encoding value of this type is encoded before transmission and decoded before binding. The encoding and decoding process is expensive. The costs increase linearly as the size of the binary object increases.
Message optimization facilitates the ability of web service endpoints to identify large binary message payloads, remove the message payloads from the body of the SOAP message, encode the message payloads using an efficient encoding mechanism to reduce the size of the payloads and then re-insert the message payloads into the SOAP message as attachments by means of an Include tag. This permits message optimization to be achieved through the encoding of binary objects prior to transmission and then de-encoding them when they reach their final destination. In the optimization process the sending endpoint checks the body of the SOAP message for XML encoded binary objects exceeding a predetermined size and encodes those objects for efficient transmission over the Internet.
To address the problems and inefficiencies related to the transmission of binary data in SOAP documents, SOAP MTOM is paired with the XML-binary Optimized Packaging (XOP). The combination of these two allow for XML messages to be dissected in order to transmit binary files as MIME attachments such that is transparent to the application. This type of transformation is restricted to base64 content in canonical form as defined in XSD Datatypes specified in XML Schema. Doing this practically normally involves setting certain parameters in your IDE for the selected Web service. Below is an example in Net Beans of the configuration of a web service set to optimize messages that it transmits and to decode optimized messages that it receives:
In summary, WSIT technology achieves message optimization by implementing the MTOM and XOP specifications. When the message optimization feature enabled, one can send small binary objects in-line in the SOAP body and large binary objects are separated from the SOAP body, encoded and then sent as an attachment to the SOAP message. When the SOAP message reaches its destination endpoint, it is decoded.
Reliable Messaging Specifications
Reliability is measured by a system’s ability to deliver messages from point A to point B without error. The figure below shows the specifications that were implemented to ensure reliable delivery of messages between two web services endpoints:
Attachment 3285 Figure:Reliable Message Specifications Implemented for WIST
Reliable Messaging implements the Core XML specifications, supporting standards for Web Services Security and Web Services Policy as well as the following specifications:
- Web Services Reliable Messaging - this specification defines a messaging protocol to manage the reliable delivery of messages between exactly two parties, a source and a destination. It provides 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 can be extended to allow for additional functionality, such as security, to be tightly integrated. The implementation of this specification integrates both 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. It is used by Web Services Atomic Transactions. The implementation of the 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 the semantics of two-phase commit in a way that either all operations invoked within an atomic transaction succeed or are all rolled back. These implementations of this specification require the implementation of the Web Services Coordination specification.
The Inner Workings of Reliable Messaging
The enablement of reliable messaging allows for messages to be grouped into sequences that are defined by the client’s proxies. Each proxy corresponds to a message sequence consisting of all of the request messages for that particular proxy. Each message has a sequence header which includes a sequence identifier identifying the sequence as well as a unique message number that indicates the order of the message in the sequence. The web service endpoint uses the sequence header information for grouping messages and then process them in the proper order if the Ordered Delivery option is selected. Also if secure conversation is enabled, each message sequence will be assigned its own security context token, which is used to sign the handshake messages initializing communication between two web service endpoints and subsequent application messages.
So Reliable Messaging technology uses web service endpoints to collaborate and determine which messages in a particular application message sequence arrived at a particular destination endpoint and which messages require resending. The reliable messaging protocol requires the destination endpoint to return message-receipt acknowledgements that include the sequence identifier and the message number of each of the messages received. If the source has determined that a particular message has not been received by the destination, it will resend the message and request an acknowledgement. Once the source has sent all messages for a given sequence and the receipt of all of the messages has been acknowledged by the destination, the source terminates the sequence.
The web service destination endpoint forwards the application messages to the application. If the option, ordered delivery, is configured then the destination endpoint reconstructs a complete stream of messages from the sequence in the exact order in which the messages were sent. It then sends them along to the destination application. By using the reliable messaging protocol, the destination endpoint can provide the following "delivery assurances" to the web service application:
- Each message is delivered to the destination application at least once.
- Each message is delivered to the destination application at most once.
- Sequences of messages are grouped via sequence identifiers and then delivered to the destination application in the order defined by the message numbers.
Below is the list of reliable messaging configuration options:
In order to show the differences in the level of communication between the client and web service due to Reliability Messaging protocol, the first figure below shows a client and web service where Reliable Messaging protocol is not used:
￼Attachment 3287 Figure: Typical Message Exchange without Reliable Messaging
As the figure shown, in the absence of the Reliable Messaging protocol, the application messages flow over the HTTP connection with no delivery assurances. Any messages lost in transit or delivered out of order, will never be known by the communicating endpoints. The second figure shows an example of a client and web service using the Reliable Messaging protocol for application message exchanges:
When reliable messaging is enabled, the Reliable Messaging source module is connected into the JAX-WS web service client. The source module transmits the application messages but keeps copies of the messages until their receipt is acknowledged by the destination module via the exchange of protocol messages. The destination module acknowledges messages and possibly buffers them for ordered-delivery guarantee. If the destination modules is configured for guaranteeing order, the destination module allows the messages to proceed through the JAX-WS dispatch for delivery to the endpoint or application destination.
The security specifications are implemented to secure communication between two web service endpoints and across intermediate endpoints. The figure below shows the specifications that were implemented for secure communication between two web services endpoints and across intermediate endpoints:
Secure Specification implements the Core XML specifications, supporting standards for Web Services Addressing and Web Services Policy as well as the following specifications:
- Web Services Security - this specification defines a standard set of SOAP extensions which one can use for building secure web services implementing message content integrity and confidentiality. Web Services Security provides message content integrity and confidentiality even for web service communication traversing intermediate nodes. It can be used with a wide variety of security models such as PKI, Kerberos and SSL. It also provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies.
- Web Services Policy - this standard provides a general model used for expressing all types of domain-specific policy models such as transport-level security, resource usage policies, QoS characteristics, and end- to-end business-process-level policies. The specification provides a flexible as well as an extensible grammar for expressing the capabilities, requirements, and general characteristics of a web service. It provides a model and framework for the expression of these properties as policies and as a building block for Web Services Security policy.
- Web Services Trust - this specification supports the following capabilities:
- It defines extensions to Web Services Security that provide methods for issuing, renewing, and validating security tokens used by Web services security.
- It establishes, assesses the presence of, and brokers trust relationships.
- Web Services Secure Conversation - this specification defines a standardized way to provide enhanced message-level security and efficiency for multiple-message exchanges. The implementation provides the basic mechanisms above which secure messaging semantics can be defined for multiple-message exchanges. It allows for the establishment of contexts along with more efficient keys or new keys. This approach improves the overall performance and security of the subsequent exchanges. Although the specification focuses on the message authentication model, it still has several holes that can be attacked. This is addressed by the Secure Conversation authentication specification that defines a standardized way to authenticate a series of messages. The Web Services Security Conversation model defines the security context as a new Web Services security token type obtained by using a binding of Web Services Trust.
- Web Services Security Policy - this specification defines sets of assertions or a standardized set of patterns representing common ways to describe the securing of messages on a communications path.
This implementation allows flexibility in terms of tokens, cryptography, and the mechanisms used such as transport security while ensuring interoperability based on assertion matching by web service clients and web services providers.
The Inner Workings of Security
Let’s describe the inner workings of the WSIT security technologies, security policy, trust, and secure conversation.
The Inner Workings of Security Policy
The WSIT Web Service Security Policy implementation is constructed on top of features provided in the Web Service Policy implementation in WSIT. It allows for users to use XML elements to specify the security requirements for a web service endpoint. This means that messages can be secured on the communication path between the client and the web service. This is done by assertions from web service endpoint specifying the security requirements to the client. The figure below demonstrates this:
The WSDL file supplies the security policy model for associating policy assertions with web service communication. This results in, where possible, security policy assertions without parameters or attributes enabling first-level, QName-based assertion matching that is done at the framework level without security domain-specific knowledge. This first-level matching provides a narrowed set of policy alternatives shared by the client and web service endpoint when there is an attempt to establish a secure communication path.
The benefit of using assertions to represent security requirements is that QName matching is often sufficient to find common security alternatives so that many aspects of security can be factored out and re-used. Consider that the security mechanism is constant for a web service endpoint, but whether message parts are protected, or secured, can vary by message action.
The types of assertions are supported are the following:
- Protection assertions - these define the scope of security protection. They identify the message parts that are to be protected and whether data integrity and confidentiality mechanisms are to be used.
- Conditional assertions - these define general aspects or pre-conditions of the security. They define the relationships within as well as the characteristics of the environment in which security is being applied. This can include the tokens that can be used for integrity or confidentiality protection, the applicable algorithms to use, etc.
- Security binding assertions - these define the security mechanism used to provide security. They are a logical grouping defining how the conditional assertions are used to protect the indicated message parts. For example, an asymmetric token can be used with a digital signature to provide integrity protection, while those parts are encrypted with a symmetric key, which is then encrypted using the public key of the recipient. Overall, the security binding assertions restrict what can be placed in the wsse:Security header and the associated processing rules.
- Supporting token assertions - these define the token types and usage patterns used to secure individual operations and/or parts of messages.
- Web Services Security and Trust assertions - these define the token referencing and trust options that can be used.
WSIT Configuration and WS-Policy Assertions
The WSIT features are enabled and configured by using a mechanism defined by the Web Services Policy Framework (WS-Policy) specification. The web service expresses its requirements and capabilities via policies embedded in the service’s WSDL description. A web service consumer, or client can then verify it’s ability to handle the expressed requirements and can optionally use server capabilities advertised in policies.
Each of individual WSIT technologies such as Reliable Messaging, Addressing, or Secure Conversation provide a set of policy assertions that it can process. These assertions provide the configuration details required for the WSIT run-time to enable proper operation of the WSIT features used in a given web service. The assertions can specify particular configuration settings or just rely on default settings pre-determined by the particular technology. For example, below, the wsrm:AcknowledgementInterval and wsrm:Inac- tivityTimeout settings are both optional. The following listing shows WS-Policy assertions for WS-Addressing and WS-Reliable Messaging:
The listing is valid in both a WSIT configuration file (i.e. wsit-<pack- age>.<service>.xml) or in a WSDL file.
The Inner Workings of Trust
The simplest means of showing how Trust works is by showing you a figure and then going through the steps of the interaction. The figure below shows the establishment of a trust relationship using the Web Services Trust technology:
The steps required to establish a trust relationship between a client, a Security Token Service, and a web service are the following:
- The client establishes an HTTPS connection with the Secure Token Service using one of the following methods:
- Username Authentication and Transport Security - in this method, the client authenticates to the Security Token Service using a username token. The Security Token Service then uses a certificate to authenticate to the Client. For message protection, transport secrity is employed.
- Mutual Authentication - in this method, X.509 certificates are bused on both the client-side and server-side to authenticate to each other. The client request is signed by the Client’s X509 certificate and subsequently signed using ephemeral key. The web service then signs the response using keys derived from the client’s key.
- The client sends a RequestSecurityToken message to the Security Token Service.
- The Security Token Service returns a Security Assertion Markup Language (SAML) token to the Client.
- The client now uses the SAML token to authenticate itself to the web service and the trust relationship is established.
For this message exchange, SOAP messages are used for communication.
The Inner Workings of Secure Conversation
It is possible to establish a secure conversation without using Trust technology but instead using Web Services Secure Conversation technology. The figure below shows the establishment of type of conversation:
As the figure shows, to establish a secure conversation between a Client and a web service without using Trust technology, you need to do the following:
- The client sends a X509 Certificate in order to authenticate itself to the web service.
- The web service returns a X509 Certificate to authenticate itself to the client.
For this message exchange, SOAP messages are used for communication.
WSIT Configuration Files
Whenever we want to take advantage of WSIT features, we need to configure these features using WSIT configuration files. There is one file each for the client-side and server side.
Server-Side Configuration File
The server-side WSIT configuration file is used when the Web service is deployed. It holds all the information about the configuring of WSIT features within the Web service. An example of this is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:port name="MonteCarloWSPort" binding="tns:MonteCarloWSPortBinding"/>
Client-Side Configuration File
The Client-Side Configuration file consists of two files:
<service>Service.xml - a file that must confirm to the WSDL specification. All the WSIT configuration information is written to this file.
wsit-client - this file is used by the client to configure WSIT features. It imports the <service>Service.xml file. The first listing below shows an example of a <service>Service file contains the information to authenticate via username with symmetric keys:
The next listing shows the wsit-client file:
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/ 01/
oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://MonteCarlo.me.org/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://MonteCarlo.me.org/" name="MonteCarloWSService" xmlns:tc="http://schemas.sun.com/ws/2006/05/trust/client" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" xmlns:sc="http://schemas.sun.com/2006/03/wss/client">
<xsd:import namespace="http://MonteCarlo.me.org/" schemaLocation="http://localhost:8080/MonteCarloApplication/ MonteCarloWSService?xsd=1">
<part name="parameters" element="tns:add">
<part name="parameters" element="tns:addResponse">
<binding name="MonteCarloWSPortBinding" type="tns:MonteCarloWS">
<port name="MonteCarloWSPort" binding="tns:MonteCarloWSPortBinding">
<soap:address location="http://localhost:8080/ MonteCarloApplication/MonteCarloWSService">
<sc:KeyStore wspp:visibility="private" storepass="changeit" type="JKS"
<sc:TrustStore wspp:visibility="private" storepass="changeit" type="JKS"
<?xml version="1.0" encoding="UTF-8"?>
<import location="MonteCarloWSService.xml" namespace="http://MonteCarlo.me.org/"/>
OK. That is it for WSIT. We are reaching the end of our series on preparing for the Web Services Developer Exam. The next article will be on Service Oriented Architecture and Web Services.