Interfaces of WS-Base Notification Specification

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 160 of 233 Criteria OASIS WS- Notification OGC Sensor Alert Service Publish interaction Yes No Subscribe-Publish interaction Yes Yes Register-Publish interaction Advertise-Publish Yes Yes Brokered interaction Yes Yes Transport SOAP XMPP HTTP Hierarchical organisation of event types Yes No Event Filtering Based on topic type only Yes complex based on notification content eg. spatial Provides description of the notification payload Not by the means of the specification Yes Information model and schema for the payload No Yes Table 8-15: Comparison between OASIS WS-Notification and the OGC Sensor Alert Service

8.5.1 Interfaces of WS-Base Notification Specification

Name WS-BaseNotification Standard Specifications OASIS Web Services Base Notification 1.3 WS-BaseNotification Committee Specification, 31 July 2006. http:docs.oasis- open.orgwsnwsn-ws_base_notification-1.3-spec-cs-01.pdf Description OASIS describes the WS-BaseNotification as follows: “The WS-Notification family of specifications defines a standard Web services approach to notification. The WS-BaseNotification specification is the base specification on which all the other specifications in the family depend. It defines the normative Web services interfaces for two of the important roles in the notification pattern, namely the NotificationProducer and NotificationConsumer roles. This specification includes standard message exchanges to be implemented by service providers that wish to act in these roles, along with operational requirements expected of them. In the Notification pattern a Web service, or other entity, disseminates information to a set of other Web services, without having to have prior knowledge of these other Web services. This specification defines a role called the NotificationProducer. A NotificationProducer is capable of producing a set of Notification messages. A NotificationProducer accepts incoming Subscribe requests. Each Subscribe request contains a reference to a NotificationConsumer SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 161 of 233 and identifies the subset of the Notifications the NotificationProducer should produce. This subset can be described by identifying one or more boolean filters, including filtering by Topic, as described in [WS- Topics]. The NotificationProducer agrees to produce Notification Messages as requested in the Subscribe request, or returns a fault if the subscription cannot be handled. In addition to the message exchanges described in this specification, a NotificationProducer may also support the required message exchanges defined in the [WS-ResourceProperties] specification and may support the optional message exchanges defined in the WS-ResourceProperties specification. In such a case, this specification defines several resource properties which MUST conform to the schema defined in the WS- BaseNotification specification.” Interfaces of the WS-BaseNotification specification: NotificationConsumer: Enables reception of notifications produced by a NotificationProducer as a result of a subscription. NotificationProducer: Enables production of notifications to those NotificationConsumers that have subscribed based on occurring events and on the supplied parameters during subscription. PullPoint: Supports destruction of PullPoint resources and retrieval of notifications from a PullPoint resource. CreatePullPoint: Manages creation of PullPoint resources. SubscriptionManager: Manages renewal and cancelation of Notification subscriptions. PausableSubscriptionManager: Enables pausing and resuming production of notifications for a given subscription. Interface NotificationConsumer Notify This action is implemented by the consumer and invoked by the producer produces Notification message when publishing Notifications. Interface NotificationProducer Subscribe Used by the notification subscriber to register its interest to receive a subset of the notifications that the producer can publish. GetCurrentMessage Upon invocation of this operation the NotificationProducer returns the last published Notification on a given topic. Interface PullPoint GetMessages The PullPoint interface supports the NotificationConsumer interface in order to allow accumulation of Notifications by enabling the NotificationProducer to send notifications to the PullPoint. The GetMessages operation enables the requestors to retrieve or pull Notification Messages from the PullPoint. DestroyPullPoint Invoked by a requestor in order to destroy an existing PullPoint. Interface CreatePullPoint SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 162 of 233 CreatePullPoint This operation is invoked by a requestor on an endpoint supporting the PullPoint interface in order to create a new PullPoint resource. Interface SubscriptionManager Renew The Renew operation is used to modify lifetime of an existing Subscription. Unsubscribe This operation is invoked by a requestor in order to terminate an existing Subscription. Interface PausableSubscriptionManager PauseSubscription This operation is invoked in order to temporarily pause the production of notifications for a given Subscription. ResumeSubscription This operation is the counterpart of the PauseSubscription operation being issued in order to resume the production of notifications for a given Subscription. Example Usage Event based automatic catalogue harvesting can be realised by implementing the NotificationProducer and NotificationConsumer interfaces. Given the dynamic aspects of an existing sensor network, the Catalogue responsible for the discovery of resources must be able to react to changes in the sensor network e.g. new sensor connected to the network. This can be realised by a service of the sensor network implementing the NotificationProducer interface and providing subscriptions to notifications concerning new sensors. Following the Catalogue has to implement the NotificationConsumer interface and subscribe to these notifications. Based on the received Notifications the catalogue service can start harvesting for information concerning the sensor network and updating its contents. Comments It is beyond the scope of this specification to describe an information model for or taxonomy for events. It relies on the WS-Topics specification that enables the definition of eventnotification types and categories that a consumer can subscribe to. Notification producer might support the message patterns defined by the WS-ResourceProprieties specification. Table 8-16: Description of WS-BaseNotification Service 8.5.2 Interfaces of WS-Brokered Notification Specification Name WS-BrokeredNotification Standard Specifications Web Services Brokered Notification 1.3 WS-BrokeredNotification OASIS Standard, 1 October 2006. http:docs.oasis-open.orgwsnwsn- ws_brokered_notification-1.3-spec-os.pdf Description OASIS describes the WS-BrokeredNotification as follows: “The Event-driven, or Notification-based, interaction pattern is a commonly used pattern for inter-object communications. Examples exist in many domains, for example, in publishsubscribe systems or in system and device management domains. Message brokers are involved in many of these systems, such as the ones provided by Message Oriented Middleware vendors. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 163 of 233 This specification defines the Web services interface for the NotificationBroker. A NotificationBroker is an intermediary between message Publishers and message Subscribers. A NotificationBroker decouples NotificationProducers and Notification Consumers and can provide advanced messaging features such as demand-based publishing and load-balancing. A NotificationBroker also allows publication of messages from entities that are not themselves service providers. This is very similar to a traditional Message Oriented Middleware model. The NotificationBroker interface includes standard message exchanges to be implemented by NotificationBroker service providers along with operational requirements expected of service providers and requestors that participate in brokered notifications. In addition to the message exchanges described in this specification, a NotificationBroker my also support the required message exchanges defined in the WS-ResourceProperties specification and may support the optional message exchanges defined in the WS-ResourceProperties specification.” Interfaces of the WS-BrokeredNotification specification: NotificationBroker: Enables the implementing service to act as a middleware between Publishers and Subscribers of Notifications. A service implementing this interface must implement the following interfaces from the WS-BaseNotification specification: NotificaitonConsumer, NotificationProducer. It may also implement the CreatePullPoint interface. In addition the following interfaces must be implemented. RegisterPublisher: Handles the publisher registration. PublisherRegistrationManager: Handles the termination of a Publisher registration unregistration. Interface RegisterPublisher RegisterPublisher This action is implemented by the broker in order to allow for to Publishers to advertise on their ability to publish Notifications on a set of Topics. Interface PublisherRegistrationManager DestroyRegistration Used to destroy the PublisherRegistration resource thus effectively terminating the publishing of Topics from a Publisher. Additionally the PublisherRegistrationManager may also support the required message exchanges defined in the WS-ResourceProperties specification. Example Usage A NotificationProducer registers with a Broker and by doing so the Broker exposes the Topics that the Publisher is able to provide. Upon successful registration a NotificationConsumer can subscribes to the Broker to receive notifications on a given Topic. The Broker mediates this subscription by subscribing for Notifications at the NotificationProducer and forwarding the received Notifications to the NotificationConsumer. Comments Table 8-17: Description of WS-BrokeredNotification Service SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 164 of 233

