ANExtArchitectureXOS 1685

Extreme Networks Application Note
The Extensible Architecture ExtremeXOS
Abstract: As XML (eXtensible Markup Language) standards have matured over time,
XML-based communication is becoming the standard way to manage network and server
elements, whether its physical or virtual elements.
The main advantages of XML are platform independence for both client and server and
an open communications architecture that allows for interoperability across point
solutions eliminating proprietary or closed environments. In addition, XML provides faster
development and quicker integration with management tools as compared to traditional
methods of SNMP or CLI. As developers and/or customers write code for network element
features, they can also define XML-based APIs (Application Programming Interfaces) for
specific features that can be integrated with their management systems. These APIs can
be made public so that third-party vendors can provide support for device features in their
management tools. ExtremeXOS XML API is a means to an open infrastructure.
In this Application Note we will discuss Extreme Networks approach to device
management in ExtremeXOS using XML APIs and the advantages associated with it.
Table of Contents
Introduction
A Comparison of Different Management Models
XML The Building Block for Extensibility
XML Element
XML Namespaces
XML Schema
Web Services Description Language (WSDL)
Data Type Definitions
Definitions of Messages
Definitions of Interfaces or portType
Definitions of Operations and Protocol Bindings
10
Definitions of Services
11
Simple Object Access Protocol (SOAP)
11
ExtremeXOS Architecture for Extensibility
17
Case Study: Retrieving Information About Identities from an ExtremeXOS Switch
19
soapUI Installation and Initial Setup
19
Creating/Opening a SOAP/XML Session with an Edge Switch
26
Retrieving Details of Active Users from Edge Switch
31
Conclusion
2010 Extreme Networks, Inc. All rights reserved.
37
The Extensible Architecture ExtremeXOSPage 2
Introduction
Extreme Networks was one of the pioneers in open
XML-based APIs (Application Programming Interfaces) to
manage networking elements at a time when the rest of
industry was using proprietary APIs to manage networking
elements. This proprietary strategy had the effect of locking
down customers to a single-vendor solution and depriving
them of open-architecture choices.
The main motivations for Extreme Networks and others to
adopt XML-based APIs are openness, object orientation,
flexibility and cost structure. XML is a standard to encode
and decode documents. The XML specification is produced
by the World Wide Web Consortium (W3C). The data
representation for XML is in standardized format and it is
available for anyone to access via the Internet.
One of the advantages of XML is its object-oriented nature,
and thus XML-based objects are self-describing. The object
orientation makes programming simpler to implement and
self-description eliminates the need to compile interface
control files for both client and server side. These attributes
make client/server programming easier to implement
and maintain.
In addition, XML Schema adds flexibility when new
subsystems are added, the client does not have to be
modified. Instead, an XML scheme file associated with the
new subsystems is simply added to the client.
Since there are open-source tools and libraries associated
with XML technology, along with ample manpower trained
to design and implement XML-based systems, the cost
structure associated with implementing XML based
technology can be optimized.
A Comparison of Different
Management Models
Prior to XML-based APIs, the traditional method for device
management was either through SNMP (Simple Network
Management Protocol), CLI (Command Line Interface) or
proprietary APIs. In this section we will address the
advantages of XML as compared to SNMP and CLI in
IP-based networks.
SNMP pioneered the traditional manager-agent method of
managing a network element using standard Management
Information Bases (MIBs). The main advantage of SNMP
was its simplicity, which had major appeal for its vast
adoption. However, even after undergoing three revisions,
SNMP in conjunction with Syslog has been at most a very
good monitoring tool. It suffers from a severe lack of
configuration capabilities. Other drawbacks of SNMP are in
application development complexity, time-lags in feature
releases, and lack of manageability which does not benefit
the end-user.
Therefore, coverage of SNMP has been restricted to

protocols, and development has failed to be fast enough to
support newer entities like virtual switches and routers. In
addition, SNMP is not scalable since it is based on a pull
technology. The excessive polling of information has the
potential to crash the network element.
This limitation of SNMP led to the proposal of various
standards distributed object technologies like CORBA
and Java RMI (Remote Method Invocation) for device
management. However, each of these technologies has its
own shortcomings and was not widely adopted like SNMP or
CLI. The CORBA approach has no agreed-upon framework
with respect to object models among various vendors. Java
RMI services cannot be discovered dynamically.
CLI is a good tool for configuration of network elements.
However, one of its main drawbacks has been the
proprietory nature of the tool. In order to configure
heterogeneous network elements in a given system, the
management station needs to know how to communicate
with each of the network elements and interpret the output
from their respective CLIs. Adding to the problem, each
vendor has their own preference or style of CLI. As one can
imagine, the CLI model doesnt easily scale to support
heterogeneous environments.
Given these limitations, what technology provides a better
solution for management of network elements in a heterogeneous environment? The answer is XML-based APIs. The
advantages associated with XML APIs are:
Standardized format for data representation
Data-driven system design using XML representation as
the extensible data model
XML schema to validate management transactions
XMLs high-level semantics allow efficiency in bulk
configuration management
XML Document Object Model (DOM) tree is extended
or updated based on the addition or modification of
features management on the network element without
much modification needed from either the client or the
network element
Availability of rich open-source tools (including libraries)
and techniques with XML technology
Client and server can run on different platforms such as
Windows, Linux or Solaris and can even be using different
programming languages such as C, C++, C# or Java
In conjunction with Web-based services like Web Service
Definition Language (WSDL) it is possible to have
dynamic discovery of services
These advantages help build an open infrastructure.
XML The Building Block

