لطفا منتظر باشید ...
Eventing
In systems made up of services that communicate among one another, possibly using asynchronous messaging, many scenarios exist in which information produced by one service is of interest to another service. Due to poor scaling characteristics, polling is often not an appropriate mechanism for obtaining such information; the risk is that too many unnecessary messages are sent through the network. Instead, the architecture requires a mechanism for explicit notifications when events occur. The Web services architecture supports this through a lightweight eventing protocol.WS-Eventing specifies mechanisms that allow a Web service, also referred to as a subscriber, to register interest in specific events that are provided by another Web service (the event source). This registration operation is called Subscription. WS-Eventing defines operations that a Web service can provide for creating and managing subscriptions. The service managing subscriptions, called the subscription manager, may or may not be the same service as the event source. When the subscription manager and the event source are different, all subscription management operations are directed to the subscription manager.When an event source determines that an event has occurred, it will provide that information to all of the matching subscriptions. This is similar to publishing topics or subjects in a traditional publish/subscribe event notification system. In contrast to traditional publish/subscribe systems, the Web services architecture provides complete flexibility in the way that topics are defined, organized, and discovered; it provides a common infrastructure for managing subscriptions that can be leveraged in many different application arenas.Subscriptions lease resources that must be eventually recovered. The primary mechanism used to reclaim resources is an expiration time for each subscription. There is also a mechanism to query the status of subscriptions: GetStatus. Additional operations to help subscribers manage their collection of subscriptions are Renew, Unsubscribe, and SubscriptionEnd. Of course, any service is free to end a subscription at any time, consistent with the principle of autonomy for all Web services. The subscription-end message can be used by the event source to notify subscribers of the premature termination of a subscription.Although the general pattern of asynchronous, event-based messages is common, different applications often require alternate event-delivery mechanisms. For instance, a simple asynchronous message might be optimal in some cases, and other situations might work better if the subscriber can control the flow and timing of message arrival through polling. The notion of delivery modes was introduced in WS-Eventing to support these requirements. Delivery mode is used as an extension point to provide a means for subscribers and event sources to establish tailored delivery mechanisms. The management specification described in the next chapter makes use of this mechanism.An event broker can be used to aggregate or redistribute notifications through different sources. This approach is supported by WS-Eventing. Brokers can play several important roles in a system. Topics may be organized for use by certain classes of applications. Brokers may act as notification aggregators that combine event information from multiple sources. They may also act as filters, receiving more messages than the ones they use for their own notifications. This flexibility is required to deploy robust and scalable notification systems.A WSDL annotation is used to provide a well-known, standard mechanism to discover the event sources provided by a service. These annotations are specified as attributes placed on WSDL portType elements. They identify the Web service as an event source and identify which messages are notifications. This attribute indicates that notifications and solicit-response operations of the portType are events exposed by a service with a port bound to this portType. Solicit-response event subscribers are expected to send responses to the event notices they receive. A policy is used to specify the supported delivery modes and filter types.
