opendaylight/md-sal/sal-binding-api/src/main/java/org/opendaylight/controller/sal/binding/api/RpcProviderRegistry.java

   1 /*
   2  * Copyright (c) 2014 Cisco Systems, Inc. and others.  All rights reserved.
   3  *
   4  * This program and the accompanying materials are made available under the
   5  * terms of the Eclipse Public License v1.0 which accompanies this distribution,
   6  * and is available at http://www.eclipse.org/legal/epl-v10.html
   7  */
   8 package org.opendaylight.controller.sal.binding.api;
   9
  10 import org.opendaylight.controller.md.sal.common.api.routing.RouteChangePublisher;
  11 import org.opendaylight.controller.sal.binding.api.BindingAwareBroker.RoutedRpcRegistration;
  12 import org.opendaylight.controller.sal.binding.api.BindingAwareBroker.RpcRegistration;
  13 import org.opendaylight.controller.sal.binding.api.rpc.RpcContextIdentifier;
  14 import org.opendaylight.yangtools.yang.binding.InstanceIdentifier;
  15 import org.opendaylight.yangtools.yang.binding.RpcService;
  16
  17 /**
  18  * Provides a registry for Remote Procedure Call (RPC) service implementations. The RPCs are
  19  * defined in YANG models.
  20  * <p>
  21  * There are 2 types of RPCs:
  22  * <ul>
  23  * <li>Global</li>
  24  * <li>Routed</li>
  25  * </ul>
  26  *
  27  * <h2>Global RPC</h2>
  28  * <p>
  29  * An RPC is global if there is intended to be only 1 registered implementation. A global RPC is not
  30  * explicitly declared as such, essentially any RPC that is not defined to be routed is considered global.
  31  * <p>
  32  * Global RPCs are registered using the
  33  * {@link #addRpcImplementation(Class, RpcService)} method.
  34  *
  35  * <h2>Routed RPC</h2>
  36  * <p>
  37  * MD-SAL supports routing of RPC between multiple implementations where the appropriate
  38  * implementation is selected at run time based on the content of the RPC message as described in
  39  * YANG model.
  40  * <p>
  41  * RPC routing is based on:
  42  * <ul>
  43  * <li><b>Route identifier</b> -
  44  * An {@link org.opendaylight.yangtools.yang.binding.InstanceIdentifier InstanceIdentifier} value
  45  * which is part of the RPC input. This value is used to select the correct
  46  * implementation at run time.</li>
  47  * <li><b>Context Type</b> - A YANG-defined construct which constrains the subset of
  48  * valid route identifiers for a particular RPC.</li>
  49  * </ul>
  50  *
  51  * <h3>Context type</h3>
  52  * <p>
  53  * A context type is modeled in YANG using a combination of a YANG <code>identity</code>
  54  * and Opendaylight specific extensions from <code>yang-ext</code> module. These extensions are:
  55  * <ul>
  56  * <li><b>context-instance</b> - This is used in the data tree part of a YANG model to
  57  * define a context type that associates nodes with a specified context <code>identity</code>.
  58  * Instance identifiers that reference these nodes are valid route identifiers for RPCs that
  59  * reference this context type.</li>
  60  * <li><b>context-reference</b> - This is used in RPC input to mark a leaf of type
  61  * <code>instance-identifier</code> as a reference to the particular context type defined by the
  62  * specified context <code>identity</code>. The value of this
  63  * leaf is used by the RPC broker at run time to route the RPC request to the correct implementation.
  64  * Note that <code>context-reference</code> may only be used on leaf elements of type
  65  * <code>instance-identifier</code> or a type derived from <code>instance-identifier</code>.</li>
  66  * </ul>
  67  *
  68  *
  69  * <h3>Routed RPC example</h3>
  70  * <p>
  71  * <h5>1. Defining a Context Type</h5>
  72  * <p>
  73  * The following snippet declares a simple YANG <code>identity</code> named <code>example-context</code>:
  74  *
  75  * <pre>
  76  * module example {
  77  *     ...
  78  *     identity example-context {
  79  *          description "Identity used to define an example-context type";
  80  *     }
  81  *     ...
  82  * }
  83  * </pre>
  84  * <p>
  85  * We then use the declared identity to define a context type by using it in combination
  86  * with the <code>context-instance</code> YANG extension. We'll associate the context type
  87  * with a list element in the data tree. This defines the set of nodes whose instance
  88  * identifiers are valid for the <code>example-context</code> context type.
  89  * <p>
  90  * The following YANG snippet imports the <code>yang-ext</code> module and defines the list
  91  * element named <code>item</code> inside a container named <code>foo</code>:
  92  *
  93  * <pre>
  94  * module foo {
  95  *     ...
  96  *     import yang-ext {prefix ext;}
  97  *     ...
  98  *     container foo {
  99  *          list item {
 100  *              key "id";
 101  *              leaf id {type string;}
 102  *              ext:context-instance "example-context";
 103  *          }
 104  *     }
 105  *     ...
 106  * }
 107  * </pre>
 108  * <p>
 109  * The statement <code>ext:context-instance "example-context";</code> inside the list element
 110  * declares that any instance identifier referencing <code>item</code> in the data
 111  * tree is valid for <code>example-context</code>. For example, the following instance
 112  * identifier:
 113  * <pre>
 114  *     InstanceIdentifier.create(Foo.class).child(Item.class,new ItemKey("Foo"))
 115  * </pre>
 116  * is valid for <code>example-context</code>. However the following:
 117  * <pre>
 118  *     InstanceIdentifier.create(Example.class)
 119  * </pre>
 120  * is not valid.
 121  * <p>
 122  * So using an <code>identity</code> in combination with <code>context-instance</code> we
 123  * have effectively defined a context type that can be referenced in a YANG RPC input.
 124  *
 125  * <h5>2. Defining an RPC to use the Context Type</h5>
 126  * <p>
 127  * To define an RPC to be routed based on the context type we need to add an input leaf element
 128  * that references the context type which will hold an instance identifier value to be
 129  * used to route the RPC.
 130  * <p>
 131  * The following snippet defines an RPC named <code>show-item</code> with 2 leaf elements
 132  * as input: <code>item</code> of type <code>instance-identifier</code> and <code>description</code>:
 133  *
 134  * <pre>
 135  * module foo {
 136  *      ...
 137  *      import yang-ext {prefix ext;}
 138  *      ...
 139  *      rpc show-item {
 140  *          input {
 141  *              leaf item {
 142  *                  type instance-identifier;
 143  *                  ext:context-reference example-context;
 144  *              }
 145  *              leaf description {
 146  *                  type "string";
 147  *              }
 148  *          }
 149  *      }
 150  * }
 151  * </pre>
 152  * <p>
 153  * We mark the <code>item</code> leaf with a <code>context-reference</code> statement that
 154  * references the <code>example-context</code> context type. RPC calls will then be routed
 155  * based on the instance identifier value contained in <code>item</code>. Only instance
 156  * identifiers that point to a <code>foo/item</code> node are valid as input.
 157  * <p>
 158  * The generated RPC Service interface for the module is:
 159  *
 160  * <pre>
 161  * interface FooService implements RpcService {
 162  *      Future&lt;RpcResult&lt;Void&gt;&gt; showItem(ShowItemInput input);
 163  * }
 164  * </pre>
 165  * <p>
 166  * For constructing the RPC input, there are generated classes ShowItemInput and ShowItemInputBuilder.
 167  *
 168  * <h5>3. Registering a routed RPC implementation</h5>
 169  * <p>
 170  * To register a routed implementation for the <code>show-item</code> RPC, we must use the
 171  * {@link #addRoutedRpcImplementation(Class, RpcService)} method. This
 172  * will return a {@link RoutedRpcRegistration} instance which can then be used to register /
 173  * unregister routed paths associated with the registered implementation.
 174  * <p>
 175  * The following snippet registers <code>myImpl</code> as the RPC implementation for an
 176  * <code>item</code> with key <code>"foo"</code>:
 177  * <pre>
 178  * // Create the instance identifier path for item "foo"
 179  * InstanceIdentifier path = InstanceIdentifier.create(Foo.class).child(Item.class, new ItemKey(&quot;foo&quot;));
 180  *
 181  * // Register myImpl as the implementation for the FooService RPC interface
 182  * RoutedRpcRegistration reg = rpcRegistry.addRoutedRpcImplementation(FooService.class, myImpl);
 183  *
 184  * // Now register for the context type and specific path ID. The context type is specified by the
 185  * // YANG-generated class for the example-context identity.
 186  * reg.registerPath(ExampleContext.class, path);
 187  * </pre>
 188  * <p>
 189  * It is also possible to register the same implementation for multiple paths:
 190  *
 191  * <pre>
 192  * InstanceIdentifier one = InstanceIdentifier.create(Foo.class).child(Item.class, new ItemKey(&quot;One&quot;));
 193  * InstanceIdentifier two = InstanceIdentifier.create(Foo.class).child(Item.class, new ItemKey(&quot;Two&quot;));
 194  *
 195  * RoutedRpcRegistration reg = rpcRegistry.addRoutedRpcImplementation(FooService.class, myImpl);
 196  * reg.registerPath(ExampleContext.class, one);
 197  * reg.registerPath(ExampleContext.class, two);
 198  * </pre>
 199  *
 200  * <p>
 201  * When another client invokes the <code>showItem(ShowItemInput)</code> method on the proxy instance
 202  * retrieved via {@link RpcConsumerRegistry#getRpcService(Class)}, the proxy will inspect the
 203  * arguments in ShowItemInput, extract the InstanceIdentifier value of the <code>item</code> leaf and select
 204  * the implementation whose registered path matches the InstanceIdentifier value of the <code>item</code> leaf.
 205  *
 206  * <h2>Notes for RPC Implementations</h2>
 207  *
 208  * <h3>RpcResult</h3>
 209  * <p>
 210  * The generated interfaces require implementors to return
 211  *  {@link java.util.concurrent.Future Future}&lt;{@link org.opendaylight.yangtools.yang.common.RpcResult RpcResult}&lt;{RpcName}Output&gt;&gt; instances.
 212  *
 213  * Implementations should do processing of RPC calls asynchronously and update the
 214  * returned {@link java.util.concurrent.Future Future} instance when processing is complete.
 215  * However using {@link com.google.common.util.concurrent.Futures#immediateFuture(Object) Futures.immediateFuture}
 216  * is valid only if the result is immediately available and asynchronous processing is unnecessary and
 217  * would only introduce additional complexity.
 218  *
 219  * <p>
 220  * The {@link org.opendaylight.yangtools.yang.common.RpcResult RpcResult} is a generic
 221  * wrapper for the RPC output payload, if any, and also allows for attaching error or
 222  * warning information (possibly along with the payload) should the RPC processing partially
 223  * or completely fail. This is intended to provide additional human readable information
 224  * for users of the API and to transfer warning / error information across the system
 225  * so it may be visible via other external APIs such as Restconf.
 226  * <p>
 227  * It is recommended to use the {@link org.opendaylight.yangtools.yang.common.RpcResult RpcResult}
 228  * for conveying appropriate error information
 229  * on failure rather than purposely throwing unchecked exceptions if at all possible.
 230  * While unchecked exceptions will fail the returned {@link java.util.concurrent.Future Future},
 231  * using the intended RpcResult to convey the error information is more user-friendly.
 232  */
 233 public interface RpcProviderRegistry extends //
 234         RpcConsumerRegistry, //
 235         RouteChangePublisher<RpcContextIdentifier, InstanceIdentifier<?>> {
 236     /**
 237      * Registers a global implementation of the provided RPC service interface.
 238      * All methods of the interface are required to be implemented.
 239      *
 240      * @param serviceInterface the YANG-generated interface of the RPC Service for which to register.
 241      * @param implementation "the implementation of the RPC service interface.
 242      * @return an RpcRegistration instance that should be used to unregister the RPC implementation
 243      *         when no longer needed by calling {@link RpcRegistration#close()}.
 244      *
 245      * @throws IllegalStateException
 246      *             if the supplied RPC interface is a routed RPC type.
 247      */
 248     <T extends RpcService> RpcRegistration<T> addRpcImplementation(Class<T> serviceInterface, T implementation)
 249             throws IllegalStateException;
 250
 251     /**
 252      * Registers an implementation of the given routed RPC service interface.
 253      * <p>
 254      * See the {@link RpcProviderRegistry class} documentation for information and example on
 255      * how to use routed RPCs.
 256      *
 257      * @param serviceInterface the YANG-generated interface of the RPC Service for which to register.
 258      * @param implementation the implementation instance to register.
 259      * @return a RoutedRpcRegistration instance which can be used to register paths for the RPC
 260      *         implementation via invoking {@link RoutedRpcRegistration#registerPath(....).
 261      *         {@link RoutedRpcRegistration#close()} should be called to unregister the implementation
 262      *         and all previously registered paths when no longer needed.
 263      *
 264      * @throws IllegalStateException
 265      *            if the supplied RPC interface is not a routed RPC type.
 266      */
 267     <T extends RpcService> RoutedRpcRegistration<T> addRoutedRpcImplementation(Class<T> serviceInterface,
 268                                                                                T implementation)
 269             throws IllegalStateException;
 270 }