Microsoft recently announced the release of three new 'Web Services' specifications which support its effort to "combine the best aspects of component-based development and the Web, and provide a cornerstone of the Microsoft .NET programming model." The specifications are provided "as-is, for review and evaluation only." (1) SOAP Routing Protocol (SOAP-RP) is a "SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries. In addition, SOAP-RP provides an optional reverse message path enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. SOAP-RP is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This specification defines the use of SOAP-RP in combination with TCP, UDP, and HTTP but other underlying protocols are possible." (2) Direct Internet Message Encapsulation (DIME) is a "lightweight, binary encapsulation format that can be used to encapsulate multiple application defined entities or payloads of arbitrary type and size into a single message construct. It is used by SOAP-RP as the encapsulation mechanism when exchanged directly over TCP or UDP in order to support encapsulation of attachments to the SOAP-RP message as well as to provide efficient message delimiting." (3) XLANG is an "XML business process language which provides a way to orchestrate applications and XML Web services into larger-scale, federated applications by enabling developers to aggregate even the largest applications as components in a long-lived business process. XLANG has a two-fold relationship with WSDL. An XLANG service description is a WSDL service description with an extension element that describes the behavior of the service as a part of a business process. XLANG service behavior may also rely on simple WSDL services as providers of basic functionality for the implementation of the business process."

SOAP Routing Protocol. By Henrik Frystyk Nielsen and Satish Thatte (Microsoft). May 23, 2001. Abstract: "SOAP Routing Protocol (SOAP-RP) is a SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries. In addition, SOAP-RP provides an optional reverse message path enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. SOAP-RP is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This specification defines the use of SOAP-RP in combination with TCP, UDP, and HTTP but other underlying protocols are possible."

From the SOAP-RP introduction: "SOAP by itself does not define an actual message path along which a SOAP message is to travel. In order to provide the semantics for actually exchanging messages, SOAP can be bound to an application layer protocol such as HTTP or SMTP. These protocols define their own message path models and message exchange patterns that in general differ from the SOAP message model. In contrast, SOAP-RP describes the entire message path within the SOAP message structure using the SOAP extensibility model. This means that a SOAP-RP enabled SOAP message does not require a binding to another application layer protocol for describing the message path. Therefore, in addition to being carried within HTTP, SOAP-RP allows a SOAP message to be exchanged directly over transport layer protocols such as TCP and UDP. This specification defines the use of SOAP-RP in combination with TCP and UDP as well as HTTP but other protocols are possible. Note that it is not the intent of SOAP-RP to provide a complete set of services often considered part of reliable messaging, security, or other services that may be required in a messaging environment. Rather, the design goal is to provide a building block that can be used in combination with other SOAP based protocols to archive such goals."

Direct Internet Message Encapsulation (DIME). By Henrik Frystyk Nielsen, Henry Sanders, and Erik Christensen (Microsoft). May 23, 2001. Abstract: "This document defines the media type "application/dime". Direct Internet Message Encapsulation (DIME) is a lightweight, binary encapsulation format that can be used to encapsulate multiple application defined entities or payloads of arbitrary type and size into a single message construct. The only parameters described by DIME is the payload type, the length, and an optional payload identifier. The type is identified by either a URI or a registered media type and the length by an integer indicating the number of octets of the payload. The optional payload identifier is in the form of a URI enabling cross-referencing between payloads. The format is strictly an encapsulation format and provides no concepts of a connection or logical circuit and does not address head-of-line problems. It is designed to make as few assumptions about the underlying or encapsulating protocol as possible."

XLANG: Web Services for Business Process Design. By Satish Thatte (Microsoft). Abstract and status: "Automation of business processes based on web services requires a notation for the specification of message exchange behavior among participating web services. This document specifies such a notation. We call it XLANG. XLANG is expected to serve as the basis for automated protocol engines that can track the state of process instances and help enforce protocol correctness in message flows. This is an initial public draft release of the XLANG specification that focuses on the language constructs used to define the behavior of an individual web service that participates in business processes. We also address the approach to combining such services into multi-party business processes. This release does not provide detailed examples and tutorial exposition. We anticipate a number of extensions to the feature set of XLANG that are discussed briefly at the end of the document."