Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 1 | /* |
Brian O'Connor | a09fe5b | 2017-08-03 21:12:30 -0700 | [diff] [blame] | 2 | * Copyright 2016-present Open Networking Foundation |
Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 3 | * |
| 4 | * Licensed under the Apache License, Version 2.0 (the "License"); |
| 5 | * you may not use this file except in compliance with the License. |
| 6 | * You may obtain a copy of the License at |
| 7 | * |
| 8 | * http://www.apache.org/licenses/LICENSE-2.0 |
| 9 | * |
| 10 | * Unless required by applicable law or agreed to in writing, software |
| 11 | * distributed under the License is distributed on an "AS IS" BASIS, |
| 12 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 13 | * See the License for the specific language governing permissions and |
| 14 | * limitations under the License. |
| 15 | */ |
| 16 | |
| 17 | package org.onosproject.yms.ynh; |
| 18 | |
VinodKumarS-Huawei | af9c7a7 | 2016-08-30 19:43:39 +0530 | [diff] [blame] | 19 | import org.onosproject.event.ListenerService; |
| 20 | |
Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 21 | /** |
| 22 | * Abstraction of an entity which provides interfaces to YANG notification |
VinodKumarS-Huawei | af9c7a7 | 2016-08-30 19:43:39 +0530 | [diff] [blame] | 23 | * service. YANG notification handler receives the event notifications from |
| 24 | * application/core and provide it to the protocols. |
| 25 | * |
Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 26 | * NBI Protocols which can support notification delivery for application(s) |
| 27 | * needs to add themselves as a listeners with YANG notification service. |
VinodKumarS-Huawei | af9c7a7 | 2016-08-30 19:43:39 +0530 | [diff] [blame] | 28 | * Also based on registered schema YMS add themselves as a listener to |
| 29 | * applications. Application sends their notification in YANG utils generated |
| 30 | * notification. YMS obtains the module/sub-module schema tree in which this |
| 31 | * notification is contained and then convert this data to an abstract tree |
| 32 | * notation (YDT) with root node as the module/sub-module node in which |
| 33 | * notification is contained. It sends the same to all the protocol who has |
| 34 | * added them as a listener as a YANG notification. |
| 35 | * |
| 36 | * Also Protocols can use YANG notification service to check if a received |
Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 37 | * notification should be filtered against any of their protocol specific |
| 38 | * filtering mechanism. |
| 39 | */ |
VinodKumarS-Huawei | af9c7a7 | 2016-08-30 19:43:39 +0530 | [diff] [blame] | 40 | public interface YangNotificationService |
| 41 | extends ListenerService<YangNotificationEvent, |
| 42 | YangNotificationListener> { |
| 43 | |
| 44 | /* |
| 45 | * Example of a use case of notification filtering. |
| 46 | * The following example illustrates how to select fault events which |
| 47 | * have severities of critical, major, or minor. The filtering criteria |
| 48 | * evaluation is as follows: |
| 49 | * |
| 50 | * ((fault & severity=critical) | (fault & severity=major) | (fault & |
| 51 | * severity=minor)) |
| 52 | * |
| 53 | * <netconf:rpc netconf:message-id="101" |
| 54 | * xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> |
| 55 | * <create-subscription |
| 56 | * xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> |
| 57 | * <filter netconf:type="subtree"> |
| 58 | * <event xmlns="http://example.com/event/1.0"> |
| 59 | * <eventClass>fault</eventClass> |
| 60 | * <severity>critical</severity> |
| 61 | * </event> |
| 62 | * <event xmlns="http://example.com/event/1.0"> |
| 63 | * <eventClass>fault</eventClass> |
| 64 | * <severity>major</severity> |
| 65 | * </event> |
| 66 | * <event xmlns="http://example.com/event/1.0"> |
| 67 | * <eventClass>fault</eventClass> |
| 68 | * <severity>minor</severity> |
| 69 | * </event> |
| 70 | * </filter> |
| 71 | * </create-subscription> |
| 72 | * </netconf:rpc> |
| 73 | */ |
| 74 | |
| 75 | /** |
| 76 | * Protocols have their own mechanism to support notification filtering |
| 77 | * or notification subscription. Depending on the protocol specification, |
| 78 | * the filtering is implemented in the protocol. |
| 79 | * The Protocol implementations are abstracted of the Schema, there are |
| 80 | * scenarios in which they need to check if the received notification |
| 81 | * is of interest as per the schema filtering / subscription. |
| 82 | * In such scenario, protocols can create a filtering / subscription YANG |
| 83 | * data tree and use the notification service to filter the notification |
| 84 | * subject against their filter. |
| 85 | * |
| 86 | * Filters the notification subject YANG data tree, with the specified |
| 87 | * filter of the NBI protocol. If the filter does not match for the |
| 88 | * passed notification subject, null will be returned. |
| 89 | * Otherwise, the part of the subject matching the filter will be returned. |
| 90 | * |
| 91 | * @param notificationSubject YANG notification subject reported by YANG |
| 92 | * notification service. |
| 93 | * @param notificationFilter Protocols data model specific notification |
| 94 | * filter represented in YANG data tree. |
| 95 | * @return filtered notification which passes the data model specific |
| 96 | * notification filter. |
| 97 | */ |
| 98 | YangNotification getFilteredSubject(YangNotification notificationSubject, |
| 99 | YangNotification notificationFilter); |
| 100 | |
Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 101 | } |