for Extensibility
XML uses plain-text (ASCII or Unicode) for information

exchange, which allows data to be moved freely between
all hardware and operating systems platform
The eXtensible Markup Language (XML) is designed with a

focus on representation, storage, and transport of data. This
design consideration is in stark contrast to the HyperText
Markup Language (HTML) which focuses on the display of
data alone. XML and HTML cannot be replaced by one
another, in that Web applications could use XML for data
representation, while HTML could still exist and provide a
method for format and display of data. XML is a platformindependent mechanism (both software and underlying
hardware technologies) for data representation and
transport. XML could also be viewed as a standards
specification for which other languages for custom purposes
could be designed.
XML can be used to architect or create new languages

for custom purposes. Some examples are:
Some of the relevant features of XML are:

Self-describing data: The elements (or most commonly
referred to as tags1) in XML are not predefined (as is the
case in HTML). Complex data types can be constructed
using the simple data types
RSS (Really Simple Syndication) for news feeds

XHTML (a new version of HTML)
WSDL (Web Services Description Language) for
defining Web services
XML Element
An element is the most basic entity of a document2. An
element is identified by a name (most commonly referred to
as a tag). An element contains a start or opening tag, end or
closing tag, and optionally one or more attributes. The
element contents (information), if any, are placed between
the start tag and the end tag. An element can contain other
elements. These concepts are exemplified in the XML
snippet below.
<object type=VlanConfig>
<name>authvlan</name>
<adminState>Enabled</adminState>
<tagValue>7</tagValue>
<tagType>802dot1Q</tagType>
<vlanTaggedPorts/>
<vlanUnTaggedPorts>13-20</vlanUnTaggedPorts>
<vlanTranslatedPorts/>
element
<ipv4ForwardingEnabled>false</ipv4ForwardingEnabled>
<primaryIpv4Address>
<ipAddress>192.168.100.1</ipAddress>
<netmask>24</netmask>
</primaryIpv4Address>
<protocol>ANY</protocol>
</object>
Figure 1
The element object contains a start tag <object>, child

elements such as name, adminState, tagValue, etc., and
is terminated by the end tag </object>
Type is an attribute of element object
802dot1Q is the content or value of the element tagType
XML Namespaces
We have noted that the self-describing nature of XML allows
application developers to define elements with custom
names. However, this could create conflicts when different
XML documents are to be merged from different XML-based
applications. Since element names are chosen by application
developers, there could be situations where elements from
two entirely different applications or services could have the
same name, yet have different contents and semantics.
1
The term tag is most commonly used in HTML. While both element and tag can be used interchangeably, the term element is used in this document.
2
The term document is used to denote a complete block of information returned by an application or service either in response to a request or unsolicited, and
conforms to an XML schema. The concept of XML schemas is discussed in subsequent sections.
Security Profile
UPM Profile
<profile>
<profile>
<name>Power off ports</name>
<name>Authorize Employees</name>
<data>poweroff_ports.upm</data>
<upmscript>corpvlan</upmscript>
<enabled>yes</enabled>
<enabled>yes</enabled>
</profile>
<creationTime>14:20:30
</creationTime>
</profile>
Figure 2
Figure 3
In the XML snippets above, a Universal Port Manager (UPM)

profile and a security profile are described. The former is a
description of a UPM script, while the latter describes the
actions to be taken when a user has to be authorized (in the
example above, a UPM profile called corpvlan needs to be
executed for authorization of employees). Note that the
contents of element profile and the semantics are very
different. If these two were to be merged and processed in an
application, the name profile would conflict.
XML parsers will need to distinguish between conflicting
element names, and process contents per the semantics of
each element. In order to solve this problem, XML provides
for namespaces, which is a method to avoid element name
conflicts. The namespace is defined using the xmlns attribute
in the start tag of an element.
Namespaces can either be defined as an attribute in the start

tag of an element, or as an attribute of the root element3.
For example:
<upm:profile xmlns:upm=http://www.extremenetworks.com/XMLSchema/xos/upm>
In the example shown above, the namespace upm is used
as a prefix when describing the element profile. The URI
http://www.extremenetworks.com/XMLSchema/xos/upm
provides the unique namespace for the prefix upm. We will
use unique namespaces for the UPM and security profiles,
and see how the merged content looks (see Figure 4).
<allprofiles
xmlns:upm=http://www.extremenetworks.com/XMLSchema/xos/upm
xmlns:nl=http://www.extremenetworks.com/XMLSchema/xos/netlogin
<upm:profile>
<upm:name>Power off ports</upm:name>
<upm:data>poweroff_ports.upm</upm:data>
<upm:enabled>yes</upm:enabled>
<upm:creationTime>14:20:30
</upm:creationTime>
</upm:profile>
<nl:profile>
<nl:name>Authorize Employees</nl:name>
<nl:upmscript>corpvlan</nl:upmscript>
<nl:enabled>0</nl:enabled>
</nl:profile>
</allprofiles>
Figure 4
3
A root element is the first element in an XML document.

