[要約] RFC 5381は、NETCONFをSOAP上で実装する経験とその目的についての報告です。SOAPを使用したNETCONFの実装に関する課題や解決策が提案されています。
Network Working Group T. Iijima
Request for Comments: 5381 Y. Atarashi
Category: Informational H. Kimura
M. Kitani
Alaxala Networks Corp.
H. Okita
Hitachi, Ltd.
October 2008
Experience of Implementing NETCONF over SOAP
石鹸でネットコンを実装した経験
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESGノート
This document discusses implementation experience of NETCONF over SOAP. Note that Section 2.4 of RFC 4741 states, "A NETCONF implementation MUST support the SSH transport protocol mapping". Therefore, a NETCONF implementation that only supports the SOAP transport described in this document and not (at least) also SSH is not in compliance with the NETCONF standards.
このドキュメントでは、SOAPを介したNetConfの実装エクスペリエンスについて説明します。RFC 4741のセクション2.4は、「NetConfの実装はSSH輸送プロトコルマッピングをサポートする必要がある」と述べています。したがって、このドキュメントに記載されている石鹸輸送のみをサポートするNetConf実装は、（少なくとも）SSHもNetConf標準に準拠していません。
Abstract
概要
This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server.
このドキュメントでは、著者がどのようにSOAP（Simple Object Access Protocol）ベースのNetConf（ネットワーク構成プロトコル）クライアントとサーバーを開発したかについて説明します。これは、HTTPの永続的な輸送接続の上にCookieを使用するRFC 4743の適合実装と相互運用しないNetConfの代替石鹸結合について説明しています。SOAPがNetConfの輸送プロトコルとして使用される場合、さまざまな種類の開発ツールが利用可能です。これらのツールを最大限に活用することにより、開発者はワークロードを大幅に削減できます。著者は、石鹸を介して送信されるNetConfメッセージを処理できるNMS（ネットワーク管理システム）とネットワーク機器を開発しました。このドキュメントは、SOAPベースのNetConfクライアントとサーバーの実装の経験から得られたNetConf開発ガイドラインを提供することを目的としています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. NETCONF over SOAP ..........................................3
1.2. Motivation .................................................3
2. NETCONF Development on Web Services Framework ...................4
2.1. WSDL as an Interface Description Language ..................5
2.2. Generation of APIs .........................................5
3. Architecture of the NETCONF over SOAP Implementation ............5
3.1. SOAP Implementation in NMS .................................6
3.1.1. SOAP Parser in NMS ..................................7
3.1.2. Session Maintenance in NMS ..........................7
3.2. SOAP Implementation in the Network Equipment ...............8
3.2.1. SOAP Parser in the Network Equipment ................8
3.2.2. Session Maintenance in the Network Equipment ........8
4. Guidelines for Developing NETCONF Clients and Servers ...........8
4.1. Procedures of Development of NETCONF Clients ...............9
4.1.1. Developing NETCONF Clients without Eclipse .........10
4.1.2. Developing NETCONF Clients Using Eclipse ...........11
4.2. Procedures of Development of NETCONF Servers ..............13
4.2.1. Developing NETCONF Servers without Eclipse .........14
4.2.2. Developing NETCONF Servers Using Eclipse ...........15
4.2.3. Developing NETCONF Servers with C
Programming Language ...............................18
5. Security Considerations ........................................18
6. Acknowledgements ...............................................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................19
This document is not a product from the NETCONF WG but a report on the experience acquired by individual developers.
このドキュメントは、NetConf WGの製品ではなく、個々の開発者が獲得した経験に関するレポートです。
SOAP (Simple Object Access Protocol) was specified in [RFC4743] as one of the transport protocols for NETCONF. It is designed to use XML (eXtensible Markup Language) as its description language, which is a fundamental messaging technology for Web Services. For this reason, SOAP is well suited to the NETCONF protocol and can be deployed widely.
SOAP（Simple Object Access Protocol）は、[RFC4743]でNetConfの輸送プロトコルの1つとして指定されました。XML（拡張可能なマークアップ言語）をその説明言語として使用するように設計されています。これは、Webサービスの基本的なメッセージングテクノロジーです。このため、SOAPはNetConfプロトコルに適しており、広く展開できます。
To develop a SOAP-based NETCONF client and server, several development tools are available as open-source software. The authors developed a SOAP-based NETCONF client and server by using available development tools. The SOAP-based NETCONF client was developed by utilizing Java APIs (Application Programming Interfaces) that are automatically generated from the XSD (XML Schema Definition) file and WSDL (Web Services Description Language) file obtained from [RFC4741] and [RFC4743], respectively. The SOAP-based NETCONF client that the authors developed acts as an NMS (Network Management System). The SOAP-based NETCONF server that the authors developed runs on network equipment and accepts NETCONF messages sent from the NETCONF client.
SOAPベースのNetConfクライアントとサーバーを開発するために、いくつかの開発ツールをオープンソースソフトウェアとして利用できます。著者は、利用可能な開発ツールを使用して、SOAPベースのNetConfクライアントとサーバーを開発しました。SOAPベースのNetConfクライアントは、XSD（XMLスキーマ定義）ファイルから自動的に生成されるJava API（アプリケーションプログラミングインターフェイス）を使用して開発されました。。著者が開発したSOAPベースのNetConfクライアントは、NMS（ネットワーク管理システム）として機能します。著者が開発したSOAPベースのNetConfサーバーは、ネットワーク機器で実行され、NetConfクライアントから送信されたNetConfメッセージを受け入れます。
The aim of this document is to describe why the authors believe SOAP is practical as a transport protocol for NETCONF when an NMS is developed. When developing an NMS that uses SOAP as its transport protocol, development tools and procedures can be used according to the Web Services framework. This document also describes the experience of implementing NETCONF over SOAP so that even those who have little knowledge of SOAP can start developing a SOAP-based NETCONF client and server.
この文書の目的は、NMSが開発されたときにNetConfの輸送プロトコルとしてSOAPが実用的であると著者が信じる理由を説明することです。SOAPを輸送プロトコルとして使用するNMSを開発する場合、Webサービスフレームワークに従って開発ツールと手順を使用できます。このドキュメントでは、SOAPを介してNetConfをSOAPに実装した経験についても説明しているため、SOAPの知識がほとんどない人でも、SOAPベースのNetConfクライアントとサーバーの開発を開始できます。
This document describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation as it relies on cookies used on top of the persistent transport connections of HTTP. This is provided for information purposes only based on the implementation experience of the authors.
このドキュメントでは、HTTPの永続的な輸送接続の上に使用されるCookieに依存するため、RFC 4743の適合実装と相互運用しないNetConfの代替石鹸結合について説明します。これは、著者の実装エクスペリエンスに基づいてのみ情報目的で提供されます。
SOAP is a fundamental messaging technology for Web Services. Therefore, if SOAP is used as a transport protocol for NETCONF, a network configuration performed by NETCONF is achieved on the Web Services framework. In this section, the overall architecture of Web Services is described.
SOAPは、Webサービスの基本的なメッセージングテクノロジーです。したがって、SOAPがNetConfのトランスポートプロトコルとして使用される場合、NetConfによって実行されるネットワーク構成がWebサービスフレームワークで達成されます。このセクションでは、Webサービスの全体的なアーキテクチャについて説明します。
+----------------+ +----------------------------+
| Format | | Register / Search |
| | | |
| XML | | UDDI |
| | | (Universal Description, |
| | | Discovery and Integration) |
| | +----------------------------+
| | +----------------------------+ +----------------+
| | | Service Description | | API |
| | | | | |
| | | WSDL | | JAXM |
| | +----------------------------+ | (Java API for |
| | +----------------------------+ | XML Messaging) |
| | | Fundamental Messaging | | JAX-RPC |
| | | | | (Java API for |
| | | SOAP | | XML / RPC) |
+----------------+ +----------------------------+ +----------------+
+----------------------------+
| Transport |
| |
| HTTP, HTTPS... |
+----------------------------+
Figure 1: Overall Architecture of Web Services
図1：Webサービスの全体的なアーキテクチャ
As depicted in Figure 1, peripheral technologies around SOAP/HTTP are well developed. Therefore, if SOAP/HTTP is chosen as a transport layer for the NETCONF protocol, the NMS development based on the Web Services framework can choose from different optional services and might be less expensive based on the use of already available services.
図1に示すように、石鹸/HTTP周辺の周辺技術はよく発達しています。したがって、SOAP/HTTPがNetConfプロトコルの輸送層として選択されている場合、Webサービスフレームワークに基づくNMS開発は、さまざまなオプションサービスから選択でき、すでに利用可能なサービスの使用に基づいて安価になる可能性があります。
WSDL [WSDL] defines how SOAP messages are exchanged between Web Services entities. Interfaces of Web Services entities are automatically generated by development tools when importing a WSDL file. Interfaces generated in this manner act as APIs. For the development of an NMS, only these APIs are necessary; there is no need to use SOAP directly.
WSDL [WSDL]は、SOAPメッセージがWebサービスエンティティ間でどのように交換されるかを定義します。Webサービスエンティティのインターフェイスは、WSDLファイルをインポートする際に開発ツールによって自動的に生成されます。この方法で生成されたインターフェイスは、APIとして機能します。NMSの開発には、これらのAPIのみが必要です。石鹸を直接使用する必要はありません。
Useful tools that can import a WSDL file are available with SOAP. For instance, Apache Axis [Axis] generates an interface from a WSDL file and is a widely used SOAP implementation middleware.
WSDLファイルをインポートできる便利なツールは、SOAPで利用できます。たとえば、Apache軸[軸]はWSDLファイルからインターフェイスを生成し、広く使用されているSOAP実装ミドルウェアです。
As described in the previous section, APIs are generated from a WSDL file by development tools such as Apache Axis. Such APIs are in the form of a Java library and act as programming interfaces for an NMS. By using these APIs, an NMS can send SOAP messages to Web Services entities.
前のセクションで説明したように、APIはApache軸などの開発ツールによってWSDLファイルから生成されます。このようなAPIはJavaライブラリの形式であり、NMSのプログラミングインターフェイスとして機能します。これらのAPIを使用することにより、NMSはSOAPメッセージをWebサービスエンティティに送信できます。
The architecture of the NETCONF over SOAP implementation is shown in Figure 2. A NETCONF implementation residing in an NMS works as a NETCONF client while network equipment acts as a NETCONF server. In this document, we call NETCONF-client and NETCONF-server implementations a NETCONF application and a NETCONF service provider, respectively. A SOAP implementation may be installed on both the NMS and the network equipment. Each instance of the SOAP implementations exchanges SOAP messages based on WSDL, as described in [RFC4743]. If Java libraries generated from the WSDL are provided in the NMS, engineers can develop a NETCONF application, which configures network equipment via the NETCONF protocol, by utilizing the Java library. There is no need for engineers to use XML or SOAP directly.
SOAP実装をめぐるNetConfのアーキテクチャを図2に示します。NMSに存在するNetConf実装は、NetConfクライアントとして機能し、ネットワーク機器はNetConfサーバーとして機能します。このドキュメントでは、NetConf-ClientおよびNetConf-Serverの実装をそれぞれNetConfアプリケーションとNetConfサービスプロバイダーと呼びます。NMSとネットワーク機器の両方にSOAP実装をインストールできます。SOAP実装の各インスタンスは、[RFC4743]で説明されているように、WSDLに基づいてSOAPメッセージを交換します。WSDLから生成されたJavaライブラリがNMSで提供されている場合、エンジニアはJavaライブラリを利用してNetConfプロトコルを介してネットワーク機器を構成するNetConfアプリケーションを開発できます。エンジニアがXMLまたはSOAPを直接使用する必要はありません。
+---------------------------+ +---------------------------+
| NETCONF Client | | NETCONF Server |
| (NMS) | | (Network Equipment) |
| +---------------------+ | | +---------------------+ |
| | NETCONF application | | | | NETCONF service | |
| | | | | | provider | |
| +---------------------+ | | +---------------------+ |
| +---------------------+ | | |
| | Java library | | | |
| +---------------------+ | | |
| +---------------------+ | | +---------------------+ |
| | SOAP Implementation | | | | SOAP Implementation | |
| | (Apache Axis) | | | | | |
| +---------------------+ | | +---------------------+ |
+-------^----------|--------+ +-------^----------|--------+
| | rpc-request | |
| +----- /SOAP ----+ |
| / HTTP(S) |
| |
| rpc-reply |
+---------------- /SOAP ---------------+
/ HTTP(S)
Figure 2: Architecture of NETCONF Implementation Using SOAP
The SOAP implementation in both the NMS and network equipment is explained in detail in the following sections.
NMSとネットワーク機器の両方でのSOAP実装については、次のセクションで詳しく説明しています。
Several SOAP implementations appropriate for use in an NMS are available today. Apache Axis is one such widely used implementation.
NMSでの使用に適したいくつかのSOAP実装が今日入手可能です。Apache軸は、そのような広く使用されている実装の1つです。
Axis works as a SOAP implementation and an NMS-development tool. For instance, WSDL2Java, one of Axis' tools, generates Java-class files from a WSDL file. Another tool called Java2WSDL does the opposite: it generates a WSDL file from Java-class files. Consequently, various benefits can be obtained if Axis is introduced as a SOAP implementation.
軸は、石鹸の実装およびNMS開発ツールとして機能します。たとえば、Axisのツールの1つであるWSDL2Javaは、WSDLファイルからJavaクラスファイルを生成します。Java2WSDLと呼ばれる別のツールは、逆のことを行います。JavaClassファイルからWSDLファイルを生成します。したがって、軸が石鹸の実装として導入された場合、さまざまな利点を得ることができます。
To develop a NETCONF application that is capable of various functions such as releasing log messages, Java-class files generated by the Axis tool may be extended by adding more functions. By utilizing these Java libraries, engineers can easily develop NETCONF applications.
ログメッセージのリリースなど、さまざまな機能が可能なNetConfアプリケーションを開発するには、Axisツールによって生成されたJavaクラスファイルを、より多くの機能を追加することで拡張できます。これらのJavaライブラリを利用することにより、エンジニアはNetConfアプリケーションを簡単に開発できます。
The SOAP Parser function is performed entirely by a SOAP implementation such as Apache Axis.
SOAPパーサー関数は、Apache軸などの石鹸の実装によって完全に実行されます。
When exchanging NETCONF messages between an NMS and network equipment, a NETCONF session has to be maintained on both sides, as described in [RFC4741].
[RFC4741]で説明されているように、NMSとネットワーク機器の間でNetConfメッセージを交換する場合、NetConfセッションを両側に維持する必要があります。
In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session state is tied to the state of the underlying transport (TCP) connection (just like in NETCONF over SSH [RFC4742] and NETCONF over BEEP [RFC4744]). However, HTTP itself is a stateless protocol, and many server implementations process user requests independently of previous requests received over the same transport connection. To simplify implementation of the NETCONF service provider, we used the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. Note that this means our implementation actually uses an alternative SOAP binding for NETCONF, which does not interoperate with RFC 4743 compliant implementations.
[RFC4743]では、HTTPは、SOAP上のNetConfの基礎となるプロトコルのオプションとして指定されています。HTTPがその目的に使用される場合、NetConfセッションの状態が基礎となる輸送（TCP）接続の状態に結び付けられていることも指定されています（SSH [RFC4742]上のNetConfと同様に、ビープ音[RFC4744]）。ただし、HTTP自体はStateless Protocolであり、多くのサーバー実装は、同じトランスポート接続で受信した以前のリクエストとは無関係にユーザー要求を処理します。NetConfサービスプロバイダーの実装を簡素化するために、HTTPヘッダー内のCookieフィールドを使用して、着信要求をNetConfセッションにマッピングしました。これは、実装が実際にNetConfに代替の石鹸結合を使用していることを意味することに注意してください。これは、RFC 4743準拠の実装と相互運用しないことです。
For example, the implemented NETCONF-session maintenance in the NMS works as follows. After the NMS sends a NETCONF hello message to the network equipment, the NETCONF service provider in the network equipment allocates a session identifier for the NETCONF application in the NMS and writes it inside the <session> element of a replying NETCONF hello message, as described in [RFC4741]. At the same time, the network equipment writes the same value in the cookie field inside an HTTP header. After that, a SOAP message encompassing the replying NETCONF hello message is added. When the NMS receives the newly allocated session identifier from the replying NETCONF hello message, the NETCONF application stores it and writes it inside a <session> element for subsequent NETCONF request messages and in a cookie field for subsequent HTTP headers. By recognizing the session identifier in NETCONF request messages and the cookie field in HTTP headers, the network equipment can maintain both a NETCONF session and the state of an HTTP connection. The NETCONF session is maintained over the maintained state of the HTTP connection. The stored session identifier is erased when the NMS sends a NETCONF close-session message and receives a NETCONF response message from the network equipment.
たとえば、NMSで実装されたネットコンセッションメンテナンスは次のように機能します。NMSがネットワーク機器にNetConf Helloメッセージを送信した後、ネットワーク機器のNetConfサービスプロバイダーは、NMSのNetConfアプリケーションのセッション識別子を割り当て、記載されているように応答するNetConf Helloメッセージの<session>要素内に書き込みます。[RFC4741]で。同時に、ネットワーク機器は、HTTPヘッダー内のCookieフィールドに同じ値を書き込みます。その後、返信NetConf Helloメッセージを含むSOAPメッセージが追加されます。NMSが応答するNetConf Helloメッセージから新しく割り当てられたセッション識別子を受信すると、NetConfアプリケーションはそれを保存し、後続のNetConf要求メッセージの<session>要素内および後続のHTTPヘッダーのCookieフィールドに書き込みます。NetConf要求メッセージとHTTPヘッダーのCookieフィールドのセッション識別子を認識することにより、ネットワーク機器はNetConfセッションとHTTP接続の状態の両方を維持できます。NetConfセッションは、HTTP接続の維持状態で維持されます。NMSがNetConfの密売メッセージを送信し、ネットワーク機器からNetConf応答メッセージを受信すると、保存されたセッション識別子が消去されます。
To accept SOAP messages sent from the NMS, it is also necessary to provide SOAP in the network equipment. As in the case of NMS, some free SOAP implementations are available today for installation on network equipment. However, the memory capacity of the network equipment might be limited. Therefore, the SOAP implementation may be chosen taking memory capacity into consideration. In some cases, a memory-saving method will be required when implementing SOAP in the network equipment.
NMSから送信された石鹸メッセージを受け入れるには、ネットワーク機器に石鹸を提供する必要もあります。NMSの場合と同様に、いくつかの無料の石鹸実装は、ネットワーク機器への設置のために本日利用できます。ただし、ネットワーク機器のメモリ容量は制限される場合があります。したがって、メモリ容量を考慮に入れてSOAP実装を選択することができます。場合によっては、ネットワーク機器に石鹸を実装するときにメモリ節約方法が必要になります。
A SOAP header inside the SOAP envelope is defined as optional. Therefore, the module that processes the SOAP header can be omitted if the memory capacity in the network equipment is insufficient. In this case, a SOAP parser in the network equipment is allowed to parse only mandatory parts of a SOAP envelope.
石鹸エンベロープ内の石鹸ヘッダーは、オプションとして定義されます。したがって、ネットワーク機器のメモリ容量が不十分な場合、石鹸ヘッダーを処理するモジュールは省略できます。この場合、ネットワーク機器の石鹸パーサーは、石鹸エンベロープの必須部分のみを解析できます。
To maintain NETCONF sessions with the NMS, the NETCONF service provider in the network equipment has to provide a session identifier to the NMS, as described in [RFC4741].
NMSでNetConfセッションを維持するために、ネットワーク機器のNetConfサービスプロバイダーは、[RFC4741]で説明されているように、NMSにセッション識別子を提供する必要があります。
For example, the implemented NETCONF-session maintenance in the network equipment works as follows. When the network equipment receives a NETCONF hello message from the NMS, the NETCONF service provider in the network equipment sets a session identifier inside the <session> element of a replying NETCONF hello message, as described in [RFC4741]. At the same time, the network equipment also sets the same value in the cookie field inside an HTTP header. After that, a SOAP message encompassing the replying NETCONF hello message is added. The cookie field inside the HTTP header is used for maintaining the state of the HTTP connection over which the NETCONF-session maintenance is ensured. The network equipment then sends an HTTP response message to the NMS. When the network equipment receives a NETCONF close-session message from the NMS, it erases the stored session identifier.
たとえば、ネットワーク機器で実装されたネットコンセッションメンテナンスは、次のように機能します。ネットワーク機器がNMSからNetConf Helloメッセージを受信すると、ネットワーク機器のNetConfサービスプロバイダーは、[RFC4741]に記載されているように、応答するNetConf Helloメッセージの<session>要素内にセッション識別子を設定します。同時に、ネットワーク機器は、HTTPヘッダー内のCookieフィールドに同じ値を設定します。その後、返信NetConf Helloメッセージを含むSOAPメッセージが追加されます。HTTPヘッダー内のCookieフィールドは、NetConf-Consessionメンテナンスが確保されるHTTP接続の状態を維持するために使用されます。ネットワーク機器は、NMSにHTTP応答メッセージを送信します。ネットワーク機器がNMSからNetConfの近接セッションメッセージを受信すると、保存されたセッション識別子が消去されます。
In the case of SOAP transport mapping, sharing information on the kinds of development tools that are available would help developers start developing SOAP-based NETCONF clients and servers. That would contribute to the rapid deployment of SOAP-based NETCONF clients and servers.
石鹸輸送マッピングの場合、利用可能な開発ツールの種類に関する情報を共有すると、開発者が石鹸ベースのNetConfクライアントとサーバーの開発を開始するのに役立ちます。これは、SOAPベースのNetConfクライアントとサーバーの迅速な展開に貢献します。
To develop a SOAP-based NETCONF client, a stub code may be generated. A stub is a library that is generated automatically from WSDL by a Web Services tool and that acts as a group of APIs. When using Apache Axis as a Web Services tool, a generated stub is in the form of Java APIs. These Java APIs display interfaces of a Web Service as if they are methods capable of configuring a local machine.
SOAPベースのNetConfクライアントを開発するには、スタブコードを生成することができます。スタブは、WebサービスツールによってWSDLから自動的に生成されるライブラリであり、APIのグループとして機能します。Apache軸をWebサービスツールとして使用する場合、生成されたスタブはJava APIの形式です。これらのJava APISは、ローカルマシンを構成できる方法であるかのように、Webサービスのインターフェイスを表示します。
The WSDL file named "netconf-soap_1.0.wsdl", which is selected from [RFC4743], specifies NETCONF messages to be exchanged between the NETCONF client and server. These NETCONF messages are the "hello" message and "rpc" message. Therefore, stub codes for creating the "hello" message and "rpc" message are generated from "netconf-soap_1.0.wsdl". However, the file "netconf-soap_1.0.wsdl" is not sufficient because no service element is specified.
[rfc4743]から選択された「netconf-soap_1.0.wsdl」という名前のWSDLファイルは、NetConfクライアントとサーバー間で交換されるNetConfメッセージを指定します。これらのNetConfメッセージは、「Hello」メッセージと「RPC」メッセージです。したがって、「hello」メッセージと「rpc」メッセージを作成するためのスタブコードは、「netconf-soap_1.0.wsdl」から生成されます。ただし、サービス要素が指定されていないため、「netconf-soap_1.0.wsdl」というファイルは十分ではありません。
In "myNetconfService.wsdl", which is also selected from [RFC4743], a service element is specified and "netconf-soap_1.0.wsdl" is imported. Stub codes generated from those WSDL files are found in files such as "Netconf.java", "NetconfLocator.java", and "NetconfBindingStub.java".
[rfc4743]からも選択されている「mynetconfservice.wsdl」では、サービス要素が指定され、「netconf-soap_1.0.wsdl」がインポートされます。これらのWSDLファイルから生成されたスタブコードは、「netconf.java」、「netconflocator.java」、「netconfbindingstub.java」などのファイルにあります。
When interfaces are used to operate the NETCONF protocol in the manner of "get-config" and "edit-config", for example, an XML schema file named "netconf.xsd", which is selected from [RFC4741], is used by being imported into "netconf-soap_1.0.wsdl". Using the XML schema, methods of operating the NETCONF protocol are generated in files such as "GetConfigType.java" and "EditConfigType.java".
インターフェイスを使用して、[getConfig]および「edit-config」のようにネットコンプロトコルを操作する場合、たとえば[rfc4741]から選択された「netconf.xsd」という名前のXMLスキーマファイルを使用して、[RFC4741]から選択します。「netconf-soap_1.0.wsdl」にインポートされています。XMLスキーマを使用して、NetConfプロトコルを操作する方法は、「getConfigType.java」や「EditConfigtype.java」などのファイルで生成されます。
When interfaces are used to configure network functions at the network equipment, a data model of each network function has to be defined in the style of an XML schema. The XML schema may be imported into "netconf-soap_1.0.wsdl" in the same manner as that of the XML schema in [RFC4741].
インターフェイスを使用してネットワーク機器でネットワーク機能を構成する場合、各ネットワーク関数のデータモデルをXMLスキーマのスタイルで定義する必要があります。XMLスキーマは、[RFC4741]のXMLスキーマと同じ方法で「NetConf-SOAP_1.0.WSDL」にインポートされる場合があります。
The connection between the NETCONF schema and a data model should be made by inserting the following attribute into elements of each data model. This attribute is defined in the XML schema in [RFC4741].
NetConfスキーマとデータモデルの間の接続は、次の属性を各データモデルの要素に挿入することで作成する必要があります。この属性は、[RFC4741]のXMLスキーマで定義されています。
<xs:attribute name="operation" type="editOperationType"
default="merge"/>
Consequently, using "myNetconfService.wsdl" to import "netconf-soap_1.0.wsdl", NETCONF schema, and the data model makes it possible to generate stub files containing interfaces to configure network equipment.
その結果、「mynetconfservice.wsdl」を使用して、「netconf-soap_1.0.wsdl」、netconfスキーマ、およびデータモデルをインポートすることで、ネットワーク機器を構成するインターフェイスを含むスタブファイルを生成できます。
When stub codes are generated, the development environment may be arranged as well. The development of a Java-based NETCONF client may use JDK (Java Development Kit) [JDK] and Apache Axis. In addition, using some IDE (Integrated Development Environment) such as Eclipse [Eclipse] with Apache Ant [Ant] and NetBeans [NetBeans] would reduce the developer workload significantly. When Eclipse is used as an IDE, first, the library (*.jar files) of Axis has to be added to the development project's build path as an external library. The library of Axis acts as a SOAP library, so there is no need to be concerned about SOAP messaging when programming a NETCONF client using the library of Axis.
スタブコードが生成されると、開発環境も配置される場合があります。JavaベースのNetConfクライアントの開発には、JDK（Java Development Kit）[JDK]およびApache軸を使用できます。さらに、Eclipse [Eclipse]とApache Ant [Ant]およびNetBeans [NetBeans]などのIDE（統合開発環境）を使用すると、開発者のワークロードが大幅に減少します。EclipseがIDEとして使用される場合、最初に、軸のライブラリ（*.jarファイル）を外部ライブラリとして開発プロジェクトのビルドパスに追加する必要があります。軸のライブラリは石鹸ライブラリとして機能するため、軸のライブラリを使用してNetConfクライアントをプログラミングする際に、石鹸メッセージングを心配する必要はありません。
Given that development of a NETCONF client is carried out in the environment of a Windows computer without Eclipse, and that "myNetconfService.wsdl" is placed in the "C:\NetconfClient" directory, a stub is generated by executing the following command in the command prompt.
NetConfクライアントの開発は、日食のないWindowsコンピューターの環境で実行され、「mynetconfservice.wsdl」が「c：\ netconfclient」ディレクトリに配置されていることを考えると、スタブは次のコマンドを実行することによって生成されます。コマンド・プロンプト。
C:\NetconfClient>java -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME%
\lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery-
0.2.jar;%AXIS_HOME%\lib\wsdl4j-1.5.1.jar
org.apache.axis.wsdl.WSDL2Java -p stub myNetconfService.wsdl
In the directory where the WSDL file is located, the WSDL2Java command is executed. Locations of each Axis library have to be specified. The environment variable of "AXIS_HOME" is the directory where Axis is installed. By executing the above command, files with an extension of "*.java" are generated in the "stub" directory, which is specified by the above command. Inside the stub directory, we can find files such as "NetconfBindingStub.java", "Hello.java", and "GetConfigType.java".
WSDLファイルが配置されているディレクトリでは、WSDL2Javaコマンドが実行されます。各軸ライブラリの場所を指定する必要があります。「axis_home」の環境変数は、軸がインストールされるディレクトリです。上記のコマンドを実行することにより、「*.java」の拡張機能を持つファイルは、上記のコマンドで指定されている「スタブ」ディレクトリで生成されます。スタブディレクトリ内では、「netconfbindingstub.java」、「hello.java」、「getConfigtype.java」などのファイルを見つけることができます。
Next, it is necessary to compile these files by executing the following command in the command prompt.
次に、コマンドプロンプトで次のコマンドを実行して、これらのファイルをコンパイルする必要があります。
C:\NetconfClient>javac -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar stub/*.java
After the compilation of those java files, "*.class" files are generated. After the compiling is done, the source code of the NETCONF client has to be written. Sample source code of the NETCONF client is shown in Figure 3. This NETCONF client is written by utilizing stub classes and interfaces, which are imported into the local package and referenced.
これらのJavaファイルの編集後、「*.class」ファイルが生成されます。コンパイルが完了した後、NetConfクライアントのソースコードを記述する必要があります。NetConfクライアントのサンプルソースコードを図3に示します。このNetConfクライアントは、ローカルパッケージにインポートされて参照されるスタブクラスとインターフェイスを利用することによって記述されています。
import org.apache.axis.types.UnsignedInt; import org.apache.axis.types.*;
org.apache.axis.types.unsignedintをインポートします。import org.apache.axis.types。*;
public class NetconfClient {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
try{
NetconfClient client = new NetconfClient();
java.net.URL url = new java.net.URL(args[0]);
stub.Netconf netconf =
new stub.NetconfLocator();
stub.NetconfPortType stubNetconf =
netconf.getnetconfPort(url);
URI[] uri = new URI[1]; stub.holders.HelloCapabilitiesHolder capability = new stub.holders.HelloCapabilitiesHolder(uri);
uri [] uri = new uri [1];stub.holders.hellocapabilityholder capability = new stub.holders.hellocapabilitiesholder（uri）;
UnsignedInt id = new UnsignedInt();
id.setValue(1);
org.apache.axis.holders.UnsignedIntHolder
holder = new
org.apache.axis.holders.UnsignedIntHolder(id)
;
stubNetconf.hello(capability, holder);
}catch(Exception e){
e.printStackTrace();
}
}
}
Figure 3: Sample Source Code of NETCONF Clients
図3：NetConfクライアントのサンプルソースコード
To add functions such as the release of log messages, these functions have to be incorporated at this stage. Again, the NETCONF client is developed by compiling its source codes.
ログメッセージのリリースなどの関数を追加するには、これらの関数をこの段階で組み込む必要があります。繰り返しますが、NetConfクライアントはソースコードをコンパイルして開発されます。
When we use Eclipse and Apache Ant, the procedures described in the previous section are significantly simplified and executed at one time. In this case, files named "build.xml" and "build.properties" are required for Apache Ant.
EclipseとApache Antを使用する場合、前のセクションで説明した手順は、一度に大幅に簡素化され、実行されます。この場合、「build.xml」と「build.properties」という名前のファイルがApache antに必要です。
The file named "build.xml" is written in XML and seen by Apache Ant when Apache Ant is running on Eclipse. The file specifies how Apache Ant behaves. According to the descriptions of the file, Apache Ant compiles source codes, generates JAR (Java ARchive) file, and so on. On the other hand, the file named "build.properties" specifies properties of the development environment where Apache Ant runs. This file is referred to by the "build.xml" file.
「build.xml」という名前のファイルはxmlで記述され、アパッチアリがEclipseで実行されているときにApache antによって見られます。ファイルは、Apache Antの動作方法を指定します。ファイルの説明によれば、Apache Antはソースコードをコンパイルし、Jar（Java Archive）ファイルを生成します。一方、「Build.Properties」という名前のファイルは、Apache Antが実行される開発環境のプロパティを指定します。このファイルは、「build.xml」ファイルで呼ばれます。
Examples of "build.xml" and "build.properties" are shown in Figure 4 and Figure 5, respectively.
「build.xml」と「build.properties」の例をそれぞれ図4と図5に示します。
<?xml version="1.0"?>
<project name="NetconfClient" default="all" basedir=".">
<property file="build.properties"/>
<path id="axis-classpath">
<fileset dir="${axis.libdir}">
<include name="*.jar"/>
</fileset>
</path>
<target name="prepare">
<mkdir dir="${destdir}"/>
</target>
<target name="stub" depends="prepare">
<java classname="org.apache.axis.wsdl.WSDL2Java" fork
="Yes">
<arg value="-o"/>
<arg value="${srcdir}"/>
<arg value="-p"/>
<arg value="${stub.stubdir}"/>
<arg value="${stub.wsdlpath}"/>
<classpath refid="axis-classpath"/>
</java>
</target>
<target name="compile" depends="stub">
<javac srcdir="${srcdir}" destdir="${destdir}"
encoding="UTF-8">
<classpath refid="axis-classpath"/>
</javac>
</target>
<target name="stub-jar" depends="compile">
<jar jarfile="${stub.jar}" basedir="${destdir}"/>
</target>
<target name="all" depends="stub-jar"/>
</project>
Figure 4: build.xml of NETCONF Clients
図4：NetConfクライアントのbuild.xml
axis.libdir=C:/axis-1_4/lib srcdir=src destdir=classes stub.stubdir=stub stub.wsdlpath=myNetconfService.wsdl stub.jar=NETCONF.jar
axis.libdir = c：/axis-1_4/lib srcdir = src destdir = classes stub.stubdir = stub.wsdlpath = mynetconfservice.wsdl stub.jar = netconf.jar
Figure 5: build.properties of NETCONF Clients
図5：NetConfクライアントのbuild.properties
The location of the WSDL file should be specified in the "build.properties" file. In the case shown in Figure 5, the location of the WSDL file is specified as being under the current directory.
WSDLファイルの場所は、「build.properties」ファイルで指定する必要があります。図5に示す場合、WSDLファイルの場所は現在のディレクトリの下にあるとして指定されています。
By running Apache Ant on Eclipse, the steps specified in Figure 4 are taken. First, stub codes are generated. Then, compiling of those stub codes is executed. We were careful about the encoding style used for the compiling. After the compilation, Apache Ant will generate a JAR file, which is the output that compresses all stub files (*.class) and acts as a library. In this example, the name "NETCONF.jar" is specified in Figure 5. The "NETCONF.jar" file also has to be added to the build path of the development project as an external library.
EclipseでApache Antを実行することにより、図4で指定された手順が取られます。まず、スタブコードが生成されます。次に、これらのスタブコードのコンパイルが実行されます。コンパイルに使用されるエンコーディングスタイルに注意しました。コンピレーションの後、Apache AntはJARファイルを生成します。これは、すべてのスタブファイル（*.class）を圧縮し、ライブラリとして機能する出力です。この例では、「netconf.jar」という名前を図5に指定します。「netconf.jar」ファイルも、外部ライブラリとして開発プロジェクトのビルドパスに追加する必要があります。
After the "NETCONF.jar" file is added to the build path of the development project, source codes of the NETCONF client can be written by utilizing stub classes and interfaces. Source codes like the one shown in Figure 3 can be written. By running Apache Ant again, the source code of the NETCONF client is compiled. The NETCONF client is developed in this manner.
「netconf.jar」ファイルが開発プロジェクトのビルドパスに追加された後、NetConfクライアントのソースコードは、スタブクラスとインターフェイスを利用して記述できます。図3に示すようなソースコードは書くことができます。Apache Antを再び実行することにより、NetConfクライアントのソースコードがコンパイルされます。NetConfクライアントはこの方法で開発されます。
In the Web Services framework, there are two approaches for developing a Web Services provider, namely a NETCONF server. One is called the top-down approach, and the other is called the bottom-up approach. The top-down approach is carried out by first designing a WSDL file. A skeleton source code from the WSDL file is then generated by using a Web Services tool such as Apache Axis. The generated skeleton code is just a template of the Web Services provider's source code. Therefore, even though the Web Services provider's skeleton code works on its own, if additional functions were necessary, the generated skeleton code would require additional source codes. This approach is superior to the bottom-up approach in terms of interoperability because the specification is already defined in the WSDL file. All vendors have to be in compliance with the WSDL file.
Web Services Frameworkには、Webサービスプロバイダー、つまりNetConfサーバーを開発するための2つのアプローチがあります。1つはトップダウンアプローチと呼ばれ、もう1つはボトムアップアプローチと呼ばれます。トップダウンアプローチは、最初にWSDLファイルを設計することにより実行されます。WSDLファイルのスケルトンソースコードは、Apache軸などのWebサービスツールを使用して生成されます。生成されたスケルトンコードは、Webサービスプロバイダーのソースコードのテンプレートにすぎません。したがって、Webサービスプロバイダーのスケルトンコードは単独で動作しますが、追加の機能が必要な場合、生成されたスケルトンコードには追加のソースコードが必要になります。このアプローチは、仕様がWSDLファイルで既に定義されているため、相互運用性の観点からボトムアップアプローチよりも優れています。すべてのベンダーは、WSDLファイルに準拠する必要があります。
In contrast, the bottom-up approach is carried out by first creating Web Services from source code (e.g., Java bean) and then generating a WSDL file from the source code by using a Web Services tool such as Axis. This approach is faster and easier than the top-down approach. However, in the bottom-up approach, it is difficult to ensure interoperability since implementation of a Web Services becomes vendor-specific.
対照的に、ボトムアップアプローチは、最初にソースコード（たとえば、Java Bean）からWebサービスを作成し、次にAxisなどのWebサービスツールを使用してソースコードからWSDLファイルを生成することにより実行されます。このアプローチは、トップダウンアプローチよりも速く、簡単です。ただし、ボトムアップアプローチでは、Webサービスの実装がベンダー固有になるため、相互運用性を確保することは困難です。
When developing a NETCONF server, the WSDL file is already defined in [RFC4743], so there is no choice but to develop the NETCONF server using the top-down approach. The remainder of this section describes the top-down approach for developing a NETCONF server.
NetConfサーバーを開発する場合、WSDLファイルは[RFC4743]で既に定義されているため、トップダウンアプローチを使用してNetConfサーバーを開発する以外に選択肢はありません。このセクションの残りの部分では、NetConfサーバーを開発するためのトップダウンアプローチについて説明します。
To develop a SOAP-based NETCONF server using the top-down approach, a skeleton code is necessary. A skeleton is a library, which is also generated automatically from WSDL by a Web Services tool. When using Axis as a Web Services tool, the generated skeleton is in the form of a Java library. From the same WSDL file as that used for generating the stub code, skeleton codes are generated in files such as "NetconfBindingSkeleton.java", "Hello.java", and "GetConfigType.java".
トップダウンアプローチを使用してSOAPベースのNetConfサーバーを開発するには、スケルトンコードが必要です。スケルトンはライブラリであり、WebサービスツールによってWSDLから自動的に生成されます。軸をWebサービスツールとして使用する場合、生成されたスケルトンはJavaライブラリの形式です。スタブコードの生成に使用されるものと同じWSDLファイルから、スケルトンコードは「netconfbindingskeleton.java」、「hello.java」、「getconfigtype.java」などのファイルで生成されます。
When skeleton codes are being generated, the development environment may be arranged as well. Moreover, when a Java-based NETCONF server is being developed, in addition to JDK and Axis, a servlet container such as Apache Tomcat [Tomcat] is necessary. The "webapps\axis" directory under the Axis directory has to be copied to the "webapps" directory under the Tomcat directory.
スケルトンコードが生成されると、開発環境も配置される場合があります。さらに、JDKと軸に加えて、JavaベースのNetConfサーバーが開発されている場合、Apache Tomcat [Tomcat]などのサーブレット容器が必要です。Axisディレクトリの下にある「WebApps \ axis」ディレクトリは、Tomcatディレクトリの下の「WebApps」ディレクトリにコピーする必要があります。
Given that the development environment of a NETCONF server is created in the environment of a Windows computer without Eclipse and "myNetconfService.wsdl" is placed in the "C:\NetconfServer" directory, a skeleton is generated by executing the following command in the command prompt.
NetConfサーバーの開発環境は、EclipseのないWindowsコンピューターの環境に作成され、「mynetconfservice.wsdl」が「c：\ netconfserver」ディレクトリに配置されます。促す。
C:\NetconfServer>java -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME%
\lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery-
0.2.jar;%AXIS_HOME%\lib\wsdl4j-1.5.1.jar
org.apache.axis.wsdl.WSDL2Java -p skeleton -s -S true -d Session
myNetconfService.wsdl
In the directory where the WSDL file is located, a WSDL2Java command is executed. Locations of each Axis library should be specified. The environment variable of "AXIS_HOME" is a directory where Axis is installed. By executing the above command, files with an extension of "*.java" are generated in the "skeleton" directory, which is specified in the above command. Inside the skeleton directory, files such as "NetconfBindingSkeleton.java", "Hello.java", and "GetConfigType.java" exist. Furthermore, files named "deploy.wsdd" and "undeploy.wsdd" are found. "Deploy.wsdd" and "undeploy.wsdd" are used when deploying a NETCONF server in a servlet container and when undeploying a NETCONF server from a servlet container, respectively.
WSDLファイルが配置されているディレクトリでは、WSDL2Javaコマンドが実行されます。各軸ライブラリの場所を指定する必要があります。「axis_home」の環境変数は、軸がインストールされるディレクトリです。上記のコマンドを実行することにより、「*.java」の拡張機能を持つファイルは、上記のコマンドで指定されている「Skeleton」ディレクトリで生成されます。スケルトンディレクトリ内には、「netconfbindingskeleton.java」、「hello.java」、「getConfigtype.java」などのファイルが存在します。さらに、「deploy.wsdd」と「undeploy.wsdd」という名前のファイルが見つかりました。「deploy.wsdd」および「undeploy.wsdd」は、サーブレットコンテナにNetConfサーバーを展開するとき、およびそれぞれサーブレット容器からネットコンサーバーを除外するときに使用されます。
Adding source codes of NETCONF server functions to skeleton codes such as "NetconfBindingImpl.java" is required as the need arises. Functions such as the release of log messages have to be added at this stage. After that, by executing the following command in the command prompt, compilation of java files is carried out. Doing so will generate "*.class" files.
NetConfサーバー関数のソースコードを追加すると、「NetConfbindingImpl.java」などのスケルトンコードが必要になるにつれて必要です。この段階でログメッセージのリリースなどの関数を追加する必要があります。その後、コマンドプロンプトで次のコマンドを実行することにより、Javaファイルのコンパイルが実行されます。そうすることで、「*.class」ファイルが生成されます。
C:\NetconfServer>javac -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar skeleton/*.java
A NETCONF server can be developed by following the above-described procedures. These class files should be copied into the directory "webapps\axis\WEB-INFO\classes" of the Apache Tomcat directory. Finally, the NETCONF server is deployed by executing the following command.
NetConfサーバーは、上記の手順に従って開発できます。これらのクラスファイルは、Apache Tomcatディレクトリのディレクトリ「webapps \ axis \ web-info \ classes」にコピーする必要があります。最後に、NetConfサーバーは次のコマンドを実行して展開されます。
C:\NetconfServer>java -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME%
\lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery-
0.2.jar org.apache.axis.client.AdminClient -p 832 depoy.wsdd
The command is executed in the directory where "deploy.wsdd" is located. The file "deploy.wsdd" is generated at the same time the skeleton code is generated. After deployment, the NETCONF server receives NETCONF messages sent from the NETCONF client.
コマンドは、「deploy.wsdd」があるディレクトリで実行されます。ファイル「deploy.wsdd」は、スケルトンコードが生成されると同時に生成されます。展開後、NetConfサーバーはNetConfクライアントから送信されたNetConfメッセージを受信します。
When Eclipse and Apache Ant are used, the procedures described in the previous section are significantly simplified and executed at one time. Files named "build.xml" and "build.properties" are required for Apache Ant. Examples of "build.xml" and "build.properties" are shown in Figure 6 and Figure 7, respectively.
EclipseとApache Antを使用すると、前のセクションで説明した手順は、一度に大幅に簡素化され、実行されます。「build.xml」と「build.properties」という名前のファイルは、apache antに必要です。「build.xml」と「build.properties」の例をそれぞれ図6と図7に示します。
<?xml version="1.0"?>
<project name="NetconfService" default="all" basedir=".">
<property file="build.properties"/>
<path id="axis-classpath">
<fileset dir="${axis.libdir}">
<include name="*.jar"/>
</fileset>
</path>
<target name="prepare">
<mkdir dir="${srcdir}"/>
<mkdir dir="${destdir}"/>
</target>
<target name="skeleton" depends="prepare">
<java classname="org.apache.axis.wsdl.WSDL2Java" fork
="Yes">
<arg value="-p"/>
<arg value="${skeletondir}"/>
<arg value="-o"/>
<arg value="${srcdir}"/>
<arg value="-s"/>
<arg value="-S"/>
<arg value="true"/>
<arg value="-d"/>
<arg value="Session"/>
<arg value="${wsdlpath}"/>
<classpath refid="axis-classpath"/>
</java>
</target>
<target name="compile" depends="skeleton">
<javac srcdir="${srcdir}" destdir="${destdir}"
encoding="UTF-8">
<classpath refid="axis-classpath"/>
</javac>
</target>
<target name="copy2axis" depends="compile">
<copy todir="${tomcat.axis.classesdir}" overwrite=
"true">
<fileset dir="${destdir}">
<include name="*.class"/>
<include name="*/*.class"/>
<include name="*/*/*.class"/>
</fileset>
</copy>
</target>
<target name="deploy" depends="copy2axis">
<java classname="org.apache.axis.client.AdminClient"
fork="Yes">
<arg value="-p"/>
<arg value="${deploy.port}"/>
<arg value="${deploy.ddname}"/>
<classpath refid="axis-classpath"/>
</java>
</target>
<target name="all" depends="deploy"/>
</project>
Figure 6: build.xml of NETCONF Servers
図6：NetConfサーバーのbuild.xml
axis.libdir=C:/axis-1_4/lib tomcat.axis.classesdir= C:/Program Files/Apache Software Foundation/Tomcat 6.0/ webapps/axis/WEB-INF/classes srcdir=src destdir=classes skeletondir=skeleton wsdlpath=myNetconfService.wsdl deploy.port=832 deploy.ddname=src/skeleton/deploy.wsdd
axis.libdir = c：/axis-1_4/lib tomcat.axis.classesdir = c：/program files/apacheソフトウェアファンデーション/Tomcat 6.0/webapps/axis/web-inf/classes srcdir = src destdir = classes skeletondir = skeleton wsdlpath= mynetconfservice.wsdl deploy.port = 832 deploy.ddname = src/skeleton/deploy.wsdd
Figure 7: build.properties of NETCONF Servers
図7：NetConfサーバーのbuild.properties
The locations of the WSDL file and "deploy.wsdd" file have to be specified in the "build.properties" file. In Figure 7, the location of the WSDL file and "deploy.wsdd" file are specified as being under the current directory.
wsdlファイルと「deploy.wsdd」ファイルの場所は、「build.properties」ファイルで指定する必要があります。図7では、WSDLファイルと「deploy.wsdd」ファイルの場所は、現在のディレクトリの下にあるとして指定されています。
By running Apache Ant on Eclipse, the steps shown in Figure 6 are followed. First, skeleton codes have to be generated. After the skeleton codes are generated, source codes of the NETCONF server functions may be added to the skeleton codes according to the functions that developers intend to add.
EclipseでApache Antを実行することにより、図6に示す手順が続きます。まず、スケルトンコードを生成する必要があります。スケルトンコードが生成された後、NetConfサーバー関数のソースコードは、開発者が追加する機能に従ってスケルトンコードに追加される場合があります。
Then, by running Apache Ant again, compiling of the skeleton codes is executed. As a result, class files of the NETCONF server are generated. Apache Ant copies these class files to the directory of Tomcat and deploys the NETCONF server. After that, the NETCONF server becomes accessible by the NETCONF client.
その後、Apache Antを再び実行することにより、スケルトンコードのコンパイルが実行されます。その結果、NetConfサーバーのクラスファイルが生成されます。Apache Antは、これらのクラスファイルをTomcatのディレクトリにコピーし、NetConfサーバーを展開します。その後、NetConfサーバーはNetConfクライアントからアクセス可能になります。
When the NETCONF server for network equipment is being implemented, memory capacity might be limited, so it might not be possible to install a Java environment on the network equipment. The network-equipment platform might not support a Web Services tool. In that case, it may be necessary to implement SOAP as well as the NETCONF server by using C programming language on the network equipment.
ネットワーク機器のNetConfサーバーが実装されている場合、メモリ容量は制限される可能性があるため、ネットワーク機器にJava環境をインストールすることはできない場合があります。Network-Equipmentプラットフォームは、Webサービスツールをサポートしていない場合があります。その場合、ネットワーク機器でCプログラミング言語を使用して、NetConfサーバーと同様にSOAPを実装する必要がある場合があります。
To develop a NETCONF server capable of receiving NETCONF messages sent over SOAP/HTTP, the network equipment may have an HTTP daemon and a NETCONF service provider. A commonly used HTTP daemon can be used. A SOAP module may be added to the HTTP daemon as a connector between the HTTP daemon and the NETCONF service provider. The NETCONF service provider for parsing NETCONF messages sent from the NETCONF client and sending reply NETCONF messages toward the NETCONF client may be developed.
SOAP/HTTPを介して送信されるNetConfメッセージを受信できるNetConfサーバーを開発するには、ネットワーク機器にはHTTPデーモンとNetConfサービスプロバイダーがある場合があります。一般的に使用されるHTTPデーモンを使用できます。SOAPモジュールは、HTTPデーモンとNetConfサービスプロバイダーの間のコネクタとしてHTTPデーモンに追加される場合があります。NetConfクライアントから送信されたNetConfメッセージを解析し、NetConfクライアントにReply NetConfメッセージを送信するためのNetConfサービスプロバイダーが開発される場合があります。
When an HTTP daemon receives a SOAP message that is sent over HTTP, the message is handed over to the SOAP module incorporated in the HTTP daemon. Then, the SOAP module removes the SOAP header and passes NETCONF messages to the NETCONF service provider. After that, the NETCONF service provider parses the NETCONF messages and configures the network equipment accordingly.
HTTPデーモンがHTTPを介して送信されるSOAPメッセージを受信すると、メッセージはHTTPデーモンに組み込まれたSOAPモジュールに引き渡されます。次に、SOAPモジュールはSOAPヘッダーを削除し、NetConfメッセージをNetConfサービスプロバイダーに渡します。その後、NetConfサービスプロバイダーはNetConfメッセージを解析し、それに応じてネットワーク機器を構成します。
The security considerations of [RFC4741] and [RFC4743] are applicable in this document. Implementers or users of SOAP-based NETCONF clients and servers should take these considerations into account.
[RFC4741]および[RFC4743]のセキュリティ上の考慮事項は、このドキュメントに適用されます。SOAPベースのNetConfクライアントとサーバーの実装者またはユーザーは、これらの考慮事項を考慮に入れる必要があります。
As specified in the security considerations section of [RFC4743], transport-level security, such as authentication of users and encryption of transport protocol, has to be ensured by TLS (Transport Layer Security) in the case of NETCONF SOAP binding. That is, security has to be provided in the form of NETCONF/SOAP/HTTPS.
[RFC4743]のセキュリティに関する考慮事項セクションで指定されているように、NetConf Soap Bindingの場合、TLS（輸送層のセキュリティ）によって、ユーザーの認証や輸送プロトコルの暗号化などの輸送レベルのセキュリティを確保する必要があります。つまり、セキュリティはNetConf/SOAP/HTTPSの形で提供する必要があります。
Extensive input was received from the members of the NETCONF design team, including: Andy Bierman, Simon Leinen, Bert Wijnen, Mehmet Ersue, Ted Goddard, Ray Atarashi, Ron Bonica, and Dan Romascanu. The following people have also reviewed this document and provided valuable input: Jari Arkko, Pasi Eronen, Chris Newman, Tim Polk, David Ward, Magnus Westerlund, and Christian Vogt.
Andy Bierman、Simon Leinen、Bert Wijnen、Mehmet Ersue、Ted Goddard、Ray Atarashi、Ron Bonica、Dan Romascanuなど、NetConfデザインチームのメンバーから広範な入力が受け取りました。以下の人々は、この文書をレビューし、Jari Arkko、Pasi Eronen、Chris Newman、Tim Polk、David Ward、Magnus Westerlund、Christian Vogtの貴重な入力も提供しています。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4743] Goddard、T。、「Simple Object Access Protocol（SOAP）でNetConfを使用」、RFC 4743、2006年12月。
[Ant] "Apache Ant". <http://ant.apache.org/>
[アリ]「アパッチアリ」。<http://ant.apache.org/>
[Axis] "Web Services - Axis".
<http://ws.apache.org/axis/>
[Eclipse] "Eclipse". <http://www.eclipse.org/>
[Eclipse]「Eclipse」。<http://www.eclipse.org/>
[JDK] "Java SE". <http://java.sun.com/javase/index.jsp>
[JDK]「Java SE」。<http://java.sun.com/javase/index.jsp>
[NetBeans] "NetBeans". <http://www.netbeans.org/index.html>
[netbeans]「netbeans」。<http://www.netbeans.org/index.html>
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742] Wasserman、M。およびT. Goddard、「Secure Shell（SSH）を介したNetConf構成プロトコルを使用」、RFC 4742、2006年12月。
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4744] Lear、E。およびK. Crozier、「Blocks拡張可能な交換プロトコル（BEEP）を介してNetConfプロトコルを使用」、RFC 4744、2006年12月。
[Tomcat] "Apache Tomcat". <http://tomcat.apache.org/>
[Tomcat]「Apache Tomcat」。<http://tomcat.apache.org/>
[WSDL] "Web Service Description Language (WSDL) 1.1". <http://www.w3.org/TR/wsdl>
[WSDL] "Webサービス説明言語（WSDL）1.1"。<http://www.w3.org/tr/wsdl>
Authors' Addresses
著者のアドレス
Iijima Tomoyuki Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan
Iijima Tomoyuki Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg。890 Saiwai-Ku Kashimada Kawasaki、Kanagawa 212-0058 Japan
Phone: +81-44-549-1735
Fax: +81-44-549-1272
EMail: tomoyuki.iijima@alaxala.com
Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan
Yoshifumi atarashi alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg。890 Saiwai-Ku Kashimada Kawasaki、Kanagawa 212-0058 Japan
Phone: +81-44-549-1735
Fax: +81-44-549-1272
EMail: atarashi@alaxala.net
Hiroyasu Kimura Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan
Hiroyasu Kimura Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg。890 Saiwai-Ku Kashimada Kawasaki、Kanagawa 212-0058 Japan
Phone: +81-44-549-1735 Fax: +81-44-549-1272 EMail: h-kimura@alaxala.net Makoto Kitani Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan
電話：81-44-549-1735ファックス：81-44-549-1272メール：h-kimura@alaxala.net makoto kitani alaxala Networks Corp. shin-kawasaki mitsui bldg。890 Saiwai-Ku Kashimada Kawasaki、Kanagawa 212-0058 Japan
Phone: +81-44-549-1735
Fax: +81-44-549-1272
EMail: makoto.kitani@alaxala.com
Hideki Okita Hitachi, Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan
秀樹、hitachi、Ltd。
Phone: +81-42-323-1111
Fax: +81-42-327-7868
EMail: hideki.okita.pf@hitachi.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。