Managing Subscriptions Behavior Model

Copyright © 2010 Open Geospatial Consortium, Inc. 41 If push based delivery is requested, the provider creates a new subscription object in which the deliveryTo endpoint is set to the value provided in the proposed subscription. If pull based delivery is requested, the provider first creates a new pull endpoint and then sets this endpoint as the value of the deliveryTo property of the new subscription object. The following diagram shows the interactions involved in creating and managing a subscription. Client Producer Subscription 1.0 getPublications : Publication[] 1.1 createSubscription 1.2 subscribeSubscription :Subscription 2.0 getSubscriptions :Subscription[] 3.0 getResourceGenericName :Resource 4.0 renewTM_Instant : Boolean 5.0 terminate : Boolean Figure 15: Subscriber Interactions The following table explains the interactions shown in Figure 15. 42 Copyright © 2010 Open Geospatial Consortium, Inc. Table 27: Explanation of Subscriber Interactions Messages Notes Msg: 1.0 From: Client To: Producer The client retrieves the list of all currently existing Publications from the Producer. Msg: 1.1 From: Client To: Subscription Based upon the information about available Publications, the client creates a new Subscription that is going to be proposed to the Producer. Note: for simplicity only one Subscription is modelled here. In a web service environment, it is more likely that two distinct subscription resources will be created: one governed by the client which is proposed to the producer and one governed by the producer that was created based upon the proposed subscription. Msg: 1.2 From: Client To: Producer The client subscribes at the Producer by sending a subscription proposal. The Producer sends a pointer to the accepted subscription in the response. Msg: 2.0 From: Client To: Producer The client may retrieve the list of all currently existing Subscriptions from the Producer. Msg: 3.0 From: Client To: Producer The client may retrieve a Resource hosted by the Producer by its name. Msg: 4.0 From: Client To: Subscription The client renews the subscription by setting a new termination time. Msg: 5.0 From: Client To: Subscription The client terminates the subscription. Figure 16 shows that a Broker only starts matching new events against a subscription when the response to the subscription has been sent to the Subscriber. Copyright © 2010 Open Geospatial Consortium, Inc. 43 Broker Producer Client :Consumer Subscriber loop [for each message in Notification] 1.0 receiveNotification 2.0 subscribeSubscriptionproposed : Subscription 2.1 checkSubscription 2.2 receiveNotification 2.3 3.0 receiveNotification 3.1 performFilterfilter, message 3.2 [notification matches filter]:receiveNotification Figure 16: Subscription Timing The interactions shown in Figure 16 are explained in Table 28. Table 28: Discussion of Subscription Timing Interactions Messages Notes Msg: 1.0 From: Producer To: Broker An Event Source sends a notification to the Producer. This will be matched against the currently existing subscriptions at the Broker not shown in the diagram. Msg: 2.0 From: Subscriber To: Broker A subscription is proposed to the Producer. Msg: 2.1 From: Broker To: Broker The Producer checks the subscription to determine if it can be accepted. This can include validity checks or check of given and supported filter statements, for example. Msg: 2.2 From: Producer To: Broker The Event Source sends another notification to the Producer. The notification is not matched against the subscription yet. Msg: 2.3 From: Broker The subscriber is informed about the outcome of the subscription. In the following, it is assumed that the subscription was accepted. 44 Copyright © 2010 Open Geospatial Consortium, Inc. To: Subscriber Msg: 3.0 From: Producer To: Broker The Event Source sends a notification to the Producer. Msg: 3.1 From: Broker To: Broker The message is matched against the subscriptions filter criteria. Note: this is done for each message in the notification. Msg: 3.2 From: Broker To: Client: Consumer If the message matches the filter criteria then it is sent as a notification to the subscriptions consumers.

6.2.2.3 Handling a Pausable Subscription

A publish subscribe service may support pausable subscriptions. In doing so, it allows clients to pause a subscription while it is not needed. This can save valuable resources both for a producer and a consumer. The following figure shows the state machine of a PausableSubscription. Existent Activ e Paused terminate [termination time before now] renew [isPaused = true] [isPaused = false] resume pause pause resume Figure 17: Pausable Subscription State Machine Copyright © 2010 Open Geospatial Consortium, Inc. 45

6.2.2.4 Sending a Notification

One of the most important activities in a publish subscribe system is to actually send notifications. Figure 18 shows the activity of publishing an event. A Notify event message is emitted and sent to some not further specified system entity. Publish Notify Figure 18: Publishing Activity The activity relies upon the interface defined in section 6.2.1.4.11.

6.2.2.5 Handling a Notification at a Broker

A broker is capable of receiving incoming notifications and matching them against existing subscriptions. Each notification matching a subscription’s filter criteria needs to be published to endpoint defined for that subscription. The following diagram shows the activities and events involved in handling an incoming notification at a broker. The activities of the publisher and broker run in parallel.