The XML snippet exemplifies the following:
The root element <allprofiles> contains the namespace
attributes xmlns:upm, and xmlns:nl
It describes two profiles belonging to different XML
namespaces with prefixes upm and nl, Notice that all
the child elements of <upm:profile> are associated with
the same namespace upm. Similarly all child elements
of <nl:profile> are associated with the namespace
prefixed by nl.
XML Schemas
In the previous two sections we discussed elements and
namespaces and noted that the former is the most basic
entity in an XML document, and the latter provides for
methods to avoid name conflicts when processing elements
in an XML document. In reality, applications which process
XML content received from XML-based services will have to
deal with many types of elements, attributes of elements,
attribute values, various orders of elements (i.e. various
structures of XML documents), etc. Hence, a number of
questions arise while designing applications that work with
XML-based Web services.
In an XML document,
What is the order in which elements can appear,
attributes that they contain, and the attribute values?
What are the semantics of an element, or in other words,
what is the data type of an element?
What are the child elements that can appear within an
element, and the order in which they can appear?
We will again revisit the most salient design goal of XML: its
self-describing nature. XML provides for schemas which can
be used to describe the structure of an XML document. This
is most popularly referred to as XML Schema. A language to
define a schema is required, however many options exist
today for applications to use. Some of them are:
Document Type Definitions (DTD) is a set of markup
declarations that define a document type for languages
such as HTML, SGML, and also XML
Regular Language for XML Next Generation (RELAX
NG) is a schema language for XML and specifies a
pattern for the structure and content of an XML
document
XML Schema Document (XSD) is a widely used schema
language to define a set of rules and constraints to which
an XML document has to conform (in order to be
deemed as valid)
the semantics. Among the reasons for the wide adoption,

and also its use in ExtremeXOS XML services, are:
Schemas are expressed in XML itself, making it easy for
applications to use a common parser to parse both the
schema definition, and the contents of a document
They support namespaces and definition of data-types
Schemas are themselves extensible for future
enhancements
Before we proceed further, we will touch on the capability
of XSD to support definition of data-types. The ability to
define data-types allows application or service designers to
design custom elements that can be used to represent
information both efficiently and effectively. XSD supports
the following primitive or built-in data-types: Boolean,
string, decimal, double, float, anyURI, QName, hexBinary,
base64Binary, duration, date, time, dateTime, gYear,
gYearMonth, gMonth, gMonthDay, gDay, and NOTATION.
XSD also allows for definition of two kinds of elements:
Simple elements which cannot contain child elements or
attributes, and the contents can be one of the built-in
data-types or a custom data-type built using one of the
built-in data-types
Complex elements which can contain child elements,
and/or attributes
Web Services Description

Language (WSDL)
In this section we will discuss the methods by which
services can be delivered over a network (or the Internet)
using XML as the underlying mechanism for data representation. The previous section introduced basic concepts of
XML such as elements, namespaces, and concluded with a
discussion of the XML Schema definition language. While
XML can help in architecting the structure of information
exchanged between a client and a server, there is still a
need for defining what kind of operations or methods are
available in the service offered. For example, when management capabilities are offered in a switch or a router, then:
What is the location of a service offered by a device? Or
in other words, how can a client application access
this service?
What are the operations supported by the service? Or in
other words, are there methods to retrieve and modify
switch configuration?
How can these services be accessed? Is there a standard
protocol which both the client and the server should
adhere to?
In this document we will discuss the XSD language since it

is widely adopted, and used in ExtremeXOS XML-based
services to describe the structure of the XML content and

One of the important capabilities or features that were
mentioned briefly in the previous section was the ability to
create languages using XML for specific applications. The
Web Services Definition Language (WSDL) is an XML-based
language for describing Web services and the operations
that are supported. WSDL defines services as a collection of

network endpoints, or ports. A port is defined by a network
address with a binding. A collection of ports defines a
service. The concepts are illustrated in the diagram below.
Service
Binding
portType
Messages
Types
Network
Endpoints
OR
Ports
Operations
Transport
Protocol
Protocol
Binding Style
Operations
Supported by
the Interface
Messages
Used
Parts of
a Message
Associated
Data Types
Description
of Data Using
XML Schema
(Data Types,
Elements,
Attributes, etc.)
5419-01
Figure 5
Extreme Networks uses WSDL to describe the different

services offered by ExtremeXOS based switches. The WSDL
files are available in the ExtremeXOS InSite SDK for both
reference and integration with custom applications.
In the subsequent subsections, we will examine some

snippets from the switch.wsdl file that is available in the
ExtremeXOS InSite SDK to understand the structure of a
WSDL document.
A WSDL file or document contains the following information:
Data Type Definitions
Data types used by the Web services: < types>

Messages used by the Web services: <messages>
Operations that can be performed, and the messages
involved: <portType>
The format of messages, and the transport details:
<binding>
Services offered: <service>
The XML snippet shown below exemplifies the definitions of

