Gaurav Agrawal | b102b01 | 2016-08-02 12:52:48 +0530 | [diff] [blame] | 1 | /* |
| 2 | * Copyright 2016-present Open Networking Laboratory |
| 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.ymsm; |
| 18 | |
| 19 | import java.util.List; |
| 20 | |
| 21 | import org.onosproject.yms.ych.YangCodecHandler; |
| 22 | import org.onosproject.yms.ydt.YdtBuilder; |
| 23 | import org.onosproject.yms.ydt.YdtResponse; |
| 24 | import org.onosproject.yms.ydt.YdtWalker; |
| 25 | import org.onosproject.yms.ynh.YangNotificationService; |
| 26 | |
| 27 | /** |
| 28 | * Abstraction of an entity which provides interfaces to YANG management |
| 29 | * system. YMS is a core of YANG in ONOS. |
| 30 | * |
| 31 | * In NBI, it acts as a broker in between the protocol and application, |
| 32 | * here there is a separate protocol implementation, which does the conversion |
| 33 | * of protocol representation to abstract data tree. The protocol |
| 34 | * implementation takes care of the protocol specific actions for |
| 35 | * e.g. RESTCONF handling the entity-tag / timestamp related operations. |
| 36 | * |
| 37 | * In SBI, driver or provider uses YANG codec handler as a utility to translate |
| 38 | * the request information in java(YANG utils generated) to protocol specific |
| 39 | * format and vice versa. |
| 40 | */ |
| 41 | public interface YmsService { |
| 42 | |
| 43 | /** |
| 44 | * Returns YANG data tree builder. |
| 45 | * |
| 46 | * NBI protocol implementation takes care of the protocol specific |
| 47 | * operations. They are abstracted from the intricacies of understanding |
| 48 | * the application identification or handling the interaction with |
| 49 | * applications. |
| 50 | * |
| 51 | * NBI protocols need to handle the encoding and decoding of data to the |
| 52 | * protocol specific format. They are unaware of the YANG of applications, |
| 53 | * i.e. protocols are unaware of the data structure / organization in |
| 54 | * applications. |
| 55 | * |
| 56 | * They need to translate the protocol operation request, into a protocol |
| 57 | * independent abstract tree called the YANG data tree (YDT). In order to |
| 58 | * enable the protocol in building these abstract data tree, YANG |
| 59 | * management system provides a utility called the YANG data tree builder. |
| 60 | * |
| 61 | * Using the YANG data tree utility API's protocols are expected to walk |
| 62 | * the data received in request and pass the information during the walk. |
| 63 | * YANG data tree builder, identifies the application which supports the |
| 64 | * request and validates it against the schema defined in YANG, and |
| 65 | * constructs the abstract YANG data tree. |
| 66 | * |
| 67 | * Interaction type is a MANDATORY parameter which is used by YANG |
| 68 | * management system to perform the required operation in ONOS. |
| 69 | * |
| 70 | * NOTE: Same YDT builder instance cannot be reused across different |
| 71 | * operation request. A new instance needs to be used for every operation. |
| 72 | * |
| 73 | * Returns YANG data tree builder logical root container node. |
| 74 | * Protocol use this to logical root container to hold schema specific data |
| 75 | * that spans across different modules schema. |
| 76 | * |
| 77 | * @param logicalRootName name of a protocol specific logical container |
| 78 | * node to group data across multiple applications. |
| 79 | * This is only a logical container to group more |
| 80 | * than one application's root node. It is not |
| 81 | * validated against any YANG definition |
| 82 | * @param rootNamespace namespace of logical root container, if any, |
| 83 | * otherwise it can be sent as null |
| 84 | * @param operationType maps the request type to a corresponding |
| 85 | * operation request type to YANG management system |
| 86 | * @return YANG data tree builder, using which the abstract tree can be |
| 87 | * built corresponding to the data exchanged between protocol and YANG |
| 88 | * management system. |
| 89 | */ |
| 90 | YdtBuilder getYdtBuilder(String logicalRootName, String rootNamespace, |
| 91 | YmsOperationType operationType); |
| 92 | |
| 93 | /** |
| 94 | * Returns YANG data tree builder attached with a given schema registry. |
| 95 | * |
| 96 | * YMS provides a framework where-in protocols can register their protocol |
| 97 | * data format specific CODECS with YMS. These registered CODEC will be |
| 98 | * used by YMS to perform translations from data format to YDT and YDT to |
| 99 | * data format. YMS may intend to use these CODECS both for NBI and SBI. |
| 100 | * |
| 101 | * To perform decode i.e. generate YDT for given data format string, these |
| 102 | * CODECS implementation needs to call the API's of YDT. YDT referred the |
| 103 | * registered schema information while building tree. In case of NBI their |
| 104 | * is a single schema registry, but for SBI schema registry is per |
| 105 | * driver/provider. |
| 106 | * |
| 107 | * Now this schema registry information is provided to protocols |
| 108 | * CODECS while invoking "decodeProtocolDataToYdt" and |
| 109 | * "decodeCompositeProtocolDataToYdt", protocol CODECS needs to provide |
| 110 | * the schema registry while getting instance of YDT builder. |
| 111 | * The schemaRegistry may be null when the YMS is performing decode for NBI |
| 112 | * protocols. |
| 113 | * |
| 114 | * Validations for NBI and SBI will vary, schemaRegistry value will also |
| 115 | * indicate the usage scenario and will be used by YdtBuilder to carry out |
| 116 | * necessary validations. |
| 117 | * |
| 118 | * This is an overloaded method to YdtBuilder which MUST be used by the |
| 119 | * overridden protocols CODECS. |
| 120 | * |
| 121 | * @param logicalRootName name of a protocol specific logical container |
| 122 | * node to group data across multiple |
| 123 | * applications. |
| 124 | * This is only a logical container to group |
| 125 | * more |
| 126 | * than one application's root node. It is not |
| 127 | * validated against any YANG definition |
| 128 | * @param rootNamespace namespace of logical root container, if any, |
| 129 | * otherwise it can be sent as null |
| 130 | * @param operationType maps the request type to a corresponding |
| 131 | * operation request type to YANG management |
| 132 | * system |
| 133 | * @param schemaRegistryForYdt schema registry for Ydt, protocol CODECS get |
| 134 | * this value from YMS in |
| 135 | * "decodeProtocolDataToYdt" and |
| 136 | * "decodeCompositeProtocolDataToYdt" and |
| 137 | * provide it while obtaining YdtBuilder |
| 138 | * @return YANG data tree builder, using which the abstract tree can be |
| 139 | * built corresponding to the data exchanged between protocol and YANG |
| 140 | * management system. |
| 141 | */ |
| 142 | YdtBuilder getYdtBuilder(String logicalRootName, String rootNamespace, |
| 143 | YmsOperationType operationType, |
| 144 | Object schemaRegistryForYdt); |
| 145 | |
| 146 | /** |
| 147 | * Returns YANG data tree walker. |
| 148 | * |
| 149 | * YANG management system gets data from application to be returned |
| 150 | * in protocol operation or to notify to protocol(s) clients, YANG |
| 151 | * management system encodes the data in a YANG data tree and informs the |
| 152 | * protocol. |
| 153 | * Protocols can use the YANG data tree walker utility to have their |
| 154 | * callbacks to be invoked as per the YANG data tree walking. |
| 155 | * By this way protocols can encode the data from abstract YANG data tree |
| 156 | * into a protocol specific representation. |
| 157 | * |
| 158 | * @return YANG data tree walker utility |
| 159 | */ |
| 160 | YdtWalker getYdtWalker(); |
| 161 | |
| 162 | /** |
| 163 | * Once the NBI protocol translates the request information into an abstract |
| 164 | * YANG data tree, it uses YANG management system as a broker to get the |
| 165 | * operation executed in ONOS. |
| 166 | * |
| 167 | * YANG management system is responsible to split the protocol operation |
| 168 | * across application(s) which needs to participate, and collate the |
| 169 | * response(s) from application(s) and return an effective result of the |
| 170 | * operation request. |
| 171 | * |
| 172 | * YMS identifies the type of operation to be performed using the |
| 173 | * operation type in YANG builder data tree and process the corresponding |
| 174 | * operation request on the applicable application(s). |
| 175 | * The response information maintained in response YANG data tree and |
| 176 | * given to NBI protocol's to encode it using a YANG data tree walker. |
| 177 | * |
| 178 | * Depending on the operation type set in the YANG builder tree, the |
| 179 | * application(s) get / set / operation interface is invoked. |
| 180 | * These interface are part to the YANG modelled service interface. |
| 181 | * |
| 182 | * @param operationRequest operation request that was constructed |
| 183 | * by NBI protocol using YANG data tree |
| 184 | * builder. This operation request contains |
| 185 | * operation request that needs to be |
| 186 | * executed on the applicable application(s) |
| 187 | * @return returns the result of the operation execution. |
| 188 | * Depending on the operation type, the YANG response data tree can have |
| 189 | * the following information. |
| 190 | * |
| 191 | * In case of EDIT_CONFIG operation, it will have the status of the |
| 192 | * operation execution. If there is any applications schema specific |
| 193 | * error, then the schema error information will be encoded in the |
| 194 | * corresponding context node. In case the edit operation is successful |
| 195 | * there is no YANG response data tree created, hence getRootNode will |
| 196 | * return null. |
| 197 | * |
| 198 | * In case of query operation, it will have the status of the operation |
| 199 | * execution. If there is any application schema specific error, then |
| 200 | * schema error information will be encoded in the corresponding YANG |
| 201 | * context. In case the query operation is successful, YANG data tree |
| 202 | * contains the application data that matched the filter in the |
| 203 | * operation request. NBI protocol to use a Yang data tree walker to |
| 204 | * construct the protocol specific reply. |
| 205 | * |
| 206 | * In case of RPC operation, it will have the status of the operation |
| 207 | * execution. If there is any application schema specific error, then |
| 208 | * schema error information will be encoded in the corresponding YANG |
| 209 | * context. In case the RPC operation is successful, and the RPC |
| 210 | * does not have any RPC reply in YANG, then the YANG data tree will |
| 211 | * be null. |
| 212 | * In case the RPC has a RPC reply in YANG, then the YANG data tree |
| 213 | * will contain the application's RPC reply schema specific . |
| 214 | * NBI protocol to use a Yang data tree walker to construct the |
| 215 | * protocol specific reply. |
| 216 | */ |
| 217 | YdtResponse executeOperation(YdtBuilder operationRequest); |
| 218 | |
| 219 | // TODO execute operation which directly take data format string as input. |
| 220 | |
| 221 | /** |
| 222 | * Returns YANG notification service. |
| 223 | * |
| 224 | * NBI Protocols which can support notification delivery for application(s) |
| 225 | * needs to add themselves as a listeners with YANG notification service. |
| 226 | * Also protocols can use YANG notification service to check if a received |
| 227 | * notification should be filtered against any of their protocol specific |
| 228 | * filtering mechanism. |
| 229 | * |
| 230 | * @return YANG notification service instance |
| 231 | */ |
| 232 | YangNotificationService getYangNotificationService(); |
| 233 | |
| 234 | /** |
| 235 | * Registers service with YANG management system. |
| 236 | * |
| 237 | * Applications model their exposed interface in YANG, and register with |
| 238 | * YANG management system, so that it can be configured / managed by the |
| 239 | * set of protocols supported in ONOS. |
| 240 | * |
| 241 | * ONOS YANG tools generate the applications service interface |
| 242 | * corresponding to the application's interface designed in YANG. |
| 243 | * |
| 244 | * The Application which implements this service registers the generated |
| 245 | * service with YANG management system. The generated service interfaces |
| 246 | * have all the information modeled by applications in YANG. |
| 247 | * |
| 248 | * Registers application's YANG model with YANG management system. This |
| 249 | * is used by applications/core to register their service with YMS. |
| 250 | * |
| 251 | * @param appManager application manager instance which is |
| 252 | * implementing the service defined in YANG. |
| 253 | * @param yangService service interface generated by ONOS YANG |
| 254 | * tools corresponding to the interface modeled |
| 255 | * in YANG. |
| 256 | * @param supportedFeatureList mentions the list of YANG features supported |
| 257 | * by the application implementation. |
| 258 | * If it is null, then the application |
| 259 | * implementation supports all the features |
| 260 | * defined in the registered YANG module. |
| 261 | */ |
| 262 | void registerService(Object appManager, Class<?> yangService, |
| 263 | List<String> supportedFeatureList); |
| 264 | |
| 265 | /** |
| 266 | * Unregisters service which is registered in YANG management system. |
| 267 | * |
| 268 | * Applications model their exposed interface in YANG, and register with |
| 269 | * YANG management system, so that it can be configured / managed by the |
| 270 | * set of protocols supported in ONOS. |
| 271 | * |
| 272 | * ONOS YANG tools generate the applications service interface |
| 273 | * corresponding to the application's interface designed in YANG. |
| 274 | * |
| 275 | * The Application which implements this service registers the generated |
| 276 | * service with YANG management system. The generated service interfaces |
| 277 | * have all the information modeled by applications in YANG. |
| 278 | * |
| 279 | * Registers application's YANG model with YANG management system. This |
| 280 | * is used by applications/core to register their service with YMS. |
| 281 | * |
| 282 | * @param appManager application manager instance which is implementing |
| 283 | * the service defined in YANG. |
| 284 | * @param yangService service interface generated by ONOS YANG tools |
| 285 | * corresponding to the interface modeled in YANG. |
| 286 | */ |
| 287 | void unRegisterService(Object appManager, Class<?> yangService); |
| 288 | |
| 289 | /** |
| 290 | * Returns YANG codec handler utility. |
| 291 | * |
| 292 | * In SBI, the provider or driver uses YANG management system as a CODEC |
| 293 | * utility. These providers/drivers use the YANG codec utility to register |
| 294 | * the device schema. YANG utils is used to generate the java files |
| 295 | * corresponding to the device schema. Provider or driver use these classes |
| 296 | * to seamlessly manage the device as java objects. While sending the |
| 297 | * request to device, drivers use the utility to translate the objects to |
| 298 | * protocol specific data representation and then send to the device. |
| 299 | * Protocol or driver use the same instance of the codec utility across |
| 300 | * multiple translation request. Protocol or driver should not use the same |
| 301 | * instance of utility concurrently. |
| 302 | * |
| 303 | * @return YANG codec utility |
| 304 | */ |
| 305 | YangCodecHandler getYangCodecHandler(); |
| 306 | |
| 307 | // TODO exceptions handling and sending. |
| 308 | } |