U.S. patent application number 14/330846 was filed with the patent office on 2014-12-25 for method and apparatus for using a command design pattern to access and configure network elements.
This patent application is currently assigned to ROCKSTAR CONSORTIUM US LP. The applicant listed for this patent is ROCKSTAR CONSORTIUM US LP. Invention is credited to Robert J. Duncan, Tal I. Lavian, Olivier K. Swedor.
Application Number | 20140379784 14/330846 |
Document ID | / |
Family ID | 51135805 |
Filed Date | 2014-12-25 |
United States Patent
Application |
20140379784 |
Kind Code |
A1 |
Swedor; Olivier K. ; et
al. |
December 25, 2014 |
METHOD AND APPARATUS FOR USING A COMMAND DESIGN PATTERN TO ACCESS
AND CONFIGURE NETWORK ELEMENTS
Abstract
An XML accessible network device is capable of performing
functions in response to an XML encoded request transmitted over a
network. It includes a network data transfer service, coupled to a
network, that is capable of receiving XML encoded requests from a
client also connected to the network. A service engine is capable
of understanding and parsing the XML encoded requests according to
a corresponding DTD. The service engine further instantiates a
service using parameters provided in the XML encoded request and
launches the service for execution on the network device in
accordance with a command design parameter. A set of device APIs
interacts with hardware and software on the network device for
executing the requested service on the network device. If
necessary, a response is further collected from the device and
provided to the client in a response message.
Inventors: |
Swedor; Olivier K.; (Zurich,
CH) ; Lavian; Tal I.; (Sunnyvale, CA) ;
Duncan; Robert J.; (San Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
ROCKSTAR CONSORTIUM US LP |
Plano |
TX |
US |
|
|
Assignee: |
ROCKSTAR CONSORTIUM US LP
Plano
TX
|
Family ID: |
51135805 |
Appl. No.: |
14/330846 |
Filed: |
July 14, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09726758 |
Nov 29, 2000 |
8782230 |
|
|
14330846 |
|
|
|
|
60213107 |
Jun 21, 2000 |
|
|
|
Current U.S.
Class: |
709/203 |
Current CPC
Class: |
H04L 67/02 20130101;
H04L 41/0266 20130101; H04L 41/0806 20130101; G06F 40/14
20200101 |
Class at
Publication: |
709/203 |
International
Class: |
H04L 29/08 20060101
H04L029/08; G06F 17/22 20060101 G06F017/22 |
Claims
1. A method of causing a network device to perform a service at the
network device, the method comprising: sending a service request
from a requesting client to the network device, the service request
comprising a request identifier and a markup language document, the
markup language document identifying a document type definition;
and at the network device: receiving the service request;
retrieving the document type definition identified by the markup
language document; parsing the service request using the retrieved
document type definition; determining whether an object
corresponding to the service has already been instantiated; and
when no object corresponding to the service has already been
instantiated, instantiating an object corresponding to the service,
and calling an operate method of the instantiated object to launch
the service.
2. The method of claim 1, wherein the markup language document
comprises parameter values and parsing the service request
comprises extracting parameter values from the markup language
document.
3. The method of claim 2, wherein the parameter values comprise
class, source and identifier parameter values.
4. The method of claim 3, wherein the identifier parameter value
indicates the document type definition.
5. The method of claim 3, wherein the class parameter value
indicates a service class.
6. The method of claim 5, wherein instantiating the object
corresponding to the service comprises instantiating the object
based on the service class.
7. The method of claim 6, wherein the operate method is
instantiated by each of a plurality of service classes.
8. The method of claim 6, wherein instantiating the object based on
the service class comprises identifying a byte code for the service
based on the class parameter value.
9. The method of claim 1, wherein the markup language document
comprises tags, at least some of the tags being defined by the
document type definition.
10. The method of claim 9, comprising generating events for each
tag in the markup language document which is defined by the
document type definition.
11. The method of claim 1, comprising keeping track of services
that require responses.
12. The method of claim 11, comprising, at the network device:
receiving response messages associated with services; formatting
response messages for transmission to clients requesting the
services; and transmitting the response messages to the clients
requesting the services.
13. The method of claim 12, comprising, at the network device, for
services requiring multiple responses, receiving multiple responses
and correlating the multiple responses for the requesting
client.
14. The method of claim 1, wherein the service is associated with
an HTTP server.
15. The method of claim 1, wherein the markup language comprises
XML.
16. The method of claim 15, wherein the document type definition
comprises an XML DTD.
17. The method of claim 1, wherein the service configures a packet
forwarding architecture in the network device.
18. The method of claim 17, wherein the service causes changes in
packet forwarding behavior at the network device.
19. The method of claim 18, wherein the service filters packets at
the network device.
20. The method of claim 1, wherein the service monitors packet
forwarding at the network device.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is based on, and claims priority
from U.S. Provisional Appln. No. 60/213,107, filed Jun. 21, 2000.
The present application is also related to co-pending U.S.
application Ser. No. ______ (NOR-12520BA) and co-pending U.S.
application Ser. No. ______ (NOR-12675HU), both commonly owned by
the assignee of the present application.
FIELD OF THE INVENTION
[0002] The present invention relates to network device
configuration and monitoring, and more particularly, to a method
and apparatus for accessing, configuring and controlling a device
stationed on a network using a command design pattern and documents
written in a markup language such as XML.
BACKGROUND OF THE INVENTION
[0003] Computer networks continue to proliferate. As they do so,
they become increasingly complex and difficult to manage. This
problem is exacerbated when a variety of network devices,
computers, and software are combined together to integrate large
intranets with the Internet.
[0004] As shown in FIG. 1, when a client 100 wants to learn
information regarding a remote network device 104 stationed on a
network 102, code executing on client 100 formats a message
requesting such information and sends it to the network device 104.
Network device 104 must be preprogrammed with functionality for
communicating in the protocol required by client 100's message and
for knowing exactly how to get the information requested. If so,
network device 104 can then respond with the requested
information.
[0005] Simple network management protocol (SNMP) is one example of
a network protocol that allows clients to learn information about
remote network devices. SNMP allows network devices 104 to send
alerts to a manager 102, or to send statistical information about
traffic, but it limits the kind of information that can be sent to
that which is pre-defined in the management information blocks
(MIBs) coded into the network device. Accordingly, a new MIB needs
to be redefined each time a new type of information is maintained
or is needed about the device, thus making network management and
performance even more problematic.
SUMMARY OF THE INVENTION
[0006] The present invention relates to an apparatus and method for
more efficiently accessing, configuring and controlling a network
device using a common design pattern and documents written in a
markup language such as the Extensible Markup Language (XML).
[0007] In accordance with one aspect of the invention, an XML
accessible network device is capable of performing functions in
response to an XML encoded request transmitted over a network. It
includes a network data transfer service, coupled to a network,
that is capable of receiving XML encoded requests from a client
also connected to the network. A service engine is capable of
understanding and parsing the XML encoded requests according to a
corresponding document type definition (DTD). The service engine
further instantiates a service using parameters provided in the XML
encoded request and launches the service for execution on the
network device using a command design parameter. A set of device
APIs interacts with hardware and software on the network device for
executing the requested service on the network device. If necessary
or desired, a response is further collected from the device and
provided to the client in a response message.
[0008] In accordance with another aspect of the invention, a method
for causing a network device to locally perform a service comprises
the steps of receiving at the network device a document written in
accordance with a markup language and a corresponding document
definition, parsing by the network device the received document in
accordance with the corresponding document definition, and
executing the service on the network device in accordance with the
parsed document and a command design parameter.
[0009] In accordance with a further aspect of the invention, a
network device for locally perform a service in response to a
remote request comprises means for receiving at the network device
a document written in accordance with a markup language and a
corresponding document definition, means for parsing by the network
device the received document in accordance with the corresponding
document definition, and means for executing the service on the
network device in accordance with the parsed document and a command
design parameter.
[0010] In accordance with a further aspect of the invention, a
network device for locally performing a service in accordance with
a received document written in a document markup language comprises
a parser that is adapted to parse the received document in
accordance with a document definition, a service engine coupled to
the parser that is adapted to instantiate an object corresponding
to the service in accordance with the parsed received document, and
to execute the service in accordance with the instantiated object
and a command design parameter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] The foregoing and other features, aspects, and advantages of
the present invention will become more apparent from the following
detailed description when read in conjunction with the following
drawings, wherein:
[0012] FIG. 1 illustrates a conventional architecture for
accessing, configuring and controlling a network device using
standard network protocols;
[0013] FIG. 2 is a functional overview of an apparatus for
accessing, configuring and controlling a network device using XML
encoded data and a command design parameter in accordance with the
present invention;
[0014] FIG. 3 further illustrates an example of a network device
that is configured in accordance with the present invention;
[0015] FIG. 4 further illustrates a service engine that can be
included in a network device according to the invention such as
that illustrated in FIG. 3;
[0016] FIG. 5 is an architectural view of a network device that is
configured in accordance with the present invention;
[0017] FIG. 6 is an example implementation of a network device in
accordance with the invention and the architecture depicted in FIG.
5; and
[0018] FIG. 7 illustrates a process for accessing, configuring and
controlling a network device using XML encoded data in accordance
with the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0019] The present invention will now be described in detail with
reference to the accompanying drawings, which are provided as
illustrative examples of preferred embodiments of the present
invention. Notably, the implementation of certain elements of the
present invention may be accomplished using software, hardware or
any combination thereof, as would be apparent to those of ordinary
skill in the art, and the figures and examples below are not meant
to limit the scope of the present invention. Moreover, where
certain elements of the present invention can be partially or fully
implemented using known components, only those portions of such
known components that are necessary for an understanding of the
present invention will be described, and detailed descriptions of
other portions of such known components will be omitted so as not
to obscure the invention. Further, the present invention
encompasses present and future known equivalents to the known
components referred to herein by way of illustration.
[0020] FIG. 2 is a functional overview of one embodiment of the
present invention. As shown, a client 100' is connected in the
conventional manner to a network such as the Internet or an
intranet (i.e. LAN/WAN/MAN) 102, which in turn is connected to a
network device 104' (e.g. router, switch, hub or similar device
capable of processing fixed-length or variable-length packets in a
network). It should be noted that although the features and
advantages of the present invention are particularly well suited to
routers, switches and hubs, and will be described in more detail
below with reference to such devices, other network-aware devices
can be adapted for use in the present invention, and so the
invention is not to be limited to these particular illustrative
devices. For example, network device 104' may also include
gateways, multiplexers and other known or future equivalents,
including those having a packet forwarding architecture.
[0021] As is apparent from FIG. 2, in contrast with the prior art,
the present invention provides communications for accessing and
configuring network elements using XML documents and a common
design pattern. As is known, XML is a metalanguage built upon the
Standard Generalized Markup Language (SGML), and is a tool for
defining text markup languages, defined by the World Wide Web
Consortium (W3C). An XML-defined language comprises a set of tags,
attributes, and constraints on how to use them. XML is a simple,
open, portable, extensible means of representing data. Unlike HTML,
XML tags tell what the data means, instead of just how to display
it. Further information regarding XML can be found from the W3C web
pages at http://www.w3.org/XML.
[0022] Those skilled in the art, after being taught by the present
disclosure, will appreciate that there are many flavors of XML and
SGML and that many markup languages are equivalent to XML for
adaptation and implementation according to the present invention.
XML is described in detail in this application because of its wide
acceptance and adoption. However, equivalents to XML that are
within the scope of the invention can include, for example, XSL,
XSLT, XPath, XLink, XPointer, HyTime, DSSSL, CSS, SPDL, CGM,
ISO-HTML, and others.
[0023] As is further known, the format of an XML document is
defined by a Document Type Definition (DTD). Accordingly, the
present invention includes local copies of DTD 202 at the sending
and receiving ends of the XML document. There can be just one DTD
202 that defines all communications for all applications, or there
may be different DTDs 202 for different types of applications, and
those skilled in the art will understand the possible variations.
Further, there are many ways known in the art that such local
copies of DTD 202 can be retrieved and obtained by network device
104', and the details thereof will not be presented so as not to
obscure the invention.
[0024] Generally, when the client computer 100' wants to access or
configure network device 104' (i.e., cause network device 104' to
perform a service locally on the network device 104'), it creates
an XML request identifying the service to be performed, which XML
document is encoded in the format defined by DTD 202 but with
parameters specific to the desired access or configuration. Client
100' sends the document over the network 102, which document is
received by the network device 104' in the form of data packets as
is conventionally done. In contrast to the conventional network
device 104, the network device 104' has been adapted to include
functionality necessary to decode the XML encoded request and to
identify the service to be performed. Using a common design
pattern, the network device 104' allows the service to perform
tasks necessary to complete the request, including, if required,
interacting with the hardware and software of the device to perform
a service locally on the network device 104'. If further needed or
desired by the client computer, network device 104' may create and
format a response to client computer 100', which may or may not
also be an XML encoded document.
[0025] FIG. 3 illustrates a network device 104' in accordance with
the present invention in further detail. As shown in FIG. 3,
network device 104' comprises, in part, a network data transfer
service 302, a service engine 304 that accesses local copies of DTD
202 and services 308, and device software and hardware 306. It
should be apparent that network device 104' can contain or include
other components for performing conventional switching and routing
functions, for example. However, the details of such additional
components are not presented here so as not to obscure the present
invention. Further, although DTD 202 and services 308 are shown as
local storages, it should be apparent that such storage need not be
permanent. For example, DTDs and services may be retrieved from a
remote server via a URL, and just a temporary representation can be
resident on device 104' as needed by service engine 304 according
to techniques well understood by those of skill in the art.
[0026] Device hardware and software 306 represents conventional
switch or router functionality that has been adapted for use in the
present invention. In one possible implementation, where network
device 104' is an Accelar/Passport family router switch from Nortel
Networks, device hardware and software 306 includes an ASIC-based
forwarding architecture, with switch ASICs comprising most of the
device's switch fabric and handling most forwarding tasks among
switch ports in accordance with resident forwarding rules. For such
a device 104', device hardware and software 306 further includes a
CPU and associated memory coupled to the switch fabric that runs
the VxWorks real-time OS, and existing applications stored in
memory and executed by the CPU that run as VxWorks "tasks" for
monitoring and controlling and configuring the ASIC forwarding
hardware via a switch-specific API. It should be apparent that
other types of switches and routers may be used in accordance with
the invention, and that other operating systems such as Linux,
PSOS, Vertex and RMX may comprise the device's operating
system.
[0027] Services in storage 308 preferably include applications that
enhance the network management capabilities of the device 104'
above and beyond that which is possible with a conventional network
device 104. Such applications may include means for setting and
reporting system variables that are not limited by pre-configured
MIBs. Such applications may further include means for configuring
the forwarding architecture so as to enable the device to filter
network traffic containing packets generated from activities not
essential to a company's business, such as browsing the Internet.
Other examples of services can include event loggers and monitors,
means for establishing different levels of quality of service in
packet forwarding decisions, and the like. Although the discussion
below will center on services that are launched using a command
design parameter in accordance with the invention, it should be
noted that device 104' may also include functionality for executing
similar remotely downloaded, installed and managed services, which
additional similar services may also be stored in storage 308.
[0028] In one example of the invention, device hardware and
software 306 also includes an Oplet Runtime Environment (ORE.TM., a
trademark of Nortel Networks), which is a platform for secure
downloading, installation, and safe execution of services on a
network device such as a switch or router, the downloaded services
(i.e. Oplets) being locally stored in services storage 308. In such
an example of the invention, the network data transfer service 302
and service engine 304 may actually be implemented as one or more
services (i.e. Oplets) managed by the ORE.TM. (not necessarily
having a command design parameter). The ORE.TM. is described in
more detail in other publications, including publications posted at
the website www.openetlab.org, and so will not be described in
detail here so as not to obscure the invention. Although use of the
invention in network devices equipped with an ORE.TM. is considered
one preferred implementation, the invention is not so limited.
Further, the functionalities provided by the ORE.TM. that are
useful for the present invention will be apparent to those skilled
in the art after being taught by the present specification and can
be separately provided.
[0029] Network data transfer service 302 is, for example, an HTTP
server such as one provided by Apache. This is because, in one
example of the invention, the XML encoded requests and device
responses (if any) are exchanged using the HTTP protocol. As is
known, HTTP is an application-level protocol that is generic,
stateless, and can be used for many tasks other than transferring
hypertext, which is its most widely known use. In one example of
the invention, the HTTP communications take place over TCP/IP
connections. The most widely used HTTP methods for handling
communications are GET, HEAD and POST. The service engine 304 is
registered with the HTTP server (by port number, for example) so
that when XML encoded requests according to the invention are
received by service 302, service engine 304 can be activated and
provided with the XML encoded request. The HTTP server keeps
handles for all received requests pointing to the requesting
client's address (perhaps with a timeout), and when responses from
service engine 304 are received along with the handle, the HTTP
server provides the response back to the requesting client using
HTTP methods.
[0030] It should be apparent that other techniques for sending XML
files through the HTTP protocol could be used. Moreover, in another
alternative of the invention, responses may be forwarded back to
the requesting client in various presentation alternatives such as
providing HTML pages for browser access.
[0031] Device hardware and software 306 is adapted in accordance
with the invention to forward packets using the HTTP protocol and
addressed to network device 104' to the network data transfer
service 302, if an HTTP server is not already provided in the
device. This can be done in many ways known to those skilled in the
art, and may depend on the particular packet forwarding
architecture of the device. For example, where packets addressed to
the device are automatically forwarded to the device's CPU, the
device's kernel packet handling need only be aware of, and be able
to communicate packets with, the HTTP server.
[0032] Service engine 304 is generally responsible for receiving
XML encoded documents, for parsing the documents to identify the
requested service and any specific run-time parameters, for causing
the device 104' to perform the requested service in accordance with
the common design pattern and, if appropriate, obtaining and
formatting a response to the requesting client.
[0033] Service engine 304 is further illustrated in FIG. 4. As
shown, it includes a parser 402, a service launcher 404, device
APIs 406, response retriever 408 and response formatter 410.
Although shown separately for clarity of the invention, the
different blocks shown in FIG. 4 can be implemented in various
combinations either together or separately. Moreover, some or all
of the functionalities may be partially or fully included as
functionalities of the ORE.TM. in the example of the invention
where the ORE.TM. is included in the network device 104'.
[0034] Parser 402 receives the XML document from the network data
transfer service 302 (preferably along with a handle for the
individual request), and retrieves the necessary DTD based on the
required identifier in the XML document. Using the appropriate DTD,
parser 402 performs processing based on the XML tags defined in the
DTD and extracts out the values for each included in the XML
document. These parsed-out values are provided to the service
launcher 404. There are several different conventionally available
XML parsers that can be used to implement parser 402, such as
Document Object Model (DOM), Simple API for XML (SAX) and Java
Document Object Model (JDOM). In one example of the invention,
parser 402 is implemented by an Aelfred XML parser from OpenText.
The Aelfred parser generates SAX events for each parsed XML tag.
These parsed-out values and SAX events are supplied to service
launcher 404.
[0035] At a minimum, the DTD and the XML document should at least
specify one of the services 308 to be performed. For example, the
DTD may include a definition such as:
TABLE-US-00001 <!ELEMENT service > <!ATTLIST service class
CDATA #IMPLIED source CDATA #IMPLIED id ID #IMPLIED>
This allows an XML document to specify a "service" having "class,"
"source" and "id" parameters. Accordingly, a client wishing to
launch a service on a remote device would create an XML document
specifying a "service" with at least a desired "class." Such a
corresponding XML document may include the following text (as well
as an identifier of the DTD that defines its structure):
TABLE-US-00002 <service class="Address" id="ID_2">
</service>
This XML document requests the network device 104' to launch a
"service" having a class of "Address." Accordingly, in this example
of the invention, when the network device 104' receives the XML
document, parser 402 will retrieve the DTD indicated by the
identifier in the document. Using this DTD, it will understand that
a "service" having a class of "Address" should be launched.
Accordingly, it will send a message to service launcher 404 to
launch a service defined by the class "Address," which can, for
example, cause the physical address of the device to be set or
reported.
[0036] It should be noted that the source or byte code
corresponding to the service "class" may be originally available
locally on the device 104' or it may be remotely located and
specified by a URL or other path descriptor to a class file
containing such source or byte code. In one example of the
invention where the Java programming language is used, the "class"
identifier is a class whose byte code can be included in a Java
Archive (JAR) file. If the byte code corresponding to the specified
"class" is located with a URL, the service engine 304 (perhaps in
cooperation with transfer service 302) downloads the file for local
access in storage 308. Additionally or alternatively, the service
engine 304 may check whether an object corresponding to the
requested service has already been instantiated using the "id"
parameter.
[0037] If the service includes any runtime parameters, the DTD and
XML documents should specify those as well, although the service
should be able to execute using default parameters. Depending on
the service requested, there may or may not be a requested response
to be sent back to the client. For example, one requested service
may be to provide traffic statistics of the device, for which a
response would be collected from the device hardware and software
and returned to the client. Meanwhile, another requested service
may be to adjust priorities of certain traffic flows, for which a
response from the device hardware and software would not
necessarily be requested. As an example of a requested service with
runtime parameters, a requested service may be to report on device
throughput, collected a variable number of seconds apart, with the
report repeatedly provided back to the client once per variable
number of minutes.
[0038] Using the above example of the service of class "Address,"
the DTD may further include a definition such as:
TABLE-US-00003 <!ELEMENT property (value | null)*>
<!ATTLIST property name CDATA #REQUIRED> <!ELEMENT value
(#PCDATA)*> <!ATTLIST value class CDATA #IMPLIED id ID
#IMPLIED source IDREF #IMPLIED>
This allows a "property" with a "name" to be assigned a "value." A
corresponding XML document may then be created by the requesting
client that contains the following text:
TABLE-US-00004 <property name = "city"> <value
id="ID_3">San Francisco</value> <property>
<property name = "country"> <value
id="ID_4">USA</value> </property>
When these definitions and this text are combined with the
previously-described XML-encoded request, the combined XML text
could, for example, cause a service of class "Address" to set a
city field and a country field in the device address system
variables to San Francisco and USA, respectively.
[0039] In one example of the invention where the source code
corresponding to a service is provided as Java classes, service
launcher 404 includes a Java Virtual Machine (JVM) that is ported
to the device 104' and operates as a task on the device CPU under
an operating system such as VxWorks. The JVM receives the byte code
corresponding to the Java class from storage 308 and instantiates
an object corresponding to the service using a no arguments
constructor. Alternatively, service launcher 404 identifies an
already-instantiated object corresponding to the service using an
"id" parameter or the like. Further, during or before instantiating
the object, service engine 404 may detect that certain other class
files are needed and operate to download or access them as
well.
[0040] Once instantiated, service engine 404 sets properties in the
object using any parameters also provided in the XML document and
parsed out by parser 402. For example, for each property "name"
there may be a corresponding "set" method (e.g. for the "city"
property, there is a "setCity" method), which method the service
engine 404 calls using the JVM to set the property to the "value"
parsed from the XML document.
[0041] According to an aspect of the invention, all services do not
continually run on the device 104'. Rather, individual services are
launched as requested by clients so as to perform functionality
when needed. Moreover, services according to the invention are
designed to be executed using a command design parameter so that
the service engine 404 need not be aware of the internal code used
to implement the service.
[0042] Therefore, all services designed in accordance with the
invention include an "operate" method which serves as the command
design parameter. In the example of the invention where services
are implemented using the Java programming language, this can be
done by requiring all services to be based on, or to "implement" a
standard interface class. For example, each service class may
implement an interface class defined as:
TABLE-US-00005 public interface Operation { public Object operate(
); }
Each service class thus provides its own implementation of the
"operate" method of the Operation interface. After instantiating
the service class (perhaps also after "setting" various properties
of the service object using parameters from the parsed document),
service launcher 404 calls this specific "operate" method.
Accordingly, service launcher 404 can cause various types of
services to be performed without needing to know their
implementation. This is akin to putting the code needed to process
the requested service in the request itself.
[0043] Device APIs 406 includes functionality to interact with
device hardware and software 306 to perform the requested service
and to receive any responses from the device's device hardware and
software. For example, where a service requests a network parameter
of the device such as the device's name, the device APIs 406 will
interact with the device hardware and software to retrieve the name
(e.g. a string) from the device's system variables (e.g. MIB) and
provide it to response retriever 408, along with an identifier of
the service that requested the parameter.
[0044] It should be appreciated that the actual implementation of
device APIs 406 depends on the code used to implement services 308,
as well as the device hardware and software. In one example of the
invention, all services 308 use a common code language such as
C/C++. In such an example, device APIs 406 comprises APIs that
provide a common interface for all such services to the existing
code running on the device 104'. Accordingly, services 308 can be
designed to execute on various platforms, with a known set of APIs
providing a common interface to the services, while providing a
variable interface with the existing code, depending on the device.
The design and implementation of such APIs are within the skill of
those in the art given the existing code, the device operating
system and the design of services 308.
[0045] In another example, device APIs 406 communicate with
existing conventional applications of network device 104 through a
loopback address of the device. For example, the service requested
by the received XML document may request access to network
parameters of the device. Specifically, the requested service
launched by the service engine can access the network parameters of
the device by specifying the loopback address, which can then
access the parameters through a network protocol stack such as an
SNMP stack.
[0046] It should be apparent that the above two examples are not
necessarily mutually exclusive. Further, other example
implementations of device APIs 406 are possible. Moreover, it
should be apparent that some services 308 need not require APIs to
fully operate.
[0047] Response retriever 408 keeps track of the services that
require responses from the device hardware and software and
initiates response messages to the requesting client when responses
are received. It receives from service launcher 404 identifiers of
the services that have been launched, as well as handles to the XML
encoded request that caused the service to be launched. When
responses are received from device APIs 406, they are preferably
received along with the identifier of the service. Response
retriever 408 can then correlate the response to the XML encoded
request to whom the response belongs and forward the response to
response formatter 410 along with the handle to the XML encoded
request.
[0048] Response formatter 410 formats response messages to be sent
back to the requesting client. It receives from response retriever
408 a response along with an identifier of the XML encoded request,
formats a response message for transmission back to the requesting
client, and forwards the response message to the network data
transfer service 302. Network data transfer service 302 can then
send the message back to the requesting client by using the handle
of the XML encoded request to retrieve the header information
contained in the packets carrying the XML encoded request. In one
example of the invention, responses are also XML encoded documents
that will instantiate a response object on the client. In this
example, response formatter 410 may also access DTDs such as DTD
202 for formatting a response. However, it should be apparent that
many other variations of formatting a response other than using XML
documents are possible.
[0049] It should be further apparent that there are many possible
ways of implementing response retriever 408 and response formatter
410, and that they may be omitted altogether. For example, response
retriever 408 and/or response formatter 410 may be partially or
fully implemented by either or both of services 308 and device APIs
406.
[0050] FIG. 5 is an architectural view of an example of network
device 104' in accordance with the principles of the present
invention.
[0051] As shown in this example, interaction with the device
hardware 514 (e.g. switch fabric, ports, memory, etc.) is performed
through the device operating system 512 (e.g. VxWorks). The device
code (e.g. routing software, etc.) 502 interacts with the device
operating system 512. Application programming interfaces (API's)
504 (e.g. Java, C/C++, etc.) interact directly with the device
hardware 514 and/or via device operating system 512. API's 504 may
further interact with device hardware and operating system through
device drivers (not shown). Java Virtual Machine (JVM) 508
preferably includes all functionality provided by a conventional
JVM and is ported to the device 104' and operating system 512.
Oplet Runtime Environment.TM. (ORE) 506 interacts with the JVM to
coordinate the downloading, management and execution of services
308. Service engine 304 interacts with ORE 506 for execution of
services 308. Service engine 304 and transfer service 302, during
operation, may also interact with API's 504, which further interact
with device code 502.
[0052] FIG. 6 illustrates an example implementation of a network
device 104' having the architecture illustrated in FIG. 5.
[0053] As shown, network device 104' includes a CPU 602, switch
fabric 604, storage 608, network port 610 and memory 612 all
communicating via a bus 614. Switch fabric 604 further communicates
with switch ports 606. Storage 608 can comprise memory for storing
program and device data. Network port 610 can provide a loopback
address for access by services and other network management
applications as described above. Memory 612 includes code for
execution by CPU 602.
[0054] It should be apparent that components corresponding to CPU
602, switch fabric 604, switch ports 606, storage 608, network port
610, memory 612 and bus 614 are also provided in a conventional
network device 104. Accordingly, as should be further apparent from
FIG. 6, adapting a conventional network device 104 in accordance
with the invention merely requires updating memory 612 to include
executable software corresponding to the above-described
functionality of the invention.
[0055] FIG. 7 illustrates an example of a process by which an XML
encoded request received by the network device 104' is fulfilled in
accordance with the present invention.
[0056] As shown in FIG. 7, when interaction with the network device
104' is desired, the client computer 100' encodes the request by
constructing an XML encoded document corresponding to the request
and in accordance with a corresponding DTD. This XML document is
sent across the network 102 using a standard network protocol such
as HTTP and received by network device 104' (block S702). The XML
document is received by the network data transfer service 302
running on the network device 104' and provided to the service
engine 304. The service engine 304 parses the XML document using
the corresponding DTD identified in the document (block S704). The
parsed document corresponds to one of the services provided or
retrieved for local access in storage 308. Accordingly, service
engine 304 instantiates a copy (or identifies an
already-instantiated copy) of the service with the properties
specified in in the parsed document (block S706). The instantiated
service is then launched for execution by invoking the "operate"
method of the service or similar command design parameter (block
S708). The requested service may require interaction with the
device software and hardware for execution, as indicated in block
S710. If a response message back to the requesting client 100' is
required by the service (determined in block S712), the response
from the device hardware and/or software is retrieved (block S714),
and a response message is formatted and forwarded to network data
transfer service 302 for transmission back to client 100' (block
S716).
[0057] Although the present invention has been particularly
described with reference to the preferred embodiments, it should be
readily apparent to those of ordinary skill in the art that changes
and modifications in the form and details may be made without
departing from the spirit and scope of the invention. It is
intended that the appended claims include such changes and
modifications.
* * * * *
References