data types using the <wsdl:types> element. The
<xsd:schema> element was described in the section XML
Schemas and is used here to indicate the structure and
semantics of the data types used in the Web service. The
element <xsd:import> indicates that this Web service
imports definitions of data-types, elements, attributes,
attribute values, etc. from the schema definitions found in
the location described by the attribute schemaLocation. In
this service, the imported schemas are switch.xsd and
common.xsd,
<wsdl:types>
<xsd:schema>
<xsd:import
namespace=http://www.extremenetworks.com/XMLSchema/
xos/switch
schemaLocation=./xsd/switch.xsd/>
<xsd:import
namespace=http://www.extremenetworks.com/XMLSchema/
xos/common
schemaLocation=./xsd/common.xsd/>
</xsd:schema>
</wsdl:types>
Figure 6
Definitions of Messages
contains an element of type switch:getRequest. In the
previous section, we imported XML schemas defined in
common.xsd and switch.xsd.
Figure 7 describes the different messages used by the

Web service.
The messages described using the <message> elements
contain child elements called <part>. The order in which
the parts appear in the message is the order in which they
are listed in the <message> element. In the above snippet,
the message getRequest is described as containing two
partsthe first part, called hdr contains an element of
type common:hdr, and the second part called body
The element type common:hdr comes from the

schema defined in common.xsd, and the prefix
common indicates the namespace.
The element type switch:getRequest comes from the
schema defined in switch.xsd, and the prefix switch
indicates the namespace.
<message name=getRequest>
<part name=hdr element=common:hdr/>
<part name=body element=switch:getRequest/>
</message>
<message name=getResponse>
<part name=body element=switch:getResponse/>
</message>
<message name=setRequest>
<part name=body element=switch:setRequest/>
</message>
<message name=setResponse>
<part name=body element=switch:setResponse/>
</message>
Figure 7
Definitions of Interfaces or portType

The XML snippet shown below captures two operations
get and setsupported by the interface switchPortType.
The choice of these two operations is to exemplify the use
of the messages getRequest, getResponse, setRequest,
and setResponse which we have discussed in the previous
section.
Notice that both the operations get and set require an
input message and this is indicated using the <input>
element. Both the operations output results use the
message described in the <output> element. For example,

the operation get requires an input from the client
application and the message type is getRequest. The
prefix tns indicates that the message getRequest
belongs to the namespace http://www.extremenetworks.
com/XMLSchema/xos/switch. The operation offered by the
service will return an output in a message format defined
getResponse.
<portType name=switchPortType>
<operation name=get>
<documentation>
Operation used to get data for objects from the switch. The type of
object to get and other options for the get operation are specified
as part of the <code>getRequest</code> message. This operation can
be used to get either a specific object or a set of objects of a
type.<br/> The data returned by this operation is contained in the
<code>getResponse</code> message.
</documentation>
<input message=tns:getRequest/>
<output message=tns:getResponse/>
</operation>
<operation name=set>
<documentation>
Operation used to set data for an object on the switch.
The type of object and values to set are specified as part of the
<code>setRequest</code> message.
</documentation>
<input message=tns:setRequest/>
<output message=tns:setResponse/>
</operation>
--- definitions of other operations --</portType>
Figure 8
<binding name=switchBinding type=tns:switchPortType>

<SOAP:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/>
<operation name=get>
<documentation>
This API returns the complete switch object.
</documentation>
<SOAP:operation/>
<input>
<SOAP:header message=tns:getRequest part=hdr use=literal/>
<SOAP:body parts=body use=literal/>
</input>
<output>
<SOAP:header message=tns:getResponse part=hdr use=literal/>
<SOAP:body parts=body use=literal/>
</output>
</operation>
--- definitions of more operations --</binding>
Figure 9
Definitions of Operations and

Protocol Bindings
In the introduction of this section, we noted that the
message formats and the transport protocol details are
required in order for a client application to use the Web
services. The <binding> element in the WSDL document
provides these descriptions, and is shown in the XML
snippet in Figure 9.
The <binding> element has two attributesname which
can contain any value (in this case switchBinding) and
is used to refer this binding, and type (in this case
switchPortType) which refers to the portType or the
interface for the binding. The previous section discussed
the interface switchPortType and examined some of the
operations that were supported by the interface.
In the XML fragments above, one can notice the use of a
term SOAP within the <binding> element. We noted
earlier that a protocol is required for accessing a Web
service. The Simple Object Access Protocol or SOAP is one
such protocol which is an XML-based protocol to let
applications exchange information. SOAP is discussed in
detail in the next chapter; for now we will assume that
SOAP provides for a platform-independent method to

communicate between applications. The <SOAP:binding>
element has two attributesstyle which can be RPC
(Remote Procedure Call) but in this case is document,
and a transport attribute that defines the transport
protocol to use (in this case http).
The <operation> element defines the operations the
network endpoint or the port provide, with the details of
the input and output messages involved in the operation. In
the XML snippet above, the operation get:
Requires an input message in the following format: A
SOAP header containing message of type getRequest
with the hdr part (based on the element definition
common:hdr in common.xsd). This is followed by a
SOAP body.
Produces an output to the client in the following format:
A SOAP header containing message of type
getResponse, following by a SOAP body.
We had examined the message types getRequest and
getResponse in the section Definitions of Messages.
Definitions of Services
The definition of the services offered by the device or
application is the last block in a WSDL document. The XML
snippet below from switch.wsdl describes a network
endpoint switchPort offered by the XML-based Web
services offered by ExtremeXOS switches.
The <service> element contains an attribute name which

