onvif两种notify方式解读-------Basic Notification

Basic Notification  interface 

以下逻辑实体参与此通知模式：

Client-------实现 consumer通知接口

Event service-------实现 producer通知接口

Subscription manager-------实现 subscribemanager接口

Event service 以及 Subscription Mananger应该在device中实例化。

典型的Client与Device之间的信息交互如下图所示：

    1.Client与Event service建立连接， Client通过发送SubscriptionRequest去订阅确定的通知，如果Event Service接受订阅，将动态实例化一个SubscriptionManager去代表这个订阅。Event Service一定会在SubscriptionResponse中去返回SubscriptionManager的WS-Endpoint-Address.

    2.为了去传输与订阅相匹配的通知消息，Event Service 与Client之间会 另外创建一个链接。通过此链接， Event Service 向Client的NotificationConsumer接口发送单向的Notify消息。只要此订阅还在其生存周期中，Event Service 可以在任意时间发送通知。

    3.为了去控制订阅，client可以通过SubscriptionResponse中返回的SubscriptionManager的地址直接相连(即client直连SubscriptionManager)。在SubscriptionRequest中，Client可以指定subscribe的销毁时间。当销毁时间到的时候对应的manager会自动销毁。Client可以通过发起RenewRequest去延长manager的生存周期。当然Client可以通过发起Unsubscription去主动解除订阅.当成功解除订阅后，对应的manager就不存在。而Manager与Eentservice的关系不再由[WS-BaseNotification]决定而是由device的实现决定。

    如下图：

    

    接下来详细介绍[WS-baseNotifiation]所提供的接口：

         1.Notificationproducer()接口----NotificationProducer的资源属性是可选项。(9.5)

        2.使用dialects支持TopicExpression filters

        3.GetEventproperties()接口中有MessageContent filters

        如果设备不接受subscription的InitialTerminationTime，则Fault信息中应该提供合法的InitialTerminationTime。device必须能够使用notify去发送消息。支持onvif的设备必须在RenewResponse以及Subscriberesponse中去提供Currenttime以及terminationtime。如果GetCurrentMessageRequest中没有可用的currenttime则device会报错。

        可选去实现 pull-point接口

        必须实现Base Subscription Manager的接口有  Renew,Unsubscribe  pausable subscription manager可选 subscription可选

        必须在request以及response中实现时间，并用Z标识

消息通知结构：

        采用----wsnt:NotificationMessage的消息模式，其XML格式如下

        在wsnt：Message中包含了信息， XML类型的消息元素由topictree所指定。

1.概述客户端通过搜索得到的信息

    一个通知至少回答何时谁发生了什么事件这些问题。在通知消息(NotificationMessage)中添加时间元属性去回答何时发生。

    对于谁产生了时间的谁的问题分为两个部分。一部分是Endpoint标识，此标识表示通知由谁产生。所以 WS_endpint应该用ProducerRef指定(其代表Device或者Service).因此 WS-Endpoint应该由带有ProducerReference元素的NotificationMessage来指定。第二部分是WS-EndPoint的组件,负责产生通知。（即一部分标识通知由谁产生，一部分负责通知产生）。根据组件可能需要多个或不用参数去标识此独一无二的组件。这些参数被作为Source元素的Items放在通知容器中。

    对于发生了什么事件的问题应该分两步。

        1：topic元素用于分类Event

        2.添加到事件容器的Data数据块的items用于详细的描述事件

（topic用于分类事件，而Data用于详细的描述事件）

    在topic属性中，client使用NotificationProducer的Topic，SourceItems以及可选的keyItems去识别所有者。这些属性会产生独一无二的标识。下面用一个实例来解释这些参数：

    Item PTZConfigurationToken代表detecton Event 的组件，在本例中其是由PTZ配置为PTZConfig1的一个PTZ节点引用。事件tns1:PTZController/PTZPreset/Reached表示的是PTZ单元已经到达预了preset对应的条件，并在Data部分包含了此PTZ单元的预设信息。因此，preset可以被名为“PresetName”的presetToken“Preset5”来标识。

    此名为presetName的preset可被Preset5识别。

