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