1.4. Metro 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
Metro implements the following WS-* specifications.
|Bootstrapping||since v1.0 : WS-MetadataExchange v1.1|
|Reliable Messaging (OASIS standards)||since v1.0 : WS-ReliableMessaging v1.0
since v1.0 : WS-ReliableMessaging Policy v1.0
since v1.3 : WS-ReliableMessaging v1.1
since v1.3 : WS-ReliableMessaging Policy v1.1
|Atomic Transactions (OASIS submissions)
Note: Metro does not implement the
standard versions of these specifications.
|since v1.0 : WS-AtomicTransaction v1.0
since v1.0 : WS-Coordination v1.0
|Security (OASIS standards)||since v1.0 : WS-Security v1.0
since v1.0 : WS-Security v1.1
since v1.0 : WS-SecurityPolicy v1.1
since v1.3 : WS-SecurityPolicy v1.2
since v1.0 : WS-Trust v1.2
since v1.3 : WS-Trust v1.3
since v1.0 : WS-SecureConversation v1.2
since v1.3 : WS-SecureConversation v1.3
|Security Profiles (OASIS standards)||since v1.3 All 1.0 and 1.1 profiles listed here except Web Services Security REL Token Profile V1.0|
|Policy (W3C standards)||since v1.0 : WS-Policy v1.2
since v1.0 : WS-PolicyAttachment v1.2
since v1.3 : WS-Policy v1.5
since v1.3 : WS-PolicyAttachment v1.5
Metro 1.3 + and WCF in .NET 3.5 implement the same specifications.
1.4.1. 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. Bootstrapping and Configuration Specifications shows the specifications that were implemented to support bootstrapping and configuration.
In addition to the Core XML specifications, bootstrapping and configuration was implemented using the following specifications:
- WSDL: 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.
1.4.2. 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.
Message Optimization Specifications shows the specifications that were implemented to optimize communication between two web service endpoints.
In addition to the Core XML specifications, optimization was implemented using the following specifications:
- SOAP: With SOAP
implementations, client requests and web service responses are most
often transmitted as 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: This specification defines a endpoint reference representation. 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 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.
1.4.3. Reliable Messaging Specifications
Reliability (in terms of WS-ReliableMessaging) is measured by a system’s ability to deliver messages from point A to point B regardless of network errors. Reliable Messaging Specifications shows the specifications that were implemented to ensure reliable delivery of messages between two web services endpoints.
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.
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.
1.4.4. Security Specifications
Web Services Security Specifications shows the specifications implemented to secure communication between two web service endpoints and across intermediate endpoints.
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.
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 Metro 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 Metro 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.