2.通知信息的详细格式（Onvif Schema）

    Message元素被分为3部分：SOurce，Data,Key。Key组（不能使用与Notification无关的属性）。 在每一个组中可以放置多个Simple and Element Items.每一个Item都有name 和value。对于一个ElementItem,它的value是一个带有ElementItem的XML元素来表述。对于一个SimpleItem,其value必须是被value属性所制定的value。所有items应该在包含它的组中是独一无二的。

供应商指定的扩展必须以Qname的形式表述SimpleItem 以及ElementItem Name以及attribute.这使得在以后的onvif扩展以及厂商指定的扩展的潜在的命名冲突得以避免。

推荐使用SimpleItems而不是ElementItems，因为SimpleItems可轻松地集成为通用客户端的消息。 不论Simple或者ElementItems的类型信息均可以从TopicSet中提取，并且每个主题可以增加一个有效负载地描述。

PropertyOperation应该在出现在关联property的通知中。操作模式的初始化用于client中有关属性地创建。即模式的初始化应该在有同步请求时应用。

Property example, continued

在下面的例子中需要一个可选的Key Item。本例子用于解释应用中的Key Item。rule engine中应该包含FiledDetector 规则。这些规则定义了场景中每个对象的属性。当一个新建的对象出现在Filed外，则产生下面所示的通知消息。

Source Item描述产生此通知的规则。当在场景中有多个对象的时候，每个对象有它自己的对象属性。 Object ID被视为一个额外的Key item 以便可以独一无二的标识这个属性。Isinside Items使用一个布尔值去判断对象是在指定场景的内部还是外部。

当对象进入了指定的场景，rule就产生了一个与下面消息相似的“property changed”消息

最终当对象离开指定的场景的时候，一个“property delete”消息产生。

在这种情况下，对象的数据项可以忽略因为对象已经不存在了

3.通知信息的消息描述

消息体的结构如前所述，消息体包括，Source，Key,Data三部分。每一部分包含一连串的Simple Item以及ElementItems。 对每个topic，设备可以根据描述语言描述的topic去规定哪个itme可以成为消息体的一部分进而生成通知消息。下面是关于强制邮件的描述语言。

    同一个组的不同Item的name 属性必须是独一无二的。isproterty属性在描述消息与property相关的时候必须为true.如果消息与prperty无关则不能出现key组。 SimpleItemDescriptor的type属性必须用XML，onvif，设备提供商的数据形式进行定义。ElementItemDescriptor的type属性必须匹配XML格式声明的全局元素声明中的一个。

消息描述语言并不强制定义每一类资源的item的顺序。另外onvif规范中的option的item在消息中可不出现。对于与消息描述相关的option的item也适用。

描述消息体的文件架构一般位于GetEventPropertiesResponse的消息体中。

下面的例子是以上例子的消息描述

4.定义过滤器语法

5.Get Event Properties

WS-BaseNotification 规范定义了许多可选的WS-ResourceProperties。此规范不需要实现WS-ResourceProperty接口。然而，订阅的直接接口必须由支持onvif的设备实现以便提供所支持的FilterDialects，文件格式以及topics。

支持onvif的设备必须声明其Topic是否是固定，以及提供何种topics,支持何种Dialects。

     下述的TopicExpressionDialects是onvif强制要求的

如果设备不支持任何的消息过滤，则需要返回一个空的URL

     规范不要求设备支持任何producerpropertiesdialects

消息包含描述语言，允许参考设备供应商的指定类型。为了简化整合类型到各个client应用中，GetEventPropertiesResponse必须在schema文件中列出其用于描述通知的所有URI，以及MessageContentSchemaLocation元素。这个列表至少包含onvif必要文件的URI.

9.7topic

所有主题描述类型依据9.73所述。

All topics grown from the ONVIF Topic Namespace describes the type of a topic

according to section 9.7.3

ws-Topic规范定义了主题树的归属以及某些web服务所支持的主题