Copyright © 2011 Open Geospatial Consortium.
79
17 Communication Patterns
17.1 Asynchronous RequestResponse
Traditional client-server communication typically involves an exchange of request and response messages. The response can be transmitted synchronously or asynchronously.
OGC 09-032 clause 8.2 explains this in further detail and documents potential realizations of asynchronous responses in different bindings.
17.2 PublishSubscribe
17.2.1 Introduction
In OGC, one of the less prominent messaging patterns is the PublishSubscribe pattern. However, it has great value for use cases in which notification of events need to be sent
to interested consumers as soon as possible and the frequency with which these events occur is unknown. The pattern is described in more detail in OGC 09-032 clause 8.1.3.
One important aspect of the pattern is the subscription model. According to OGC 09-032, a subscription model characterizes how the producer matches notifications against
subscriptions. Various models exist. While this standard does not restrict the set of allowed models, it defines requirements for the usage of the Channel and Filter
subscription models see OGC 09-032 clauses 8.1.3.1.1 and 8.1.3.1.3 for further details on these two models. Channel based subscription is also called Topic based subscription.
PublishSubscribe implementations can combine various subscription models per binding. This allows clients for example to use both channel and filter criteria in one
subscription.
Requirement http:www.opengis.netspecSWES2.0reqCommunicationPubSub
REQ 62. Specifications making use of this SWES publishsubscribe
standard shall define all functionality to enable publish- subscribe on a per-binding base.
NOTE The realization in the SOAP binding is documented in clause 19.
17.2.2 Events and their encoding
The events recognized by this standard and their encoding are defined in Table 35. A SWE service that implements publishsubscribe functionality is free to publish each type
of event.
80
Copyright © 2011 Open Geospatial Consortium.
Requirement http:www.opengis.netspecSWES2.0reqCommunicationPubSubEventEncoding
REQ 63. SWES events published by a service shall be encoded as defined
in Table 35.
Table 35 — SWES Events and their encoding Event name
a
Event definition
Encoding of the event Use at SWE
service that implements
PublishSubs cribe
CapabilitiesChan ged
see Table 15 in the
according row
SWESEvent see clause 8.2.4 code value shall be
“CapabilitiesChanged” optional
OfferingAdded OfferingChanged see
clause 8.2.6
code value shall be “OfferingAdded” optional
OfferingDeleted OfferingChanged see
clause 8.2.6
code value shall be “OfferingDeleted”
optional
SensorInserted SensorChanged see
clause 8.2.7
code value shall be “SensorInserted” optional
SensorDescriptio nUpdated
SensorDescriptionUpdated see clause 8.2.8
code value shall be “
SensorDescriptionUpdated
” optional
a Although some values listed in the column appear to contain spaces, they shall not contain spaces. NOTE The insertion of a sensor causes the addition of an offering and thus also of a change to the
Capabilities. As such, depending upon which of the events defined in the table a service actually recognizes and publishes, up to three notifications may be triggered when a sensor was inserted. The
number of triggered notifications can get even higher if a sensor insertion causes events defined by other standards.
Copyright © 2011 Open Geospatial Consortium.
81
17.2.3 Content based filtering of notifications
Kategori