Network Working Group T. Iijima
Internet-Draft Y. Atarashi
Intended status: Informational H. Kimura
Expires: May 22, 2008 M. Kitani
Alaxala Networks Corp.
H. Okita
Central Research Laboratory,
Hitachi, Ltd.
November 19, 2007
Experience of implementing NETCONF over SOAP
draft-iijima-netconf-soap-implementation-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Iijima, et al. Expires May 22, 2008 [Page 1]
Internet-Draft SOAP implementation November 2007
Abstract
NETCONF protocol is standardized to be exchanged over SSH, SOAP, or
BEEP. We developed a network management system based on NETCONF
protocol. For several reasons, we chose the SOAP protocol as a
transport protocol of NETCONF. This document describes why we chose
SOAP as a transport protocol and the insight gained from actual
development.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. NETCONF over SOAP . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Framework of Web service . . . . . . . . . . . . . . . . . . . 4
2.1. SOAP as a Transport Protocol . . . . . . . . . . . . . . . 4
2.2. WSDL as an Interface Description Language . . . . . . . . 5
3. Architecture of NETCONF over SOAP implementation . . . . . . . 6
3.1. SOAP implementation in NMS . . . . . . . . . . . . . . . . 7
3.1.1. SOAP Engine in NMS . . . . . . . . . . . . . . . . . . 7
3.1.2. Session maintenance in NMS . . . . . . . . . . . . . . 7
3.2. SOAP implementation in network equipment . . . . . . . . . 8
3.2.1. SOAP Engine in network equipment . . . . . . . . . . . 8
3.2.2. Session maintenance in network equipment . . . . . . . 8
4. Guideline of developing NETCONF client and server . . . . . . 9
4.1. Procedures of development of NETCONF client . . . . . . . 9
4.1.1. Developing NETCONF client without Eclipse . . . . . . 10
4.1.2. Developing NETCONF client with Eclipse . . . . . . . . 10
4.2. Procedures of development of NETCONF server . . . . . . . 12
4.2.1. Developing NETCONF server without Eclipse . . . . . . 13
4.2.2. Developing NETCONF server with Eclipse . . . . . . . . 14
4.2.3. Developing NETCONF server by C programming . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Iijima, et al. Expires May 22, 2008 [Page 2]
Internet-Draft SOAP implementation November 2007
1. Introduction
1.1. NETCONF over SOAP
In order to enable network equipment configuration automatically from
network systems, NETCONF is designed to use XML as its description
language since XML is easy for systems to understand. XML is a
suitable technology to cope with flexible specification changes and
frequent functional extensions, and it enables automatic operation.
SOAP is also designed to use XML and is expected to become an
indispensable technology of Web service. For this reason, SOAP is a
prospective technology and well suited to the NETCONF protocol.
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [3].
1.3. Motivation
This document describes why SOAP is practical as a transport protocol
of NETCONF in developing a network management system. This document
also describes the experience of implementing NETCONF over SOAP.
Iijima, et al. Expires May 22, 2008 [Page 3]
Internet-Draft SOAP implementation November 2007
2. Framework of Web service
SOAP is considered to be an indispensable technology of Web service.
So if we use SOAP as a transport protocol of NETCONF, network
configuration by NETCONF is achieved on a framework of Web service.
In this section, we describe the overall architecture of the Web
service.
+---+ +-----------+ +----------------+ +--------------+ +--------+
| | | Security | |Reliable Message| | Transaction | | Search |
|XML| | | | | | | | |
| | |WS-Security| | WS-Reliability | |WS-Transaction| | UDDI |
| | | | | | | | +--------+
| | | | | | | | +--------+ +---------+
| | | | | | | | |language| | API |
| | | | | | | | | | | |
| | | | | | | | | WSDL | | JAXM |
| | +-----------+ +----------------+ +--------------+ +--------+ | JAX-RPC |
| | +----------------------------------------------------------+ | .NET |
| | | Fundamental Messaging | | |
| | | | | |
| | | SOAP | | |
+---+ +----------------------------------------------------------+ +---------+
+----------------------------------------------------------+
| Transport |
| |
| HTTP, HTTPS... |
+----------------------------------------------------------+
Figure 1: Overall architecture of Web service
As depicted in figure 1, peripheral technologies around SOAP/HTTP are
well developed, including security technology. For instance, WS-
Security and WS-Transaction technology are installed on SOAP only by
inserting particular messages in the SOAP Header. If we do not
choose SOAP/HTTP as a transport layer of the NETCONF protocol, we
have to develop each surrounding technology from scratch. Hence,
when introducing additional technologies around SOAP, the development
of a NETCONF-based network management system is relatively easy when
we choose SOAP as a transport protocol of NETCONF.
2.1. SOAP as a Transport Protocol
SOAP is basically designed to use distributed objects scattered
around the Internet regardless of platform. Therefore, SOAP is
developed as a messaging technology that uses standardized internet
Iijima, et al. Expires May 22, 2008 [Page 4]
Internet-Draft SOAP implementation November 2007
technologies such as HTTP and XML.
In addition, SOAP is so flexible that it is easy to incorporate other
technologies. For instance, the notion of session can be easily
incorporated in SOAP by inserting a message ID into a SOAP Header.
2.2. WSDL as an Interface Description Language
WSDL is designed so as to bind easily with SOAP. WSDL is an
innovative technology for Web service since the development tool
automatically generates interfaces to Web service by simply importing
WSDL into the development tool. Developers only need to customize
the programs by putting the generated interfaces together.
Regarding development tools that understand WSDL, useful technologies
are available with SOAP. For instance, Apache Axis is an interface
generator from WSDL as well as a widely used SOAP implementation
written in Java. If we choose SOAP as a transport protocol, we do
not need to develop interfaces to Web service by ourselves owing to
the development tool.
Iijima, et al. Expires May 22, 2008 [Page 5]
Internet-Draft SOAP implementation November 2007
3. Architecture of NETCONF over SOAP implementation
In this section, we describe the architecture of NETCONF
implementation using SOAP as its transport protocol. Figure 2 is the
architecture of the NETCONF implementation using SOAP. SOAP
implementation is implemented on both a network management system and
network equipment. And each SOAP implementation exchanges SOAP
messages based on the WSDL which is provided by [2]. If Java library
which is generated from the WSDL are provided on the network
management system, engineers can develop NETCONF application, which
can configure network equipment via the NETCONF protocol, by
utilizing the Java library. Engineers don't need to write neither
SOAP nor XML directly by hands. NETCONF application developed in
network management system works as a NETCONF client while network
equipment acts as a NETCONF server.
+-------------------------------------------------------+
| Network Management System |
| |
| +--------------------------------------------+ |
| | NETCONF application | |
| +--------------------------------------------+ |
| +--------------------------------------------+ |
| | Java library | |
| +--------------------------------------------+ |
| +--------------------------------------------+ |
| | SOAP Implementation | |
| | | |
| | Apache Axis | |
| +--------------------------------------------+ |
+---------------------|----------^----------------------+
| |
rpc-request | | rpc-reply
/ SOAP | | / SOAP
/ HTTP(S) | | / HTTP(S)
| |
+---------------------v----------|----------------------+
| +--------------------------------------------+ |
| | SOAP Implementation | |
| +--------------------------------------------+ |
| |
| Network Equipment |
+-------------------------------------------------------+
Figure 2: Architecture of NETCONF implementation using SOAP
Iijima, et al. Expires May 22, 2008 [Page 6]
Internet-Draft SOAP implementation November 2007
In the following section, we explain the SOAP implementation in
detail in both NMS (Network Management System) and network equipment.
3.1. SOAP implementation in NMS
Several SOAP implementations capable of being installed on NMS are
available today. For instance, Apache Axis is a practical free
software implementation of SOAP when we choose SOAP as a transport
protocol. Rapid parsing in the NMS is achieved by Axis since it uses
SAX as its parser.
Also, Axis is not only a SOAP implementation but a useful tool to
develop a NMS. For instance, WSDL2Java, one of Axis's tools, can
generate Java's class file from WSDL file. Another tool called
Java2WSDL does the opposite. We can generate WSDL file from Java's
class file. Conclusively, various kinds of benefits can be acquired
if we introduce Axis as a SOAP implementation.
In order to develop NETCONF-capable applications, Java library, which
is generated by Apache Axis tool and run over SOAP implementation,
has to be extended to incorporate such functions as session
management and releasing of log messages. By utilizing these Java
library, engineers can easily develop NETCONF applications.
3.1.1. SOAP Engine in NMS
The function of SOAP Engine is totally left to a SOAP implementation
such as Apache Axis.
3.1.2. Session maintenance in NMS
When exchanging NETCONF messages between NMS and network equipment,
implementation of session maintenance function is necessary in both
sides. We used Cookie field in a HTTP header as a session identifier
and implemented a session maintenance function which manages the
Cookie field. After NMS sends a NETCONF hello message to network
equipment, NMS receives a newly allocated session identifier which is
written in the Cookie field of a replying hello message. NMS
preserves the Cookie paired with the network equipment's MAC address
and uses it for the subsequent NETCONF messages exchange as a session
identifier. When NMS sets the Cookie for the following NETCONF
messages, the network equipment recognize it and maintains sessions.
The stored Cookie is erased when the NMS sends a close session
message and received a response message from network equipment.
Iijima, et al. Expires May 22, 2008 [Page 7]
Internet-Draft SOAP implementation November 2007
3.2. SOAP implementation in network equipment
SOAP must also be implemented in the network equipment in order to
accept SOAP messages sent from the NMS. Like the case of NMS, some
free SOAP implementations to be installed on network equipment are
available today. However, in the case of network equipment, memory
capacity might be limited. Therefore, SOAP implementation have to be
chosen taking memory capacity into consideration, and memory saving
method might be required when implementing SOAP engine in the network
equipment.
3.2.1. SOAP Engine in network equipment
When we choose HTTP as an underlying protocol over which SOAP is
sent, the SOAP message consists of HTTP header and a SOAP Envelope.
The SOAP Envelope is a necessary part of every SOAP message. But in
regard to the SOAP encodingStyle attribute inside the Envelope
elements, it is not required to be specified. In such a case,
default encodingStyle of "http://schema.xmlsoap.org/soap/encoding" is
applied. So if there's a memory constraint, we can omit a function
of parsing encodingStyle.
Similarly, SOAP Header inside the SOAP Envelope is defined as
optional. So, when memory capacity in network equipment is
insufficient, the module that processes SOAP Header can be omitted.
After all, a SOAP engine in network equipment is allowed to act only
as a SOAP Envelope and Body parser.
3.2.2. Session maintenance in network equipment
In order to maintain sessions with the NMS, SOAP implementation in
network equipment must provide session identifier to the NMS. When
network equipment receives NETCONF hello message from the NMS, SOAP
implementation in network equipment sets session identifier paired
with network equipment's MAC address in a Cookie field of the HTTP
header and sends it back as a response message. The session
identifier is used when locking the configuration of the network
equipment. When network equipment receives a NETCONF close message
from the NMS, the network equipment erases the Cookie identifier.
Iijima, et al. Expires May 22, 2008 [Page 8]
Internet-Draft SOAP implementation November 2007
4. Guideline of developing NETCONF client and server
NETCONF implementations running on SOAP implementation in NMS and in
network equipment acts as NETCONF client and NETCONF server
respectively. By making full use of various tools such as Apache
Axis, Apache Ant, Eclipse and so on, it becomes easier to develop
SOAP-based NETCONF client and server.
4.1. Procedures of development of NETCONF client
In order to develop SOAP-based NETCONF client, stub codes is
necessary. Stub is a library, which is generated automatically from
WSDL by a Web service tool and shows interfaces toward Web service as
methods available in local package. When using Apache Axis as a Web
service tool, generated stub is in a form of Java library.
WSDL file named "netconf-soap_1.0.wsdl" extracted from [2] is
specifying NETCONF messages to be exchanged between NETCONF client
and server. However, the file is not enough for generating stub code
since service element is not specified. By adding service element
of, for example, "NetconfService" to "netconf-soap_1.0.wsdl", stub
files such as "NetconfService.java", "NetconfServiceLocator.java",
and "NetconfBindingStub.java" are generated. In addition, as for
interfaces of how to configure network equipment such as "get-
config", "edit-config", [2] is importing XML schema file named
"netconf.xsd" of [1]. In regards to interfaces of what network
functions to be configured, however, data models have to be defined
in a style of XML schema and be imported to [2]. The connection
between NETCONF schema and data model should be done by inserting
<xs:attribute name="operation" type="editOperationType"
default="merge"/>, which is defined in NETCONF schema [1], into each
data model's elements. From the "netconf-soap_1.0.wsdl" importing
NETCONF schema and data model, we can generate stub files containing
interfaces to configure network equipment.
Before generating stub codes, development environment needs to be
arranged. When developing Java-based NETCONF client, JDK (Java
Development Kit), and Apache Axis are necessary. In addition, some
IDE (Integrated Development Environment) such as Eclipse, NetBeans
and hopefully Apache Ant would reduce developers workload
significantly. When using Eclipse as an IDE, first of all, library
(*.jar files) of Apache Axis have to be added to development
project's build path as an external library. Since library of Apache
Axis acts as SOAP library, we don't need to be aware of SOAP
messaging when developing NETCONF client.
Iijima, et al. Expires May 22, 2008 [Page 9]
Internet-Draft SOAP implementation November 2007
4.1.1. Developing NETCONF client without Eclipse
Stub is generated by executing following command in DOS-prompt on the
assumption that netconf-soap_1.0.wsdl, namely WSDL file extracted
from [2], is placed in the directory of "C:\NetconfClient" and in the
environment of Windows computer without Eclipse.
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 netconf-soap_1.0.wsdl
In the directory where WSDL file is located, WSDL2Java command was
executed. In the case we don't use Eclipse, locations of each Axis
library has to be specified as a class path. "AXIS_HOME" is a
directory where Apache Axis is installed. By executing above
command, files with extension of "*.java" are generated in the "stub"
directory, which is specified by above command. Inside the stub
directory, we can find files such as "NetconfBindingStub.java",
"Hello.java", and "GetConfigType.java" and the like. Then, we
compiled them by executing following command in DOS-prompt.
C:\NetconfClient>javac -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar stub/*.java
Compiling those java files will generate "*.class" files. At the
time of compiling, encoding style might be taken care of. After
compiling, we wrote source code of the NETCONF client utilizing
stub's classes and interfaces which are imported to local package and
referenced. Functions such as session management, releasing of log
messages, and son on have to be incorporated at this stage. And
again, we compiled the source code of the NETCONF client. NETCONF
client can be developed by taking these procedures.
4.1.2. Developing NETCONF client with Eclipse
In the case we use Eclipse and Apache Ant, above procedures are
significantly simplified and executed at one time. In this case,
files named "build.xml" and "build.properties" are required for
Apache Ant. Examples of "Build.xml" and "build.properties" are shown
in Figure 3 and Figure 4 respectively.
Iijima, et al. Expires May 22, 2008 [Page 10]
Internet-Draft SOAP implementation November 2007
<?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}">
</jar>
</target>
<target name="all" depends="stub-jar"/>
</project>
Figure 3: build.xml of NETCONF client
axis.libdir=C:/axis-1_4/lib
srcdir=src
destdir=classes
stub.stubdir=stub
stub.wsdlpath=netconf-soap_1.0.wsdl
stub.jar=NETCONF.jar
Figure 4: build.properties of NETCONF client
Iijima, et al. Expires May 22, 2008 [Page 11]
Internet-Draft SOAP implementation November 2007
The location of WSDL file has to be specified in the
"build.properties" file. In the case of Figure 4, the location of
WSDL file is specified as under the current directory. As shown in
Figure 4, after generating NETCONF stub code, Apache Ant will
generate NETCONF.jar file, which is compressing all stub files
(*.class) and acts as a library. The NETCONF.jar file also have to
be added to development project's build path as an external library.
After adding NETCONF.jar file to build path, we wrote NETCONF
client's source codes utilizing stub's classes and interfaces.
Functions such as session management, releasing of log messages, and
son on have to be incorporated at this stage. And we compiled them
and developed the NETCONF client.
4.2. Procedures of development of NETCONF server
There are two ways of developing Web service provider. The one is
called top-down approach, and another is called bottom-up approach.
The top-down approach is done by first designing WSDL file, and then
generate skeleton source code from WSDL file by using a Web service
tool such as Apache Axis. Generated skeleton code just provides
template of the source code. So generated skeleton code requires
additional source codes in order to work as a Web service provider.
This way is superior to bottom-up approach in terms of
interoperability since specification is already defined in WSDL file.
By contrast, the bottom-up approach is first creating Web service
from a source code (e.x. Java bean) and then generating WSDL file
from the source code by using a Web service tool such as Apache Axis.
This approach is faster and easier than top-down approach. But in
the case of bottom-up approach, ensuring the interoperability becomes
difficult since implementation of Web service becomes vendor-
specific.
In the case of developing NETCONF server, since WSDL file is already
defined in [2], there's no choice but to develop NETCONF server by
top-down approach. The rest of the section mentions the top-down
approach of developing NETCONF server.
In order to develop SOAP-based NETCONF server by top-down approach,
skeleton code is necessary. Skeleton is a library, which is also
generated automatically from WSDL by a Web service tool. When using
Apache Axis as a Web service tool, generated skeleton is in a form of
Java library. From the same WSDL file as the one being used for
generating stub, skeleton files such as
"NetconfBindingSkeleton.java", "Hello.java", "GetConfigType.java",
and so forth are generated.
Before generating skeleton codes, development environment needs to be
Iijima, et al. Expires May 22, 2008 [Page 12]
Internet-Draft SOAP implementation November 2007
arranged. When developing Java-based NETCONF server, servlet
container such as Apache Tomcat is necessary in addition to JDK,
Apache Axis. And the directory of "webapps\axis" under Apache Axis
have to be copied to the directory of "webapps" under Apache Tomcat.
4.2.1. Developing NETCONF server without Eclipse
Skeleton is generated by executing following command in DOS-prompt on
the assumption that netconf-soap_1.0.wsdl, namely WSDL file extracted
from [2], is placed in the directory of "C:\NetconfServer" and in the
environment of Windows computer without Eclipse.
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 skeleton -s -S true -d Session
netconf-soap_1.0.wsdl
In the directory where WSDL file is located, WSDL2Java command was
executed. In the case we don't use Eclipse, locations of each Axis
library have to be specified as a class path. "AXIS_HOME" is a
directory where Apache Axis is installed. By executing above
command, files with extension of "*.java" are generated in the
"skeleton" directory, which is specified in the above command.
Inside the skeleton directory, we can find files such as
"NetconfBindingSkeleton.java", "Hello.java", and "GetConfigType.java"
and the like. Furthermore, files named "deploy.wsdd" and
"undeploy.wsdd" are found. "Deploy.wsdd" and "undeploy.wsdd" are
used when deploying NETCONF service to servlet container and
undeploying NETCONF service from servlet container respectively.
Then, it is required to add source code of the NETCONF server to the
skeleton code such as "NetconfBindingImpl.java". Functions such as
session management, releasing of log messages, and son on have to be
added at this stage. And compiling these java files by executing
following command in DOS-prompt will generate "*.class" files.
C:\NetconfClient>javac -classpath .;%AXIS_HOME%\lib\axis.jar;%
AXIS_HOME%\lib\jaxrpc.jar skeleton/*.java
NETCONF server can be developed by taking these procedures. Then, it
is required to copy these class files into the directory of
"webapps\axis\WEB-INFO/classes" of Apache Tomcat. Finally, it is
required to deploy NETCONF service by executing following command.
At this time, "deploy.wsdd", which was generated at the time of
generating skeleton, is required.
C:\NetconfClient>java -classpath .;%AXIS_HOME%\lib\axis.jar;%
Iijima, et al. Expires May 22, 2008 [Page 13]
Internet-Draft SOAP implementation November 2007
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
In the direcotory where "deploy.wsdd" is located, the command was
executed.
4.2.2. Developing NETCONF server with Eclipse
In the case we use Eclipse and Apache Ant, above procedures are
significantly simplified and executed at one time. In this case,
files named "build.xml" and "build.properties" are required for
Apache Ant. Examples of "Build.xml" and "build.properties" are shown
in Figure 5 and Figure 6 respectively.
Iijima, et al. Expires May 22, 2008 [Page 14]
Internet-Draft SOAP implementation November 2007
<?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="${destdir}"/>
</target>
<target name="skeleton" depends="prepare">
<java classname="org.apache.axis.wsdl.WSDL2Java" fork="Yes">
<arg value="-p"/>
<arg value="${skeleton.skeletondir}"/>
<arg value="-o"/>
<arg value="${srcdir}"/>
<arg value="-s"/>
<arg value="-S"/>
<arg value="true"/>
<arg value="-d"/>
<arg value="Session"/>
<arg value="${skeleton.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="${skeleton.destdir}">
<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>
Iijima, et al. Expires May 22, 2008 [Page 15]
Internet-Draft SOAP implementation November 2007
Figure 5: build.xml of NETCONF server
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
skeleton.skeletondir=skeleton
skeleton.wsdlpath=netconf-soap_1.0.wsdl
skeleton.destdir=classes/skeleton
deploy.port=832
deploy.ddname=deploy.wsdd
Figure 6: build.properties of NETCONF server
The location of WSDL file and "deploy.wsdd" file have to be specified
in the "build.properties" file. In the case of Figure 6, the
location of WSDL file and "deploy.wsdd" file are specified as under
the current directory. After generating skeleton, it is required to
add source code of the NETCONF server to skeleton code. Functions
such as session management, releasing of log messages, and so on have
to be added at this stage. And by compiling these files, class files
of NETCONF server will be generated. Then it is required to copy
these class files to the directory of Tomcat and to deploy the
NETCONF service. After that, NETCONF server will become accessible
from the NETCONF client.
4.2.3. Developing NETCONF server by C programming
When implementing NETCONF server on network equipment, memory
capacity might be limited and it might be unattainable to install
Java environment on network equipment. Or platform of network
equipment might not be the one which doesn't support Web service
tool. In that case, implementing SOAP engine as well as NETCONF
server on network equipment by C programming might be required. In
order to develop NETCONF server capable of receiving NETCONF message
which is sent over SOAP/HTTP, HTTP daemon and NETCONF daemon are
necessary to be implemented inside network equipment. A commonly
used HTTP daemon needs to be added with a SOAP engine and a connector
to NETCONF daemon. After HTTP daemon receives a SOAP message which
is sent over HTTP, the SOAP engine incorporated in the HTTP daemon
removes the SOAP Header and passes NETCONF messages on to NETCONF
daemon. Then, NETCONF daemon parses the NETCONF messages and
configure the network equipment accordingly.
Iijima, et al. Expires May 22, 2008 [Page 16]
Internet-Draft SOAP implementation November 2007
5. Security Considerations
Security should be considered from two angles. One is transport-
level security, and the other is message-level security. Transport-
level security, such as encryption of entire messages, is a matter of
SSL/TLS. However, message-level security, such as partial encryption
of messages or signatures, should be done by using other
technologies. To fulfill that need, WS-security has been defined.
WS-Security is a Web service technology and is dependent on SOAP
technology. WS-Security technology can be incorporated by inserting
XML encryption and XML signatures into the SOAP Header.
Also, WS-Reliability achieves confirmation of sent messages and
resending of messages. WS-Reliability is also achieved by inserting
particular messages into the SOAP Header.
Iijima, et al. Expires May 22, 2008 [Page 17]
Internet-Draft SOAP implementation November 2007
6. IANA Considerations
This document has no actions for IANA.
Iijima, et al. Expires May 22, 2008 [Page 18]
Internet-Draft SOAP implementation November 2007
7. References
7.1. Normative References
[1] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[2] Goddard, T., "Using NETCONF over the Simple Object Access
Protocol (SOAP)", RFC 4743, December 2006.
7.2. Informative References
[3] Bradner, S. , "Key words for use in RFCs to Indicate
Requirement Levels" , BCP 14 , RFC 2119 , March 1997 .
[4] Sperberg-McQueen, C. , Paoli, J. , and T. Bray , "XML 1.0
Recommendation" , World Wide Web Consortium FirstEdition REC-
xml-19980210 , February 1998 ,
<http://www.w3.org/TR/1998/REC-xml-19980210> .
[5] "Web Services - Axis" .
<http://ws.apache.org/axis/>
[6] "Web Service Description Language (WSDL) 1.1".
<http://www.w3.org/TR/wsdl/>
[7] "Apache Ant".
<http://ant.apache.org/>
[8] "Apache Tomcat".
<http://tomcat.apache.org/>
[9] "Eclipse".
<http://www.eclipse.org/>
[10] "NetBeans".
<http://www.netbeans.org/index.html>
[11] "Java SE".
<http://java.sun.com/javase/index.jsp>
Iijima, et al. Expires May 22, 2008 [Page 19]
Internet-Draft SOAP implementation November 2007
Authors' Addresses
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
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
Phone: +81-44-549-1735
Fax: +81-44-549-1272
Email: h-kimura@alaxala.net
Iijima, et al. Expires May 22, 2008 [Page 20]
Internet-Draft SOAP implementation November 2007
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
Central Research Laboratory, Hitachi, Ltd.
1-280 Higashi-Koigakubo
Kokubunji, Tokyo 185-8601
Japan
Phone: +81-42-323-1111
Fax: +81-42-327-7868
Email: hideki.okita.pf@hitachi.com
Iijima, et al. Expires May 22, 2008 [Page 21]
Internet-Draft SOAP implementation November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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.
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.
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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Iijima, et al. Expires May 22, 2008 [Page 22]
