Detailed protocol Engineering Reports | OGC

22 Figure 5 - Notification

7.1 Detailed protocol

Inserting the DMS may require some changes in the roles within the OGC Web Services architecture. It is understood, however, that the changes in the client and web services functionalities shall be kept to a minimum. The approach we propose is to make the DMS available as a web service, and add a module at the client side in order to be able to use the services provided by the DMS. OGC web services standards support different binding possibilities, including SOAP + HTTP, HTTP POST + plain XML, and KVP. At this stage, using SOAP + HTTP at the Client DMS Dispatcher 1 : NotifyNotification 2 : validateNotification 3 : filterNotification 4 : prioritizeNotification 5 : provenanceNotification 6 : CDMSNotifyNotification 7 : createDispatchMessage 8 : CDispatchNotifyNotification 23 Client-DMS side seems to be advantageous as it provides the flexibility of adding new metadata for the DMS functions, namely within the SOAP header, and also permits the use of WS- standards, especially WS-ReliableMessaging which addresses one of the DMS requirements. The detailed Client-DMS communication mechanisms are outlined in the following, for request-response and publish-subscribe exchange patterns respectively. ฀ Request-response model here we assume that HTTP+XML binding is provided by the OWS: o The Client forms an XML request addressed to the OWS.. o The Client then calls the service provided by the DMS, giving the OWS URL and the request as arguments. Since SOAP binding is provided by DMS on the Client side, these arguments will constitute the SOAP body of the SOAP envelope sent by the Client to DMS. o Upon receipt of the request, the DMS web service obtains the XML request and forms a new request towards the provided OWS URL. It then waits for the response from the OWS. o DMS performs validation, filtering, and prioritization to the response it receives from the OWS. o The DMS then forms a response to the Client’s request, including the OWS response in the SOAP body. o The process is completed when the Client finished reading response message. ฀ Publish-subscribe model: o The Client forms a SOAP message for subscription request addressed to the ES. The request will contain ConsumerReference field to indicate the client EPR.. o The Client then encapsulates the original request into another SOAP envelope, with the original ES URL and the complete SOAP request included in the SOAP body. o Upon receipt of the request, the DMS web service reads the message and forms a new request towards the ES, replacing the ConsumerReference in the original request with a new EPR, formed by of DMS EPR and client identifier. The DMS shall also read specific parameters of the request, e.g. update interval information, for the purpose of performing validation to the notifications. It then waits for the response from the ES. 24 o DMS then forms a response to the Client’s request, including the ES subscription response in the SOAP body. o The process is completed when the Client finished reading the response message. o Notifications from the ES will contain the client ID in the wsa:To field, as it corresponds to the ConsumerReference field sent by the DMS during subscription request. Every time DMS receives a notification, it shall obtain the ID and use it to route the notification message to the proper client, after performing validation, filtering, and prioritization to the notification. The validation, filtering, and prioritization steps will be implemented in a modular way after the first baseline implementation of the DMS, which includes only the forwarding of requests, responses, and notifications between client and the ground web services.

7.2 Required extensions to OGC Web Services Architecture