The FASPSessionNET-200601 service can be used by an application to poll or allow subscriptions to notifications. This section goes over these two options in more detail. If you are familiar with service oriented architectures you should be accustomed to these mechanisms.
Notifications allow an application to subscribe to a set of events. When an event occurs, and an application is subscribed to it, a notification will be delivered to the application. In this scenario, the application is referred to as an observer. Implementing a notification observer allows an application to receive near real-time information about ongoing FASP session in an event-driven fashion.
In order to operate as an observer the application must act as a SOAP server, typically using HTTP as a transport layer. This introduces some complexity at the application-level. However, the benefits of being event-driven often justifies this. In order to act as an observer, an application registers a subscription to a set of topics. When the subscription is registered, the application identifies the endpoint that notifications will be delivered to. An endpoint is referenced by an address and an optional SOAP action. When an event occurs that corresponds to a subscribed topic, a notification will be delivered to the registered endpoint.
The mechanisms employed for delivering notifications are based on two standards. The first is Web Services Addressing, which is defined by the W3C. The second is Web Services Notification, defined by OASIS. Developers familiar with these standards will notice many similarities. Endpoints are identified by an EndpointReferenceType. This type has two elements, Address and Action. Address specifies the uniform resource identifier (URI) of the observer. Typically, this will take the form of http://observer.example.com/service/location. Action is used for routing any SOAP messages to the appropriate handler. The action is optional, and its value is usually dependent on the web services framework being used.
An application registers a subscription by invoking the Subscribe() method. This method includes two EndpointReferenceType objects, as well as a TopicExpressionType parameters. A topic expression contains an array of session topics that the application wants to subscribe to. The two endpoint references identify a subscription observer and a session observer. In a typical case, the address used will be identical for both observers; with only the action being different which allows the order message to be routed to the correct handler. When a subscription is established, a set of subscription topics are implicitly registered. Whenever an event occurs that corresponds to one of these topics a notification will be delivered to the subscription observer. This allows the observer to know when the subscription will expire or terminate, and maintain it as needed. The observer must implement the SubscriptionNotify() method in order to receive these notifications. However, the session topics must be explicitly requested by the observing application. This allows the observer to receive notifications corresponding to only those events in which it is interested. When a session event occurs that an observer is subscribed to a notification will be delivered through the SessionNotify() method; which the observing application must implement.
Applications can poll this service to find FASP sessions and query them for detailed information. The messages returned from ListSessions() and QuerySessions() provide the primary requirements needed to use these polling techniques. For example, An application can invoke ListSessions() which will return an array of session identifiers and one ID for each FASP session that is currently active. Once the list of IDs has been received it can be followed by multiple invocations of QuerySession() utilizing the IDs that were received earlier. Once this completes the application will have all of the details about any active FASP sessions. The polling interval can be determined by the requirements of your application. When the polling interval increases there is a higher potential to miss information. The needs of your application and expected use should be weighed to get the best performance while ensuring proper polling of the information.
The Observer and Session Management Web Services have a few items that have been deprecated. To learn more about these items please see the deprecated section under Resources or use the links below. It is not recommended to use these, instead you should use Reliable Query.