ws-eventing, Ws-transfer Web service standards

Transmission (Transfer)
Ws-transfer details the basic operations required to manage data entities that are accessed through Web services. To understand Ws-transfer needs to introduce two new terms: Factory (Factory) and resources (Resource). A factory is a Web service that can create resources from its XML representation. Ws-transfer introduces operations for creating, updating, retrieving, and deleting resources. It should be noted that for resource state maintenance, the host server can only do its best. When a client learns that a server has accepted a request to create or update a resource, it can properly anticipate where the resource is currently located and has a defined representation, but this is not a guarantee-even in the absence of any third party. The server may change the representation of a resource, may completely delete a resource, or it may recover a resource that has already been deleted. The lack of this assurance is consistent with the loosely coupled model provided by the Web. If required, the service can provide additional guarantees that are required for a non-Web service architecture.

Ws-transfer's Create, update, and delete operations extend the read-only functionality 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. The factory then creates the requested resource and determines its initial representation. The factory is assumed to be different from the resource being created. The new resource is assigned to an endpoint reference that is returned in response messages and determined by the service. The put operation updates the resource by providing an alternate representation. A one-time snapshot of a resource representation, like a get operation in Ws-metadataexchange, can also be retrieved through a get operation in Ws-transfer. After the delete operation succeeds, the resource will no longer be available through the endpoint reference. These 4 meta data management operations form the foundation of State management in Web services.

Event (Eventing)
Asynchronous messaging may be used in systems consisting of services that need to communicate with each other. In many cases, the information generated by one service is also required by other services. Because of poor scalability, polling is often not an effective way to get this information; There are too many unnecessary messages sent over the network. Instead, the schema requires a mechanism that emits explicit notification when an event occurs. A more important requirement is that the bindings of the source and user services must be completed dynamically at run time. To do this, the Web services architecture provides a lightweight event protocol.

Ws-eventing details the mechanisms for implementing the following 4 entity interactions: Subscribers, subscription managers, event sources, and event reception. This enables a Web service to register its interest in a specific event provided by another Web service (event source) as a subscriber. This registration is called a subscription. Ws-eventing defines the actions that a service can provide to support subscription creation and management. When an event source determines that an event occurs, it supplies this information to the subscription manager. The subscription manager can then route the event to all matching subscriptions, similar to the published topic in the traditional publish/Subscribe event notification System. The Web services architecture provides overall flexibility in the way topics are defined, organized, and discovered, and provides a common management infrastructure for subscriptions that are likely to be used in many different applications. You can also subscribe to a leased resource, but you will eventually have to take it back. The primary mechanism for recovering resources is the expiration time for individual subscriptions. Query subscription status also has a mechanism that helps subscribers manage several of their subscription items, including renewal, notification, and unsubscribe requests, as well as detailed instructions in the additional operating specification. Of course, any service is free to terminate subscriptions at any time, consistent with the autonomic principles of all Web services. Subscription termination messages are available for event sources to notify subscriber subscriptions to terminate prematurely.

Although the general pattern of event-based asynchronous messages is common, different applications typically require different event-delivery mechanisms. For example, a simple asynchronous message might be the best choice in some cases, but other situations might be more appropriate if event reception can control the message flow and the message arrival time by polling. Polling is also necessary when receiving a destination that cannot be reached from the source, such as when a firewall is blocked. The concept of the transfer pattern introduced in ws-eventing is used to support these requirements. The transfer mode is used as an extension point to provide a means of establishing a custom delivery mechanism for subscribers, event receivers, and event sources. The following management norms take advantage of this mechanism.

The

     event agent can be used to aggregate or reassign notifications from different sources, and the agent can also be used as a stand-alone subscription manager. Both of these methods have been supported by ws-eventing. Agents can play a number of important roles in the system. Themes can be organized using specific application classes. Agents can act as notification aggregates to consolidate event information from multiple sources. They can also act as filters, which are more than the messages they receive 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