Requirements Mapping for WS-Notification

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 Copyright © 2010 Open Geospatial Consortium, Inc. 67 7 Event Discovery

7.1 Introduction

An initial model for Event Service Discovery is presented in this chapter. A CSW-ebRIM registry extension package is developed to correspond with the Event Service Discovery model. Example Services are provided along with queries to demonstrate the discovery process. An online registry service is available to test the queries.

7.2 Event Metadata Example

The classes in the Event Metadata package described in section 6.2.1.3 were implemented in XML Schema to support testing of the event discovery functionality in OWS-7. The schema is provided in chapter 16, Annex D – Event Metadata . Event metadata was created for two exemplary services, one from the Sensor Web and one from the Aviation domain. The metadata describes the event types that are published by the services on given event channels in certain encodings. Figure 30 and Figure 31 show the event metadata that was exemplarily created for OWS-7 in UML object diagram notation. Figure 30: Example of Event Metadata for Aviation Service – UML Object Diagram Notation