9. Technology Viewpoint

The Technology Viewpoint of the SensorSA specifies the technological choices of the concrete service platform and its operational issues. To accommodate the requirements of Sensor Networks as introduced in section 4.5 the SensorSA refines the guidelines and requirements for platform specifications as defined in the Technology Viewpoint of the ORCHESTRA Reference Model RM-OA, 2007. These guidelines comprise: - a general approach for how to specify a service platform see section 9.1, - the specification of the SANY service platform - a description of how access control mechanisms are being implemented section 9.3.1, - an agreement on data formats see section 9.3.2, and - optionally a set of restrictions to be observed for a particular platform.

9.1. Properties of a Service Platform

As a general guideline, the specification of a service platform shall be conformant to the OASIS Reference Model for Service Oriented Architecture 1.0 SOA-RM, 2006. This implies that the platform is being described according to the SOA-RM by the following predefined platform properties: - Platform Name Name of the platform and if applicable the exact version number of the platform specification. In the case of a standard platform, a reference shall be provided. - Reference Model If the platform specification is based on a specific reference model, the name and the exact version number of the reference model shall be provided. - Interface Language Specification of the formal machine-processable language used to define SOA-RM Service Interfaces. In the case of a standard language, a reference shall be provided. - Execution Context Specification of the SOA-RM Execution Context. The Execution context is an agreement between service providers and consumers. It contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used. This includes, for example, the specification of the transport and the security layer, the format of the messages exchanged between service providers and consumers, etc. In the case of a standard SOA-RM Execution Context, a reference shall be provided.