Copyright © 2010 Open Geospatial Consortium, Inc.
63
Figure 29: Event Service Requirements Packages
The packages were structured and colored according to their importance. Also, separation of functionality was aimed for.
The packages colored in read define the requirements that are essential for a publish subscribe application:
The
Resource
package defines the basic structure of resources, for example that a resource is identifiable and may have labels. In addition, resources with lifetime
are defined. They can be terminated at a given time. Behavior to access resources and control their termination time is also defined.
The
Consumer
package defines the structure of notifications as well as the behavior of system entities that receive them. The package supports the Consumer
interface defined in OGC 09-032 section 6.6.2.1. It is defined separately to allow the inclusion in service roles that need Consumer functionality but not
subscriptions e.g. a Router as defined in OGC 09-032 section 6.6.1.5.
The
Publish Subscribe
package defines structure of subscriptions and event channels, among others. In addition, behavior of a Provider, Publisher, Producer
and subscriptions are defined. For a more detailed description of the according
64
Copyright © 2010 Open Geospatial Consortium, Inc.
interfaces and roles, see OGC 09-032 section 6.6. This package, together with the Resource and Consumer package, represents the core functionality of an Event
Service.
The requirements packages that define functionality to enable notification brokering are colored in green:
The
Registrar
package defines the structures and behavior to enable the registration of new publishers that send events notifications to a Consumer. The
package supports the Registrar interface defined in OGC 09-032 section 6.6.2.2. It is defined separately to allow the inclusion in service roles that need Registrar
functionality but not subscriptions e.g. a RegisteringRouter as defined in OGC 09-032 section 6.6.3.2.
The
Brokered Publish Subscribe
package defines an extension of the functionality provided in the Publish Subscribe package. Behavior is defined that enables the
implementation of a standalone Event Service that acts both as an event Consumer and Provider
– see OGC 09-032 section 6.6.1.5. This setting was implemented in both OWS-6 and OWS-7.
The
Registering Broker
package defines the requirements of a broker where new publishers have to be registered before they can send events to it. The according
service role is described in OGC 09-032 section 6.6.3.3. The yellow requirements packages define enhanced publish subscribe functionality:
The
Pausable Provider
package defines the structure of a pausable subscription and the behavior that needs to be supported for it.
The
Demand Based Publication
package defines the requirements needed to support the mechanism described in more detail in section 6.2.2.7 of this report.
Finally, the requirements packages colored in blue define advanced event channel functionality:
The
Aggregation Channel
package defines the structure and behavior needed to support aggregating event channels see section 6.3.
The
Ad Hoc Channel
package defines the structure and behavior needed to support ad hoc event channels see section 6.3.
The details of the requirements contained in each package are provided in
Annex A - Publish Subscribe Requirements
.
Copyright © 2010 Open Geospatial Consortium, Inc.
65
6.5 Realization of Publish Subscribe
6.5.1 Introduction
This chapter documents how well a given publish subscribe technology fulfills the requirements derived from the abstract publish subscribe model
– see section 6.4.
6.5.2 Realization with WS-Notification
In October 2006 OASIS published WS-Notification
2
as an official standard. It is composed of three specifications: WS-BaseNotification, WS-BrokeredNotification and
WS-Topics. The standard is for example used by the Sensor Event Service OGC Discussion Paper 08-133 as the underlying technology to enable publish subscribe. The
standard is primarily used in the SOAP binding but could be used in the Plain-old-XML POX binding as well, provided that a WS-Addressing binding for POX is defined.
The OWS-6 SWE Event Architecture ER OGC 09-032 provides an Annex with a tutorial on how to use this technology. Section 6.5.2.2 complements that tutorial with
additional information regarding the Notify message.
The following section discusses how well WS-Notification can realized the publish subscribe requirements.
6.5.2.1 Requirements Mapping for WS-Notification
This section summarizes the results of the publish subscribe requirements mapping study performed for WS-Notification. The detailed technical documentation of the
requirements realization with WS-Notification is omitted here to avoid unnecessary distraction of the reader. It can be found in chapter 14
Annex B
–
Publish Subscribe Requirements Realization Tables
, Table 53. The following observations were made:
The average realization grade is 2.15 on a scale from 1 [perfect] to 4 [no go], which indicates that WS-Notification in general at least partly already realizes the
required functionality and that missing functionality can be added. There is no requirement with realization grade 4 which would mean that the
requirement cannot be realized with WS-Notification as underlying technology. This shows that the WS-Notification standard is an option to implement publish
subscribe in OGC SOAP web service bindings.
2
http:www.oasis-open.orgcommitteestc_home.php?wg_abbrev=wsn
66
Copyright © 2010 Open Geospatial Consortium, Inc.
6.5.2.2 Considerations on the Notify Message sent via HTTP
The Notify operation is used to send notifications to consumers. Usually, no response is expected from the consumer upon receipt of this message. However if HTTP is used as
underlying protocol each SOAP request sent via HTTP automatically has an HTTP response. The Web Services Interoperability Organization has some recommendations for
SOAP-via-HTTP communication
3
. Especially section 3.8.3 on status codes is interesting as it defines the success status codes for HTTP responses.
As the HTTP specification [1] defines that a 200 OK response shall contain a message body while 202 Accepted should contain a message body and is intended to signal the
acceptance of a process we recommend using 204 No Content as response code – this
status code requires that no content is provided in the response body. This fulfills the semantics of the Notify response best and is within the recommendation of WS-I which
states that “An INSTANCE MUST use a 2xx HTTP status code on a respo
nse message
that indicates the successful outcome of a HTTP request.” It also does not conflict with the HTTP defined semantics of the status codes. The response should not contain a body
payload.
Consequently, every publisher should be implemented to accept all 2xx codes as notify response.
NOTE: Usage of WS-ReliableMessaging results in at least some content communicated back to the entity that sent the notification in a reliable way.
6.5.3 Summary
Chapter 6.5 documents how well a given publish subscribe technology supports the requirements derived from the abstract model. During the testbed, the participants were
able to establish the mapping for one realization technology, namely WS-Notification –
the results are documented in section 6.5.2.1. WS-Notification was already used in OWS- 6 and was in OWS-7 also applied in the Aviation and SFE threads.
Other technologies, like Atom AtomPub, WS-Eventing etc. can and should in the future also be investigated in this way. The foundation for that work is laid in this report.
When more technology mappings for the requirements have been achieved, a meaningful comparison of the different technologies can be made. That study will point out which
technology is most appropriate for realizing publish subscribe functionality required by OGC services per given OWS binding style SOAP, RESTful etc.
3
http:www.ws-i.orgProfilesBasicProfile-2_028WGD29.htmlSOAPHTTP