identifies the service. The <port> element contains the
following attributes: name which identifies the endpoint,
and binding which indicates the binding definition to use.
The child element <SOAP:address> defines the location of
the service.
<service name=switch>
<port name=switchPort binding=tns:switchBinding>
<SOAP:address location=http://localhost/xapi/>
</port>
</service>
Figure 10
Simple Object Access Protocol

(SOAP)
SOAP is an XML-based protocol designed for communication between applications. In the context of this document,
SOAP is a protocol used for custom enterprise applications,
such as Extreme Networks EPICenter network management system which can access Web services offered by
ExtremeXOS based switches. The underlying transport that
SOAP uses could be either RPC or HTTP. RPC is certainly a
choice and well-adapted for communication between
objects in applications built using DCOM or CORBA
technologies; however, it presents not only a compatibility
problem but also a security risk and administrators tend to
block this kind of traffic. Given the wide adoption and use of
SOAP
Message
HTTP (as a transport protocol) and XML (as content

definition), it is not surprising that SOAP (which is also
XML-based) is one of the best choices for accessing services
offered by a device or application in the network.
A discussion of the complete SOAP protocol itself is beyond
the scope of this document; however, we will discuss some
of the building blocks that make up a SOAP message in
order to correlate with content to be sent and received to/
from a Web service. The diagram below shows the different
elements of a SOAP message and their purpose.
Envelope
A mandatory element, and identifies the

XML document as a SOAP message
Header
Optional element, and contains

application-specific information such
authentication, session identifiers, etc.
Body
Mandatory element in SOAP message, and

contains information exchanged between the
client and the Web services offered by the port
Fault
An optional fault element, and appears as a

child element of the body, and once per a
SOAP message
5420-01
Figure 11

The SOAP message shown below is a request sent from an
application to retrieve configurations of all VLANs in an
ExtremeXOS based switch.
In the SOAP message shown below:
<soapenv:Envelope> is the first and the root element.
The fragment identifies that this XML document is a
SOAP message.
The element <ns1:hdr> inherits the definition of the

data-type clientHeader defined in the XML Schema
definition common.xsd. sessionId is a unique session
identifier returned by the Web service switch running
in the ExtremeXOS switch. Client applications are
required to use the openSession interface to start a Web
services session with the ExtremeXOS switch. Sessions
can be terminated with Web services on ExtremeXOS
switches using the closeSession interface.
The element <soapenv:Header> contains a child element

<ns1:hdr> and the prefix ns1 indicates the association
with namespace http://www.extremenetworks.com/
XMLSchema/xos/common,
<?xml version=1.0 encoding=UTF-8?>

<soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<soapenv:Header>
<ns1:hdr
xmlns:ns1=http://www.extremenetworks.com/XMLSchema/xos/common>
<sessionId>20af000000002a</sessionId>
<extension/>
</ns1:hdr>
</soapenv:Header>
<soapenv:Body>
<getRequest action=next maxSize=200
xmlns=http://www.extremenetworks.com/XMLSchema/xos/switch>
<filter xsi:type=ns2:VlanConfig
xmlns=
xmlns:ns2=http://www.extremenetworks.com/XMLSchema/xos/vlan/>
<hdr xmlns=>
<sessionId>20af000000002a</sessionId>
<extension/>
</hdr>
</getRequest>
</soapenv:Body>
</soapenv:Envelope>
Figure 12

The element <soapenv:Body> contains a specific request
from the client to return the configurations of all the VLANs
in the switch. The operation getRequest is used by the
client application to request the switch, and element
<filter> to specify that only VLAN configurations are being
requested in this SOAP message.
Screenshot 1 (Figure 13): A client application uses the

openSessionRequest interface to start a Web services
session with the ExtremeXOS switch. The location
http://<ip-address-of-switch>/xmlServices is the service
location and is used in the transport protocol HTTP.
The next few screenshots of packet captures will illustrate

the usage of HTTP as the transport protocol which contains
the SOAP messages which we have discussed in this section.
Figure 13

Screenshot 2 (Figure 14): The Web service in the ExtremeXOS switch responds to the client application with a
SOAP message containing openSessionReply and returns a
unique session identifier. This session identifier is to be

used by the client application for further transactions.
Figure 14

Screenshot 3 (Figure 15): The client application requests configurations of all VLANs in the ExtremeXOS switch using the
getRequest interface.
Figure 15

Screenshots 4 (Figure 16) and 5 (Figure 17): ExtremeXOS switch responds to the client application with all the VLAN
configurations using the getResponse message in the SOAP body.
Figure 16

This screenshot is a continuation of the previous one and shows the rest of the configuration of VLAN authvlan.
Figure 17
ExtremeXOS Architecture
for Extensibility
The components of XML, WSDL, and SOAP form the
building blocks on which ExtremeXOS provides the
extensibility framework. A layered view (of data representation, message envelope, and the transport layer) summarizes the Web services framework offered by ExtremeXOS
based switches.
The extensibility framework provides for:

