WS-Bluff is a varient of "Call My Bluff" developed as a game by psd to be played at the XML Summer School, the rationalle behind the game is explained in a blog post.
Web services exchange XML documents with structured payloads. The processing semantics of an execution endpoint may be influenced by additional information that is defined at layers below the application protocol. When multiple Web services are used in combination, the ability to structure execution related data called context becomes important. This information is typically communicated via SOAP Headers. WS-Context provides a definition, a structuring mechanism, and service definitions for organizing and sharing context across multiple execution endpoints. The ability to compose arbitrary units of work is a requirement in a variety of aspects of distributed applications such as workflow and business-to-business interactions. By composing work, we mean that it is possible for participants in an activity to be able to determine unambiguously whether or not they are participating in the same activity. An activity is the execution of multiple Web services composed using some mechanism external to this specification, such as an orchestration or choreography. A common mechanism is needed to capture and manage contextual execution environment data shared, typically persistently, across execution instances.
WS-BusinessActivity "provides the definition of the business activity coordination type that is to be used with the extensible coordination framework. The WS-BusinessActivity specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion, and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of long-running distributed activities." WS-BusinessActivity addresses the coordination of activities that apply business logic to handle business exceptions: actions are applied immediately and are permanent; compensating actions may be invoked in the event of an error. The Business Activity specification defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations
The WS-Inspection specification provides an XML format for assisting in the inspection of a site for available services and a set of rules for how inspection related information should be made available for consumption. A WS-Inspection document provides a means for aggregating references to pre-existing service description documents which have been authored in any number of formats. These inspection documents are then made available at the point-of-offering for the service as well as through references which may be placed within a content medium such as HTML. Specifications have been proposed to describe Web Services at different levels and from various perspectives. It is the goal of the proposed Web Services Description Language (WSDL) to describe services at a functional level. The Universal Description, Discovery, and Integration (UDDI) schema aims at providing a more business-centric perspective. What has not yet been provided by these proposed standards is the ability to tie together, at the point of offering for a service, these various sources of information in a manner which is both simple to create and use. the WS-Inspection specification addresses this need by defining an XML grammar which facilitates the aggregation of references to different types of service description documents, and then provides a well defined pattern of usage for instances of this grammar. By doing this, the WS-Inspection specification provides a means by which to inspect sites for service offerings. Repositories already exist where descriptive information about Web services has been gathered together. The WS-Inspection specification provides mechanisms with which these existing repositories can be referenced and utilized, so that the information contained in them need not be duplicated if such a duplication is not desired.
WS-Security] defines the basic mechanisms for providing secure messaging. This specification uses these base mechanisms and defines additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains. In order to secure a communication between two parties, the two parties must exchange security credentials (either directly or indirectly). However, each party needs to determine if they can "trust" the asserted credentials of the other party. In this specification we define extensions to [WS-Security] that provide: Methods for issuing, renewing, and validating security tokens. Ways to establish assess the presence of, and broker trust relationships. Using these extensions, applications can engage in secure communication designed to work with the general Web services framework, including WSDL service descriptions, UDDI businessServices and bindingTemplates, and [SOAP] [SOAP2] messages. To achieve this, this specification introduces a number of elements that are used to request security tokens and broker trust relationships.
OASIS 2007. The primary goal of this specification is to create a mechanism for the transfer of messages between two endpoints when the sending endpoint is unable to initiate a new connection to the receiving endpoint. It defines a mechanism to uniquely identify non-addressable endpoints, and a mechanism by which messages destined for those endpoints can be delivered. It also defines a SOAP binding that is required for interoperability. Additional bindings can be defined. This mechanism is extensible allowing additional functionality, such as security, to be tightly integrated. This specification integrates with and complements the WS-ReliableMessaging[WS-RM], WS-Security [WS-Security], WS-Policy [WS-Policy], and other Web services specifications. Combined, these allow for a broad range of reliable, secure messaging options.
Web Service Atomic Transaction is an OASIS standard. To achieve all-or-nothing property for a group of services, it defines three protocols ('i.e.', completion, volatile two-phase commit, and durable two-phase commit), and a set of services. These protocols and services together ensure automatic activation, registration, propagation and atomic termination of Web Services.
W3C Submission, 2005. When sending SOAP messages in an environment where the two endpoints (source and destination) are not able to freely open connection in both directions, delivery of asynchronous messages becomes problematic. Perhaps the most common scenario being where the initiator (client) of a Web service call is behind a firewall so any messages initiated from the service back to the client can not be delivered. Another common case is where the client does not have a SOAP listener (i.e. server) running to receive asynchronous messages. In both of these cases, in order for the service to deliver a message to the "unreachable" client endpoint it becomes necessary for the client to initiate the connection, thus allowing the message to be sent back on the response flow of the connection. This specification defines a mechanism through which an endpoint may initiate a connection to another endpoint for the purposes of allowing messages from the destination/service endpoint to be delivered back to the source/client.
W3C August 2010. Web services use metadata to describe what other endpoints need to know to interact with them. Specifically, [WS-Policy] describes the capabilities, requirements, and general characteristics of Web services; [WSDL11] describes abstract message operations, concrete network protocols, and endpoint addresses used by Web services; XML Schema [XMLSchema - Part 1], [XMLSchema - Part 2] describes the structure and contents of XML-based messages received by and sent by Web services.The mechanisms defined herein are intended for the retrieval of metadata (i.e., Web service description information) only. They are not intended to provide a general purpose query or retrieval mechanism for other types of data associated with a Web service, such as state data, properties and attribute values, etc.
This specification is intended to form a core component of a unified resource access protocol for Web services. The operations described in this specification define standard messages for controlling resources using the familiar paradigms of "get", "put", "create", and "delete". The extensions deal primarily with fragment-based access to resources.
OASIS 2004. The Event-driven, or Notification-based, interaction pattern is a commonly used pattern for inter-object communications. Examples exist in many domains, for example in publish/subscribe systems provided by Message Oriented Middleware vendors, or in system and device management domains. This notification pattern is increasingly being used in a Web services context. WS-Notification is a family of related specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. It includes: standard message exchanges to be implemented by service providers that wish to participate in Notifications, standard message exchanges for a notification broker service provider (allowing publication of messages from entities that are not themselves service providers), operational requirements expected of service providers and requestors that participate in notifications, and an XML model that describes topics. The WS-Notification family of documents includes three normative specifications: [WS-BaseNotification], WS- BrokeredNotification, and [WS-Topics].
BEA. "This specification describes the WS-CallBack protocol. WS-CallBack is used to dynamically specify where to send asynchronous responses to a SOAP request." "The CallBack header is needed in cases where a web service is using asynchronous communication and the address to which to send responses is not known at deployment time. In order to enable asynchronous responses to requests the requestor must specify in the request where to send the responses. The WS-CallBack protocol provides the SOAP and WSDL 1.1 mechanisms needed to enable this behavior." "A WS-CallBack sender sends a WS-CallBack request containing a CallBack header with a callbackLocation element. The WS-CallBack receiver then sends its response(s) to the URI listed in the callbackLocation element." "The CallBack header must contain the SOAP mustUnderstand attribute with the value equal to 1 and must contain a callbackLocation element. In the absence of an explicit out-of-band agreement the scheme of the URI in the first callbackLocation element MUST be of the same scheme used to deliver the WS-CallBack request. E.g. if the request was delivered over HTTP and there is no explicit agreement to the contrary then the URL in the callbackLocation element must be of type 'http'."
Protocol designed to enable WS-Acknowledgement senders to request explicit acknowledgement from WS-Acknowledgement receivers that a WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been received. An Acknowledgement message only acknowledges the receipt of the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message. No guarantee is made that the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been or will ever be processed. If the WS-Acknowledgement sender does not receive an acknowledgement within the pre-arranged retry interval then the WS-Acknowledgement sender will repeat the WS-Acknowledgement Request Message. The WS-Acknowledgement sender will continue to repeat the WS-Acknowledgement Request Message until the WS-Acknowledgement sender has retried the pre-arranged maximum number of times or until it receives an acknowledgement message. As part of the configuration of a reliable messaging exchange between two parties it is possible to ask for duplicate elimination. In that case the WS-Acknowledgement receiver is required to keep a persistent record of what Message IDs have been received for a pre-arranged period of time. If the WS-Acknowledgement receiver should receive a message whose Message ID matches that of one already in the persistent store then the WS-Acknowledgement receiver will repeat the previous transmitted Acknowledgement message. It will then discard the repeated message. The exact behavior of a reliable message exchange is decided by a set of configuration parameters defined in section 8. The WS-Acknowledgement sender and receiver, using an out of band mechanism, must agree on these parameters before reliable messaging can be initiated. WS-Acknowledgement is designed to operate at the SOAP message level and its behavior is therefore independent of any transport to which the SOAP messages may be bound.
BEA. The Web Services Message Data (WS-MessageData) specification introduces the MessageData header which enables the re-use of meta-data about a message across SOAP extensions. As new types of message meta-data are standardized it is hoped that they will be placed inside of the MessageData header so as to more easily enable re-use. This specification defines an implementation [under which] each extension [of multiple extensions that agree upon the same token] could implicitly or explicitly refer to a single header that contained the token viz., by reference rather than by value. This specification introduces a single SOAP header that contains common values like a message identifier. The expectation is that other extensions will then rely on the meta-data in that header when defining their own behavior. The MessageData header is intended as an extensible repository for metadata about a message. For performance purposes it is preferable that the WS-MessageData appear before any SOAP headers that rely upon it... The MessageID element contains a Message ID that must be a URI that associates the message in which it appears with an identifier that is unique across all messages from all possible sources and for all time... The RefToMessageID element must only be used when a message has been generated directly in response to a single previous message. For example, in the case of a request/response pair where the transport is asynchronous the RefToMessageId element on the response message would contain the MessageId value contained in the requesting message."
WS-Coordination is a Web Services specification developed by BEA Systems, IBM, and Microsoft and accepted by OASIS Web Services Transaction TC in its 1.2 version. It describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed transactions. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally WS-Coordination describes a definition of the structure of context and the requirements for propagating context between cooperating services. However, this specification isn't enough to coordinate transactions among web services. It only provides a coordination framework, and other specifications like WS-Atomic Transaction or WS-BusinessActivity are needed for this purpose.
Microsoft: The Web Services Routing Protocol (WS-Routing), which was formerly known as the 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 through a set of intermediaries. In addition, WS-Routing provides an optional reverse message path that enables two-way message exchange patterns, such as request/response, peer-to-peer conversations, and the return of message acknowledgments and faults. WS-Routing is expressed as a SOAP header entry within a SOAP envelope, making it independent of the underlying protocol. SRMP uses several fields of the WS-Routing specification and ignores others. In particular, the actual routing-related fields are largely ignored. Instead, SRMP relies on HTTP and TCP/IP routing between the sender and the receiving Web service. This document describes the WS-Routing fields that SRMP uses. For more information about WS-Routing, see [MSDN-WSROUTING].
OASIS, part of BPEL4People. Human tasks, or briefly tasks enable the integration of human beings in service- oriented applications. This document provides a notation, state diagram and API for human tasks, as well as a coordination protocol that allows interaction with human tasks in a more service-oriented fashion and at the same time controls tasks’ autonomy. The document is called Web Services Human Task (abbreviated to WS- HumanTask for the rest of this document). Human tasks are services “implemented” by people. They allow the integration of humans in service-oriented applications. A human task has two interfaces. One interface exposes the service offered by the task, like a translation service or an approval service. The second interface allows people to deal with tasks, for example to query for human tasks waiting for them, and to work on these tasks. A human task has people assigned to it. These assignments define who should be allowed to play a certain role on that task. Human tasks may also specify how task metadata should be rendered on different devices or applications making them portable and interoperable with different types of software. Human tasks can be defined to react on timeouts, triggering an apropriate escalation action. This also holds true for notifications. Notifications are a special type of human task that allows the sending of information about noteworthy business events to people. Notifications are always oneway, i.e., they are delivered in a fire-and-forget manner: The sender pushes out notifications to people without waiting for these people to acknowledge their receipt.
OASIS 2004. Introduction: In this document, we consider a distributed computing environment consisting of Web services and stateful resources. A pattern defining the relationship between Web services and stateful resources is detailed in “Modeling Stateful Resources with Web services” [State Paper]. The term WS- Resource is used to describe the relationship between a Web service and a stateful resource. This WS-ServiceGroup specification defines a means by which Web services and WS-Resources can be aggregated or grouped together for a domain specific purpose. In order for requestors to form meaningful queries against the contents of the ServiceGroup, membership in the group must be constrained in some fashion. The constraints for membership are expressed by intension using a classification mechanism. Further, the members of each intension must share a common set of information over which queries can be expressed. In this specification, the ServiceGroup membership rules, membership constraints and classifications are expressed using the resource property model [WS-ResourceProperties]. Groups are defined as a collection of members that meet the constraints of the group. The ServiceGroupRegistration interface extends the basic ServiceGroup capabilities with message exchanges for managing the membership of a ServiceGroup. The ServiceGroup and ServiceGroupRegistration interfaces defined in this document are commonly expected to be composed with other application domain specific interfaces, which define more specialized interaction with the service group and/or with the services that are members of the service group. For example, specialized interfaces may offer means of querying the contents of the ServiceGroup, and for performing collective operations across members of the ServiceGroup. WS-ServiceGroup is inspired by a portion of the Global Grid Forum’s “Open Grid Services Infrastructure (OGSI) Version 1.0” specification [OGSI].
W3C Sumbission, March 2006, IBM, BEA, Microsoft. This specification describes a general SOAP-based protocol for enumerating a sequence of XML elements that is suitable for traversing logs, message queues, or other linear information models. There are numerous applications for which a simple single-request/single-reply metaphor is insufficient for transferring large data sets over SOAP. Applications that do not fit into this simple paradigm include streaming, traversal, query, and enumeration. This specification defines a simple SOAP-based protocol for enumeration that allows the data source to provide a session abstraction, called an enumeration context, to a consumer that represents a logical cursor through a sequence of data items. The consumer can then request XML element information items using this enumeration context over the span of one or more SOAP messages. Somewhere, state must be maintained regarding the progress of the iteration. This state may be maintained between requests by the data source being enumerated or by the data consumer. WS-Enumeration allows the data source to decide, on a request-by-request basis, which party will be responsible for maintaining this state for the next request. In its simplest form, WS-Enumeration defines a single operation, Pull, which allows a data source, in the context of a specific enumeration, to produce a sequence of XML elements in the body of a SOAP message. Each subsequent Pull operation returns the next N elements in the aggregate sequence.
OASIS TC. One of the most fundamental components of negotiating services is agreeing when something should occur, and in auditing when they did occur. Short running services have traditionally been handled as if they were instantaneous, and thereby dodged this requirement through just-in-time requests. Longer running processes may require significant lead times. When multiple long-running services participate in the same business process, it may be more important to negotiate a common completion time than a common start time. Central coordination of such services reduces interoperability as it requires the coordinating agent to know the lead time of each service. Other processes may have multiple and periodic occurrence. Identical processes may need to be requested on multiple schedules. Other processes must be requested to coincide with or avoid human interactions. An example is a process that occurs on the first Tuesday of every month. Others may need to be completed on schedules that vary by local time zone. Physical processes are now being coordinated by web services. Building systems and industrial processes are operated using oBIX, BACnet/WS, LON-WS, OPC XML, and a number of proprietary specifications including TAC-WS, Gridlogix EnNet, and MODBUS.NET. Energy use in buildings can be reduced while improving performance if building systems are coordinated with the schedules of the buildings occupants
The text for True sections has been quoted under reasonable use from the specification referenced, otherwise this work is released under a Creative Commons License