WS-Eventing and WS-transfer Web Service Standards

Transmission (transfer)
WS-transfer describes the basic operations required to manage data entities accessed through Web Services. To understand WS-transfer, we need to introduce two new terms: factory and resource ). A factory is a Web service that can create resources in its XML Representation. WS-transfer introduces operations for creating, updating, retrieving, and deleting resources. It should be noted that for resource status maintenance, the host server can only do its best. When the client learns that the server has accepted the request to create or update a resource, it can properly predict the location where the resource is currently located and has a definite representation, but this is not a guarantee-even if there is no third party. The server may change the representation of a resource, delete a resource, or restore a deleted resource. This lack of assurance is consistent with the loose coupling model provided by the web. If necessary, the service can provide additional guarantees necessary for the non-web service architecture.

The creation, update, and deletion operations of WS-transfer extend the read-only operation function in WS-metadataexchange. The retrieval operation is exactly the same as the get operation in WS-metadataexchange. The CREATE request is sent to the factory. Then, the factory creates the requested resource and determines its initial representation. The factory is assumed to be different from the created resource. A new resource is allocated to an endpoint that is returned in the Response Message and determined by the Service. The put Operation provides a replacement representation to update resources. A one-time snapshot in the resource representation is the same as a get operation in WS-metadataexchange. It can also be retrieved through the get operation in WS-transfer. After the delete operation is successful, the resource cannot be referenced by the endpoint. These four metadata management operations constitute the basis for building State management in Web Services.

Event (Eventing)
In a system composed of services that need to communicate with each other, asynchronous message transmission may be used. In many cases, the information generated by one service is also required by other services. Due to poor scalability, polling is often not an effective way to obtain this information; there are too many unnecessary messages sent over the network. On the contrary, this architecture requires an explicit notification mechanism when an event occurs. More importantly, the binding between the source service and the user service must be completed dynamically at runtime. Therefore, the Web service architecture provides a lightweight event protocol.

WS-Eventing details the mechanisms for implementing the following four entity interactions: subscribers, subscription managers, event sources, and event receipt. This allows a web service to register its interest in the specific events provided by another Web Service (event source) as a subscription. Such registration is called subscription. WS-Eventing defines the operations that a service can provide to support subscription creation and management. When the event source determines that an event has occurred, it will provide this information to the Subscription Manager. The Subscription Manager can then send the event to all matched subscriptions, similar to the publishing topic in the traditional publishing/subscription event notification system. The Web service architecture provides comprehensive flexibility for Topic definition, organization, and discovery. It provides a general management infrastructure for subscriptions that may be used in many different application scenarios. You can also subscribe to rental resources, but all resources must be withdrawn. The main mechanism used to reclaim resources is the expiration time of each subscription. There is also a mechanism to query the subscription status. Additional operation specifications to help subscribers manage their subscription items (including renewal, notification, and cancellation requests) are also described in detail. Of course, any service can terminate the subscription at any time, which is consistent with the autonomy principle of all web services. The subscription termination message allows the event source to know that the subscription is terminated too early.

Although the general mode of event-based asynchronous messages is very common, different applications usually require different event transfer mechanisms. For example, simple asynchronous messages may be the best choice in some cases. However, if event receipt can control the message stream and message arrival time through polling, other cases may be more suitable. When the receiving fails to reach the destination from the source, polling is also necessary if the receiving is blocked by a firewall. The transfer mode concept introduced in WS-eventing is used to support these requirements. The transfer mode is used as an extension point to provide a means to establish a custom transfer mechanism for subscribers, event receiving, and event sources. The following management specifications use this mechanism.

Event agents can be used to aggregate or reassign notifications from different sources. They can also be used as independent subscription managers. Both methods are supported by WS-Eventing. A proxy can play several important roles in the system. Topics can be organized and used according to specific application classes. A proxy can act as a notification aggregation device to integrate event information from multiple sources. They can also act as filters, which receive more messages than the filters used for their own notifications. This flexibility is required to deploy a robust and scalable notification system.

WS-Eventing for WCF: http://www.codeproject.com/useritems/WSEventing.asp
WS-transfer service for workflow: http://www.codeproject.com/useritems/WSTransferWorkflow.asp