Better visibility of events within the infrastructure
Better manageability to enable granular control within
the infrastructure
The network to become a part of a service oriented model
where the network can be tightly (and most importantly,
easily) integrated with business applications
HyperText Transport Protocol

(HTTP)
Message Transport Layer
Simple Object Access Protocol

(SOAP)
Message Envelope Layer
Web Services Description Language

(WSDL)
eXtensible Markup Language

(XML)
API Layer
Data Representation
Figure 19 shows the ExtremeXOS architecture for configuration management and integration with both internal and
external custom applications. ExtremeXOS Configuration
Manager, which is at the core between different management interfaces and internal ExtremeXOS processes and
services, handles XML natively. This not only allows
ExtremeXOS services to easily provide XML-based APIs,
but also allows custom in-switch applications to use the
open communication framework.
5421-01
Figure 18
External
Business
Applications
XML Client
In-Switch
Custom
Applications
Web
(HTTP/S Server)
SSH/Telenet
SNMP
Stack
gSoap Server
CLI
SNMP
Agent
XML
APIs
XML Server
ExtremeXOS Configuration Manager
ExtremeXOS Core Processes & Services
5422-01
Figure 19
The XML server shown above is responsible for providing a

gateway between the external interface and the switch
modules. It securely wraps, unwraps, and validates messages; and performs the mechanical translations of results
from the modules to the client machine. In order to
configure an ExtremeXOS switch using the XML API, the
client will have to authenticate with the switch before any
XML requests will be accepted. The extensibility framework
uses the same credentials (user name and password) as in
the CLI or HTTP interface. The same user privilege (admin
user or regular user) will be applied to the configuration
requests handled via the XML interface.
The XML Client process is responsible for publishing
application-specific information to external Web-based
applications (such as EPICenter, or other custom
enterprise applications).
An XML processor (used by both XML client and server)

contains a parser library and XML API handlers. The parser
performs the marshalling or de-marshalling functions that
serialize or de-serialize application-specific structures.
Additionally, a mechanism is available to use the APIs by
sending XML messages over an SSH or telnet session. Once
an SSH or telnet connection is established with the switch,
the client must first set the session to XML mode before
using the XML APIs by sending the enable xml-mode CLI
command to the switch. This mechanism is provided for
management applications that use Netconf.
A complete reference of all the data types, elements,
attributes, operations and services are provided in
ExtremeXOS InSite Software Development Kit available at
http://extremenetworks.com/solutions/Insite.aspx.
Case Study: Retrieving Information about

Identities from an ExtremeXOS Switch
In this section, we will explore the method by which an
application can poll (if required periodically) an ExtremeXOS
based switch for retrieving identities tracked in the network.
The edge switch will act as a server. We will use a tool called
soapUI, which, amongst a host of other features, provides a
very easy method to inspect and test WSDL based Web
services. The procedures and description provided in this
section is intended to provide an overview of how to establish
a SOAP/XML session with an ExtremeXOS switch and
retrieve information.
NOTES
This case study uses soapUI Version 3.5.
It is recommended to have a copy of the ExtremeXOS
InSite SDK in the host on which soapUI is planned to be
installed. This case study uses the ExtremeXOS InSite SDK
Release 12.4.1.7 available at http://www.extremenetworks.com/solutions/Insite.aspx.
The rest of this section will explain the steps to install soapUI
on a host. Open the soapUI installer program and follow the
steps given after each screenshot to complete the installation
process.
soapUI Installation and Initial Setup

Information about soapUI is available at http://www.soapui.
org. Please refer to the download instructions provided at the
Web site.
Steps: Click Next.
Steps: Check I accept the agreement Click Next.
Steps: Specify the program installation location Click Next.
Steps: Accept all the default set of components that are selected for installation Click Next.
Steps: Check I accept the agreement Click Next.
Steps: Click Next.
Steps: Ensure that options are selected as shown above Click Finish to complete the installation process.
Steps: When soapUI program starts, Right Click on the Default Workspace Click New soapUI Project.
Steps: Enter the project name as shown or choose a custom project name Click Ok.
Steps: Right Click on the project created Click Add WSDL.
Steps: Click Browse to locate the WSDL files provided by the ExtremeXOS InSite SDK.
Steps: Select switch.wsdl from the list of WSDL files provided in the ExtremeXOS InSite SDK Click Open.
Steps: Ensure that all the options are selected as shown Click Ok.

Creating/Opening a SOAP/XML Session with an Edge Switch
Steps: Expand switchBinding under the project Expand openSession Double Click on Request 1.

Replace the contents of the request with the SOAP envelope provided below.
<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:com=http://
www.extremenetworks.com/XMLSchema/xos/common>
<soapenv:Header/>
<soapenv:Body>
<com:openSessionRequest>

<session com:operation=merge>

<appName></appName>

<username>admin</username>

<password></password>

<xmlApiVersion></xmlApiVersion>

<sessionId></sessionId>

<timeout></timeout>

<accessRight></accessRight>

<extension>

</extension>

