2

NETCONF タグを含むデバイスに送信される XML RPC 要求を生成するためのより良い方法を見つけようとしています。

リクエストがどのように見えるべきかはわかっているので、私がやっていることは、XML-RPC リクエスト XML をプレースホルダーとともにハードコーディングすることです。これらのプレースホルダーは、後で実際の入力に置き換えることができます。

例えば：

<rpc message-id="">
  <get-config>
    <source>
      <running/>
    </source>
    <filter type="subtree" base_path="">
      <wing-stats>
        <device>
          <lldp>
            <dev_id/>
            <local_port/>
            <neighborId/>
            <Neighbor_port_id/>
          </lldp>
          <mac>@device_mac</mac>
        </device>
      </wing-stats>
    </filter>
  </get-config>
</rpc>

この例では、リクエストの送信中に @device_mac が置き換えられます。しかし、リクエスト XML をハードコーディングしていると感じたこともあります。リクエスト XML を生成するより良い方法はありますか?

Netconf データは、YANG/YIN ファイルを使用してモデル化されます。これらのファイルを使用して、少なくとも NETCONF 要求部分を生成する方法はありますか?

4

2 に答える 2

1

バラ、

これを行うには 2 つの方法があると思います: 利用可能な日付モデル駆動型ツールキットのいずれかを使用することができます。そのうちの少なくとも 1 つはモデル指向の API を生成し、詳細な XML (DOM) 操作を非表示にします。2 番目の方向は、 pyangツールによって実装されているように、 RFC 6110で定義されている YANG から DSDL へのマッピングを利用することです。現在、後者では、ツールがDSDLで動作できる必要があります。DSDL は、本質的にRelax NGとSchematronの組み合わせです。

お役に立てれば。

于 2012-04-04T12:56:49.230 に答える
0

それはすべてあなたの文脈に依存すると思います。アプリケーションがこの特定のモデルとこの特定の rpcのみをサポートすることを意図している場合、そのような小さなユース ケースに、より洗練された、モデルに依存しない API を使用するのはおそらくやり過ぎでしょう。

一方、アプリケーションが多くのモデルと rpc をサポートする必要がある場合、または実行時に追加される新しいモデルをサポートする必要がある場合でも、Carl が言及したようなモデルに適用できるソリューションを検討する必要があります。

于 2015-12-31T13:15:20.280 に答える