1.2. What is WSIT?

For three years (and continuing) Sun has worked closely with Microsoft to ensure interoperability of web services enterprise technologies such as security , reliable messaging, and atomic transactions. That portion of Metro is known as WSIT (Web Service Interoperability Technologies). Metro's WSIT subsystem is an implementation of a number of open web services specifications to support enterprise features. In addition to security, reliable messaging, and atomic transactions, Metro includes a bootstrapping and configuration technology. Metro's WSIT Web Services Features shows the underlying services that were implemented for each technology.

Metro's WSIT Web Services Features
Diagram showing Metro's WSIT web services features:
Core XML, Core Web Services, Bootstrapping, Security, and Reliability

Starting with the core XML support currently built into the Java platform, Metro uses or extends existing features and adds new support for interoperable web services. See the following sections for an overview of each feature:

1.2.1. Bootstrapping and Configuration

Bootstrapping and configuration consists of using a URL to access a web service, retrieving its WSDL file, and using the WSDL file to create a web service client that can access and consume a web service. The process consists of the following steps, which are shown in Bootstrapping and Configuration.

Bootstrapping and Configuration
Diagram showing bootstrapping and configuration
  1. Client acquires the URL for a web service that it wants to access and consume. How you acquire the URL is outside the scope of this tutorial. For example, you might look up the URL in a Web Services registry.
  2. The client uses the URL and the wsimport tool to send a WS-MetadataExchange Request to access the web service and retrieve the WSDL file. The WSDL file contains a description of the web service endpoint, including WS-Policy assertions that describe the security, reliability, transactional, etc., capabilities and requirements of the service. The description describes the requirements that must be satisfied to access and consume the web service.
  3. The client uses the WSDL file to create the web service client.
  4. The web service client accesses and consumes the web service.

Bootstrapping and Configuration explains how to bootstrap and configure a web service client and a web service endpoint that use the Metro's WSIT technologies.

1.2.2. Message Optimization Technology

A primary function of web services applications is to share data among applications over the Internet. The data shared can vary in format and include large binary payloads, such as documents, images, music files, and so on. When large binary objects are encoded into XML format for inclusion in SOAP messages, even larger files are produced. When a web service processes and transmits these large files over the network, the performance of the web service application and the network are negatively affected. In the worst case scenario the effects are as follows:

  • The performance of the web service application degrades to a point that it is no longer useful.
  • The network gets bogged down with more traffic than the allotted bandwidth can handle.

One way to deal with this problem is to encode the binary objects so as to optimize both the SOAP application processing time and the bandwidth required to transmit the SOAP message over the network. In short, XML needs to be optimized for web services. This is the exactly what the Message Optimization technology does. It ensures that web services messages are transmitted over the Internet in the most efficient manner.

Sun recommends that you use message optimization if your web service client or web service endpoint will be required to process binary encoded XML documents larger than 1KB.

For instructions on how to use the Message Optimization technology, see Message Optimization.

1.2.3. Reliable Messaging Technology

Reliable Messaging is a Quality of Service (QoS) technology for building more reliable web services. Reliability (in terms of what is provided by WS-ReliableMessaging) is measured by a system’s ability to deliver messages from point A to point B. The primary purpose of Reliable Messaging is to ensure the delivery of application messages to web service endpoints.

The reliable messaging technology ensures that messages in a given message sequence are delivered at least once and not more than once and optionally in the correct order. When messages in a given sequence are lost in transit or delivered out of order, this technology enables systems to recover from such failures. If a message is lost in transit, the sending system retransmits the message until its receipt is acknowledged by the receiving system. If messages are received out of order, the receiving system may re-order the messages into the correct order.

You should consider using reliable messaging if the web service is experiencing the following types of problems:

  • Communication failures are occurring that result in the network being unavailable or connections being dropped
  • Application messages are being lost in transit
  • Application messages are arriving at their destination out of order and ordered delivery is a requirement

To help decide whether or not to use reliable messaging, weigh the following advantages and disadvantages:

  • Enabling reliable messaging ensures that messages are delivered exactly once from the source to the destination and, if the ordered-delivery option is enabled, ensures that messages are delivered in order.
  • Enabling reliable messaging uses more memory (especially if the ordered delivery option is enabled) since messages must be stored (even after they are sent) until receipt is acknowledged.
  • Non-reliable messaging clients cannot interoperate with web services that have reliable messaging enabled.

For instructions on how to use the Reliable Messaging technology, see Using Reliable Messaging.

1.2.4. Security Technology

Until now, web services have relied on transport-based security such as SSL to provide point-to-point security. Metro implements WS-Security so as to provide interoperable message content integrity and confidentiality, even when messages pass through intermediary nodes before reaching their destination endpoint. WS-Security as provided by Metro is in addition to existing transport-level security, which may still be used.

Metro also enhances security by implementing WS-Secure Conversation, which enables a consumer and provider to establish a shared security context when a multiple-message-exchange sequence is first initiated. Subsequent messages use derived session keys that increase the overall security while reducing the security processing overhead for each message.

Further, Metro implements two additional features to improve security in web services:

  • Web Services Trust: Enables web service applications to use SOAP messages to request security tokens that can then be used to establish trusted communications between a client and a web service.
  • Web Services Security Policy: Enables web services to use security assertions to clearly represent security preferences and requirements for web service endpoints.

Metro implements these features in such a way as to ensure that web service binding security requirements, as defined in the WSDL file, can interoperate with and be consumed by Metro and WCF endpoints.

For instructions on how to use the WS-Security technology, see Using WSIT Security.

Terms of Use; Privacy Policy; Copyright ©2013-2017 (revision 20160708.bf2ac18)
Please Confirm