</session>
</com:openSessionRequest>
</soapenv:Body>
</soapenv:Envelope>
Steps: Click on the location bar Click [edit current].
Steps: Enter the URL as https://<switch-management-ipaddress>/xmlServices Click Ok.
NOTES
Notice the use of https instead of http to secure information exchange between the edge switch and the application
The edge switch has already been configured to enable the Web server (Refer Section Error! Reference source not found. Error!
Reference source not found.)
Steps: Click Submit request to specified endpoint URL.

The edge switch now responds with a SOAP message containing a SessionID which can be used for 900 seconds (15 minutes).
Subsequent requests to the edge switch will have to use the SessionID returned by the edge switch.

Retrieving Details of Active Users from Edge Switch
In this section, we will format a request to retrieve the current set of active users being tracked by the edge switch.
Steps: Expand the get method Replace the request to retrieve the list of active users with content provided below.
NOTES
It is important to replace the value of the sessionId tag with the value recorded earlier when the edge switch responded to the
openSession request.
Format for the request for a list of current active users:

<soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:com=http://www.extremenetworks.com/XMLSchema/xos/common
xmlns:swit=http://www.extremenetworks.com/XMLSchema/xos/switch>
<soapenv:Header>
<ns1:hdr xmlns:ns1=http://www.extremenetworks.com/XMLSchema/xos/common>
<reqId>1</reqId>
<sessionId>20af0000000019</sessionId>
</ns1:hdr>
</soapenv:Header>
<soapenv:Body>
<getRequest maxSize=0
xmlns=http://www.extremenetworks.com/XMLSchema/xos/switch>
<filter xsi:type=ns2:UserIdentityData xmlns=
xmlns:ns2=http://www.extremenetworks.com/XMLSchema/xos/idmgr>
<datasetType>active</datasetType>
</filter>
</getRequest>
</soapenv:Body>
</soapenv:Envelope>

The edge switch now responds with the list of active users being tracked.
SOAP response from the edge switch:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:ns1=http://www.extremenetworks.com/XMLSchema/xos/l2protocol
xmlns:xos=urn:xapi
xmlns:vlan=http://www.extremenetworks.com/XMLSchema/xos/vlan
xmlns:idmgr=http://www.extremenetworks.com/XMLSchema/xos/idmgr
xmlns:port=http://www.extremenetworks.com/XMLSchema/xos/port
xmlns:fdb=http://www.extremenetworks.com/XMLSchema/xos/fdb
xmlns:ns2=http://www.extremenetworks.com/XMLSchema/xos/dhcp
xmlns:ems=http://www.extremenetworks.com/XMLSchema/xos/ems
xmlns:aaa=http://www.extremenetworks.com/XMLSchema/xos/aaa
xmlns:snmp=http://www.extremenetworks.com/XMLSchema/xos/snmp
xmlns:system=http://www.extremenetworks.com/XMLSchema/xos/system
xmlns:event=http://www.extremenetworks.com/XMLSchema/xos/event
xmlns:ns4=urn:ietf:params:xml:ns:netconf:soap:1.0
xmlns:netb=urn:ietf:params:xml:ns:netconf:base:1.0
xmlns:switch=http://www.extremenetworks.com/XMLSchema/xos/switch
xmlns:com=http://www.extremenetworks.com/XMLSchema/xos/common
xmlns:upm=http://www.extremenetworks.com/XMLSchema/xos/upm
xmlns:xosacl=urn:xapi/l2protocol/acl xmlns:xoscfg=urn:xapi/cfgmgmt/cfgmgr
xmlns:xosfdb=urn:xapi/l2protocol/fdb xmlns:xospol=urn:xapi/system/policy
xmlns:xosvlan=urn:xapi/l2protocol/vlan>
<SOAP-ENV:Header>
<com:hdr>

<reqId>1</reqId>
<sessionId>20af0000000074</sessionId>
</com:hdr>
<event:eventHeader/>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<switch:getResponse>
<objects>
<object xsi:type=ns2:UserIdentityData>
<userName>bob _ stone</userName>
<domain>PRIMECORP</domain>
<portList>14</portList>
<modificationTimestamp>1269525859532</modificationTimestamp>
<eventType>na</eventType>
<authProtocolsUsed>netloginDot1x</authProtocolsUsed>
<numOfLocations>1</numOfLocations>
<creationTimestamp>1269525822399</creationTimestamp>
<location>
<port>14</port>
<portDisplayString/>
<macAddress>00:11:43:4c:90:6f</macAddress>
<lldpCapabilityInfo>0</lldpCapabilityInfo>
<netBiosHostName/>
<kerberosSnooping>false</kerberosSnooping>
<authMethod>netloginDot1x</authMethod>
<securityProfile/>
<securityViolations/>
<logonStatus>loggedOn</logonStatus>
<logonTime>1269525822389</logonTime>
<logOutTime>0</logOutTime>
<authFailTime>0</authFailTime>
<vlanInfo>
<vlan>
<name>corp</name>
</vlan>
</vlanInfo>
</location>
</object>
<userName>bob _ stone</userName>
<domain>PRIMECORP.COM</domain>
<authProtocolsUsed>none</authProtocolsUsed>
<location>
<port>14</port>
<macAddress>00:11:43:4c:90:6f</macAddress>
<netBiosHostName>LAPTOP2</netBiosHostName>
<kerberosSnooping>true</kerberosSnooping>

<authMethod>na</authMethod>
<securityProfile/>
<vlanInfo>
<vlan>
<name>corp</name>
</vlan>
</vlanInfo>
</location>
</object>
<userName>john _ smith</userName>
<domain>PRIMECORP</domain>
<authProtocolsUsed>netloginDot1x</authProtocolsUsed>
<location>
<port>13</port>
<macAddress>00:0d:88:68:8f:cc</macAddress>
<netBiosHostName/>
<kerberosSnooping>false</kerberosSnooping>
<authMethod>netloginDot1x</authMethod>
<securityProfile/>
<vlanInfo>
<vlan>
<name>corp</name>
</vlan>
</vlanInfo>
</location>
</object>
<userName>john _ smith</userName>
<domain>PRIMECORP.COM</domain>
<authProtocolsUsed>none</authProtocolsUsed>

<location>
<port>13</port>
<macAddress>00:0d:88:68:8f:cc</macAddress>
<netBiosHostName>WORKSTATION1</netBiosHostName>
<kerberosSnooping>true</kerberosSnooping>
<authMethod>na</authMethod>
<securityProfile/>
<vlanInfo>
<vlan>
<name>corp</name>
</vlan>
</vlanInfo>
</location>
</object>
</objects>
</switch:getResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Conclusion
ExtremeXOS provides an open communications architecture that allows for interoperability across point solutions eliminating
proprietary or closed environments. ExtremeXOS XML-based APIs helps simplify the management of network elements in
terms of configuration, ease of deployment and standardization. Following the pioneering lead of Extreme Networks, today
the networking industry actively supports XML-based APIs to support an open, yet secured infrastructure.
www.extremenetworks.com
Corporate
and North America
Extreme Networks, Inc.
3585 Monroe Street
Santa Clara, CA 95051 USA
Phone +1 408 579 2800
Europe, Middle East, Africa

and South America
Phone +31 30 800 5100
Asia Pacific
Phone +65 6836 5437
Japan
Phone +81 3 5842 4011
2010 Extreme Networks, Inc. All rights reserved. Extreme Networks, the Extreme Networks logo, EPICenter and ExtremeXOS are either registered trademarks or trademarks
of Extreme Networks, Inc. in the United States and/or other countries. Specifications are subject to change without notice. 1685_02 05/10

ANExtArchitectureXOS 1685

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ANExtArchitectureXOS 1685

Încărcat de

Drepturi de autor:

Formate disponibile

Extreme Networks Application Note

The Extensible Architecture ExtremeXOS

Extreme Networks Application Note

A Comparison of Different Management Models

XML The Building Block for Extensibility

Web Services Description Language (WSDL)

Data Type Definitions

Definitions of Interfaces or portType

Definitions of Operations and Protocol Bindings

Simple Object Access Protocol (SOAP)

ExtremeXOS Architecture for Extensibility

Case Study: Retrieving Information About Identities from an ExtremeXOS Switch

soapUI Installation and Initial Setup

Creating/Opening a SOAP/XML Session with an Edge Switch

Retrieving Details of Active Users from Edge Switch

2010 Extreme Networks, Inc. All rights reserved.

The Extensible Architecture ExtremeXOSPage 2

Extreme Networks Application Note

2010 Extreme Networks, Inc. All rights reserved.

Therefore, coverage of SNMP has been restricted to

The Extensible Architecture ExtremeXOSPage 3

Extreme Networks Application Note

XML The Building Block

XML uses plain-text (ASCII or Unicode) for information

The eXtensible Markup Language (XML) is designed with a

XML can be used to architect or create new languages

Some of the relevant features of XML are:

RSS (Really Simple Syndication) for news feeds

The element object contains a start tag <object>, child

2010 Extreme Networks, Inc. All rights reserved.

The Extensible Architecture ExtremeXOSPage 4

Extreme Networks Application Note

In the XML snippets above, a Universal Port Manager (UPM)

Namespaces can either be defined as an attribute in the start

A root element is the first element in an XML document.

2010 Extreme Networks, Inc. All rights reserved.

The Extensible Architecture ExtremeXOSPage 5

Extreme Networks Application Note

the semantics. Among the reasons for the wide adoption,

Web Services Description

In this document we will discuss the XSD language since it

2010 Extreme Networks, Inc. All rights reserved.

The Extensible Architecture ExtremeXOSPage 6

Extreme Networks Application Note

that are supported. WSDL defines services as a collection of

Extreme Networks uses WSDL to describe the different

In the subsequent subsections, we will examine some

A WSDL file or document contains the following information:

Data Type Definitions

Data types used by the Web services: < types>

The XML snippet shown below exemplifies the definitions of

The Extensible Architecture ExtremeXOSPage 7

Extreme Networks Application Note

Figure 7 describes the different messages used by the

The element type common:hdr comes from the

<part name=hdr element=common:hdr/>

<part name=body element=switch:getRequest/>

<part name=hdr element=common:hdr/>

<part name=body element=switch:getResponse/>

<part name=hdr element=common:hdr/>

<part name=body element=switch:setRequest/>

<part name=hdr element=common:hdr/>

<part name=body element=switch:setResponse/>