US20150134845A1 - Object Oriented Communication Among Platform Independent Systems over Networks Using SOAP - Google Patents

Object Oriented Communication Among Platform Independent Systems over Networks Using SOAP Download PDF

Info

Publication number
US20150134845A1
US20150134845A1 US14/453,487 US201414453487A US2015134845A1 US 20150134845 A1 US20150134845 A1 US 20150134845A1 US 201414453487 A US201414453487 A US 201414453487A US 2015134845 A1 US2015134845 A1 US 2015134845A1
Authority
US
United States
Prior art keywords
soap
communication protocol
underlying
network element
routine
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/453,487
Inventor
Michael Linderman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GANAS LLC
Original Assignee
GANAS LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37568926&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US20150134845(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US09/867,469 external-priority patent/US7007094B1/en
Application filed by GANAS LLC filed Critical GANAS LLC
Priority to US14/453,487 priority Critical patent/US20150134845A1/en
Publication of US20150134845A1 publication Critical patent/US20150134845A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0246Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/289Object oriented databases
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0226Mapping or translating multiple network management protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0233Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0246Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0253Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0246Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0806Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/085Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/133Protocols for remote procedure calls [RPC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/565Conversion or adaptation of application format or content
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present subject matter relates to a software and hardware infrastructure allowing for the management of any network device regardless of its location utilizing only a single communications protocol.
  • an HTML document converts the presentation of information served to the browser by a server.
  • contents of an HTML file are static in that the browser can only present a passive snapshot of the contents at the time the document is served.
  • conventional world wide web service employ a “raw” interface such as a common gateway interface (CGI).
  • CGI common gateway interface
  • the CGI mechanism assumes access to the application on the customer's site, but not to the object.
  • the person or process that invokes the CGI program must have full knowledge of that program.
  • a firewall is not in control of the CGI. Therefore, the use of the CGI would make it impossible to fully secure communications between users.
  • the CGI mechanism works only in the client server environment communicating to one server. This method cannot be applied to the distributed multi-process environment, if only a single communications protocol for the entire system is to be utilized.
  • CGI common object request broker architecture
  • IIOP internet inter-ORB protocol
  • CORBA common object request broker architecture
  • DCOM and IIOP/CORBA are rich environments, which means that implementations and applications that use them tend to be complex and symmetrical.
  • the internet does not guarantee the specific kind of client or server software which would be running at the second end of the connection. All that is required is that the connection understands the hypertext transfer protocol (HTTP). Additionally, it is often technically impossible to insure that all applications would run either IIOP or DCOM.
  • HTTP hypertext transfer protocol
  • firewalls make the efficient use of distributed object protocols very challenging. Understanding why firewalls cause problems for distributed object protocols requires understanding of how a firewall is able to distinguish one protocol from another. For example, in the TCP/IP architecture, each widely used protocol is assigned its own port number and each request made using this protocol carries that number.
  • HTTP for example, is generally assigned port 80 , while, for example, the file transfer protocol (FTP) relies on port 21 .
  • Most firewalls allow blocking a specific protocol by rejecting all traffic sent on the port used by that protocol.
  • firewalls are configured to allow traffic on port 80 . If this was not the case, HTTP requests from browsers could not be received. However, many firewalls block most other ports. This would result in other protocols not being received by the user's local server.
  • HTTP HyperText Transfer Protocol
  • XML HyperText Transfer Protocol
  • SOAP simple object access protocol
  • IBM Lotus Development Corporation
  • Microsoft and User Land Software This protocol adds a set over the HTTP headers and rich XML payload to enable complex application-to-application communication over the internet.
  • SOAP messaging protocol uses HTTP to carry messages that are formatted with XML.
  • the deficiencies of the prior art are addressed by the present subject matter which is directed to a system utilizing an object access protocol as the single communications protocol between the user, any intermediate software system, and a network element (hardware).
  • the subject matter utilizes the same object protocol, not only as the foundation of the internet communication, but also for the lower level inter-object communication.
  • the system can also be used to control the switches running the network.
  • the server can utilize the simple network management protocol (SNMP) to configure the switches, the present subject matter would be able to control a network's back-end remotely, and will even be capable of changing bandwidth assignments.
  • SNMP simple network management protocol
  • the present subject matter Because of its object access nature, the present subject matter is adaptable to control any network device be it a server, a switch, or any number of other devices such as network printers and fax machines.
  • a host of emerging “smart” products including computer controlled appliances such as refrigerators and other kitchen appliances, climate control systems and medical devices can also be controlled.
  • the present subject matter is cross platform compatible since it is capable of running regardless of the platform because it is built in industry and standard protocols and is therefore not restricted to any given platform, thereby making a completely unique product.
  • the present subject matter will consist of a client and a number of servers.
  • the client end would include a web browser interface enabling the utilization of HTTP compatibility with the SOAP which is designed specifically enable the transmission of XML payloads with special HTTP headers.
  • Every server of the present subject matter will run a parser filtering out the XML messages and sill translate these messages into necessary commands to be executed across network elements.
  • the XML vocabulary will be translated into the necessary SNMP commands to be issued to the switches.
  • the present subject matter will be scalable, thereby allowing for the addition of management capabilities by the integration of additional command protocols for communicating with other devices.
  • the present subject matter will initially control devices that use the SNMP or Command Line Interface (CLI) protocol and can be scaled to add support for future protocols and devices as these become industry standards.
  • CLI Command Line Interface
  • the architecture of the present subject matter allows a user to wrap existing or new communications equipment in a SOAP/XML wrapper, which would then allow for internet readiness or manageability via the internet anywhere in the world.
  • the software wrapper is the computer program that understands object access protocol, i.e. contains a Protocol Virtual Machine (PVM), and runs on a single board computer, or on the hardware of the network element.
  • PVM Protocol Virtual Machine
  • a T-Box has a direct (not via the Internet) connection to the controlled network elements.
  • the T-Box can communicate to the network elements via the Simple Network Management Protocol (SNMP) or Comment Line Interface (CLS) .
  • SNMP Simple Network Management Protocol
  • CLS Comment Line Interface
  • a network management system would be utilized with the SOAP/XML protocol as the foundation for inter-object communication.
  • the SOAP protocol extends the XML into the remote procedure call (RPC) paradigm in a standardized manner.
  • RPC remote procedure call
  • the present subject matter extends the simple RPC paradigm to a more complex useful transaction-based approach whereby a “call” by user could be chained through a series of servers each providing a telecommunications management network (TMN) hierarchy management level over the internet.
  • TSN telecommunications management network
  • the SOAP infrastructure is important to the technology of the present subject matter.
  • Available SOAP parsers had to be broken up and modified into client and server side parsing engines.
  • the purposes of asynchronous identifications a connection pooling mechanism was developed upon which the SOAP messages rode. The utilization of this system would allow network elements to be remotely controlled across a network.
  • FIG. 1 is a block diagram showing the hardware of the present subject matter as well as an upward ordered message flow
  • FIG. 2 is a block diagram of the present subject matter as well as showing a downward ordered message flow
  • FIG. 3 is a diagram showing an alarm path flow
  • FIG. 4 is a diagram showing alarm object communication and distribution.
  • FIG. 5 is a diagram showing an alternate embodiment of the present subject matter.
  • FIG. 6 is a flow diagram showing the operation of the present subject matter.
  • FIGS. 1 and 2 The system design 10 of the present subject matter is shown in FIGS. 1 and 2 .
  • separate CPUs 12 and 14 would include portions of the system hardware of the present subject matter.
  • the application can have as many CPUs as servers. We have shown two CPUs only for clarity reasons.
  • the CPU 12 would include a web browser 16 associated with a GUI which is an applet loaded by the web browser from the localized web server 20 . This would prompt the user for data to perform a particular command. Once the required data is entered, the command is encoded into an HTTP-SOAP message.
  • the drawings illustrate the utilization of two CPUs, the present subject matter can employ as many CPUs as there are servers. The use of only two CPUs in the present subject matter was for clarity purposes only.
  • the legend is: Name-of-SNMP-program node_address command (get/set) class.item object_id value.
  • SOAP is an XML based textual protocol, instead of numerals, it contains meaningful strings representing class, item, and object id in the component hierarchy.
  • the SNMP-like set of commands can be expanded if required.
  • the present subject matter always guarantees the delivery of the message, referred to as “nailing connections”.
  • the receiving server in our system always notifies the sender.
  • the second CPU 14 would include a web server (Apache) which is the entry point of the network management system of the present subject matter.
  • the web server 20 would determine if the message is a SOAP message. If this is the case, it would strip off the HTTP header and forward the remaining SOAP/XML message to the SOAP server 22 .
  • This server is a servlet container which, upon receiving a SOAP message, a determination would be made to which server the message is destined. In this instance, the message will always be routed from or to a read/write server (RWS) 24 .
  • the RWS 24 Upon receipt of the message from the SOAP server 22 , the RWS 24 will store the data in a generic model in a relational database 30 in an object to relational table mapping. The RWS 24 will then forward or receive the message from a network management agent (NMA) 26 .
  • NMA network management agent
  • the NMA 26 will then determine the course of action required for the particular type of request or command and build the appropriate model for it using G.855, G.85X recommendations as its basis.
  • the NMA 26 will then forward commands to or receive comments from various network element agents (NEA) 28 .
  • NAA network element agents
  • FIGS. 1 and 2 it is noted that a number of NEAs can be employed.
  • the NEA 28 upon receiving a nodal command from the NMA 26 will the build a M.3100 management model to support the nodal action.
  • the NEA 28 will then forward a smaller command to a translation device (T-box) 32 for processing or translation.
  • T-box 32 then translates the SOAP command into the native language of the intended device such as network element 34 , or SNMP.
  • the web browser 16 will generally be a third party provided browser. Most personal computers come with a preinstalled browser or can easily be downloaded. Both Netscape and Internet Explorer will be supported as both are Java enabled. However, it is also possible to use either front end applications written in any other computer language, as long as they are talk SOAP/XML.
  • the web browser 16 will upload applets from the web server 18 for procedural contacts and communicate the network data transactions back to the web server 20 to be forwarded to the RWS 24 .
  • a network element record must already have been installed into the database 30 for that network element. The user will only be allowed to select from the list of network elements currently being managed.
  • the web browser will also receive asynchronous events from the web server and display them.
  • the RWS 24 will receive or send user requests and store them in the database 30 as they are received. After a successful storage, a SOAP envelope will be sent to the NMA 26 to begin execution of the user request. The RWS 24 will also forward alarms to the web server 20 for display when it receives them from lower layer processors such as an NEA 28 .
  • the NMA 26 when triggered by the RWS 24 will initiate processing of the user request.
  • the NMA 26 will read and parse the SOAP request and then build a model required to satisfy that request.
  • the NMA 26 will send a series of SOAP encoded singular node access requests to the NEA each with the data sufficient to satisfy the secondary request.
  • a typical NMA network request is broken down into a set of simpler nodal requests.
  • the NMA will implement a standard space model in order to satisfy the network management layer requirement.
  • the NMA will process the request to either a successful or error termination condition.
  • the NMA will log the cumulative status of the user request and also send a response SOAP packet back to the RWS 24 to be forwarded to the user.
  • the NMA 26 will store the data required for each nodal requested to the database 30 .
  • Each NMA request and secondary NEA request all will have unique transaction Ids and database tables.
  • a Network Element Discovery server (NED) 25 can be provided between the NMA 26 , the RWS 24 and the NEA 28 included in FIGS. 1 and 2 .
  • the NED will discover and store in the database 30 each network element's configuration.
  • the configuration data may contain port, card, slot and shelf information. It may also discover the current set of provisional connections and their states.
  • the NED 25 will use the NEA 28 for access to the network elements in order to perform its discovery task.
  • the NED will be used to populate the database tables initially. It will also perform an Audit/Learn function.
  • firewall 36 separates the web browser 16 , the web server 20 and the SOAP server 22 from the remaining elements of the system.
  • the NEA 28 will be triggered from a SOAP envelope received from the NMA 26 .
  • the NEA will parse the XML document which encompasses the data necessary to complete a single nodal transaction.
  • An M.3100 derivative model will be used to satisfy the elemental management layer requirement.
  • the NEA 28 will proceed to
  • FIGS. 1 and 2 show the T-box 32 connected to a single network element 34 , it can be appreciated that a single T-box can manage several network elements. To explain, one T-box can manage several network elements.
  • a success or failure message is received, the status is then stored in the database for logging purposes and then the status is sent back to the NMA 26 .
  • the purpose of the database 30 is of course to store information. Once a user hits the appropriate button on the browser 16 , an NMA request will be received by the RWS 24 and immediately stored in the database. Additionally, each NEA request is stored in the database before being processed by the NEA 28 . Furthermore, the configuration of each network element is also stored in the database 30 .
  • the T-box 32 contains embedded software.
  • the T-box will be able to receive “M-GET”, “M-SET” and “M-ACTION” requests via the SOAP interface, as well as command line interfaces (CLI).
  • the T-box will translate the SOAP command into the appropriate native console command (MML), (CLI) or SNMP, and send it via an ethernet interface to the actual network element in order to satisfy the given NEA request.
  • MML native console command
  • CLI native console command
  • SNMP SNMP
  • the HTTP-SOAP protocol provides the present subject matter a method of information exchange between functional components. Similar to any messaging protocol, it provides for data encapsulation with messages.
  • the HTTP-SOAP protocol includes an envelope defining a framework for describing what is in a message and how to process it. It also includes a set of encoding rules for expressing instances of application defined data types as well as a convention for representing remote procedure calls and responses.
  • the T-box can control the network element from the applet directly to the T-box without control from additional servers.
  • the applet is a JAVA program that runs within the web browser. However, any application written in any language can talk to the network element through the T-box using SOAP as one protocol.
  • the network element 34 sends a message to the T-box 32 over, perhaps, the ethernet as shown by Step 1 .
  • the T-box 32 includes a parser therein and utilizes the parser to translate the response received from the network element 34 into a SOAP response and sends this response to the NEA 28 at Step 2 . It is noted that a plurality of NEAs would be utilized and the message relayed from the T-box 32 would be sent to the NEA 28 which is managing that particular network element.
  • the NEA 28 forwards the nodal response created therein to the NMA 26 .
  • the NMA then forwards the entire transaction response to the RWS 24 at Step 4 .
  • the RWS 24 will then forward this response to the SOAP server 22 at Step 6 , as well as to the database 30 at Step 5 .
  • the SOAP server 22 would then forward the response to the web server 20 which in turn would send the response back to the web browser 16 in the first CPU 12 .
  • FIG. 2 illustrates a downward message flow from the CPU 12 ultimately to a network element 34 .
  • the web browser 16 will connect to the web server 20 at Step 2 .
  • the web server will automatically upload the
  • the web browser 16 that will prompt the user for a command and a set of attributes used to control the network element 34 . If authorized by the user, the web browser 16 would then be connected to the web server 20 in the second CPU 14 as shown by Step 2 . At this point, the web browser will then build and send an HTTP-SOAP envelope to the web server 20 . Upon receipt of the SOAP envelope, the web server 20 will immediately route it to the SOAP server 22 as shown by Step 3 . Once the SOAP server 22 determines that a proper request has been made, it will be forwarded across the firewall 36 to the RWS server 24 as shown by Step 4 . At Step 5 , the RWS 24 will modify the request if required and then store it in the database 30 .
  • the RWS server will also forward the request to the NMA 26 as shown by Step 6 .
  • the NMA 26 will process this message and forward the necessary subcomponents to the proper NEA 28 for nodal processing.
  • Step 8 indicates that the NEA 28 will forward the appropriate single-space command to the T-box 32 .
  • the T-box 32 will formulate and send the proper translation for the command to the network element 34 across the ethernet as shown by Step 9 .
  • FIGS. 3 and 4 illustrate the alarm path network of the system of the present subject matter also indicating that the architecture is very scalable and allows for several NMAs as well as several NEAs and one or more GUIs and T-boxes.
  • alarms are received by the NEAs, they are immediately forwarded to the NMA for further processing and forwarding.
  • Alarms can be received by the NEA at any time and are discriminated via the header field. Thus an in-progress provision cannot get confused with alarms being interpreted as responses.
  • the directions of the alarm message will be from the Network Element to the T-Box and then to the NEA.
  • the alarm will then proceed to the NMA, the RWS and the GUI (web browser).
  • the alarms by nature, go from the hardware equipment to the web browser.
  • a user that connects to the RWS from a GUI will register with the alarm distributor class for alarms.
  • alarms are received by the NEA, they are immediately forwarded to the NMAs for further processing and forwarding.
  • Alarms can be received by the NEA at any time and are discriminated via the header field.
  • the header attribute “alarm” indicates to the SOAP senders that this is an alarm data object.
  • the present subject matter employs a TCP/IP network with a connection to the internet.
  • the network has a firewall between itself and the internet. It is possible for a network administrator to access and configure all equipment on the network through the use of telnet, SNMP, and other network management tools. These tools can only be used from behind the firewall. The firewall will, however, prevent these connections from being made from behind the firewall.
  • HTTP connections which are still left open by the firewall to send in SNMP commands to the equipment beyond the firewall. This would allow the present subject matter to control the bandwidth being assigned to any part of network. This would also enable ISPs and other providers of bandwidth to sell bandwidth in a more dynamic manner because the bandwidth could be adjusted to meet demands more quickly and easily than currently possible.
  • the present subject matter also has the ability to allow a single network administrator to administer networks in different geographic locations. For example, if a service provider is located in Canada, network elements can be connected to a T-box in Canada utilizing a serial cable, an ethernet cable to a hub. The provider would then send email to a customer located, for example, in the United Kingdom confirming this connection. The customer would then email to an engineering technical support team located, for example, in China so that it can assign the correct IP addresses to the switches through a web interface. After these addresses are quickly assigned, the switches are registered for technical support if debugging will be required. The debugging of the switch can be done in various locations through the web interface. Once the registration is completed, the user will start provisioning of the network element using the web interface.
  • the provider in Canada will make selections relating to various equipment that must be connected.
  • the T-box in Canada receives a generic command, it will make a decision to translate this to CLI or SNMP for the network element.
  • Most of the debugging commands usually include CLI access.
  • this switch can be used to enable or disable different ports that are used to connect the different devices together via the switch. Furthermore, the speed of the data that travels through these ports can also be altered.
  • traffic can be regulated through the system.
  • different virtual local area networks can be created and connected to that one switch. This is done for the purposes of isolating data that users can share on the computers or to isolate peripheral devices.
  • the present subject matter can be utilized to control “smart” devices such as computerized appliances and the like.
  • equipment can help the homeowner with climate control.
  • the present subject matter can interface with electrical, wired or wireless devices or equipment. In such a scenario, the present subject matter can be used to program these devices and help in the automation process.
  • the present subject matter is also capable of interfacing with wireless data systems and devices as well as interfacing with medical devices, distant learning equipment and various other telecommunications equipment.
  • the present subject matter offers a highly distributed network management application by using an XML based communication protocol.
  • the translator for the XML based protocol to SNMP or TL1 can be embedded in a small hardware device serving as a web server controlling a number of network elements.
  • FIG. 5 illustrates an alternate embodiment of the present subject matter in which a user request is transmitted directly from a browser/application 40 to the T-box 48 and then to the network element or application 50 instead of proceeding directly through a database 42 , network manager 44 and element manager 46 as illustrated in FIGS. 1 and 2 .
  • a graphical user interface is used to control the communications between the browser/application 40 and the network element/application 50 directly through the T-box 48 or indirectly through the network manager 44 and element manager 46 .
  • communication is provided either upwardly or downwardly directly through the T-box 48 or indirectly through the T-box and database 42 , network manager 44 and element manager 46 .
  • the T-box 48 is provided with both a SOAP server as well as the PVM.
  • the GUI is provided with two input devices on the screen. These input devices would indicate whether the user request is to proceed directly to the T-box 48 or via the network management system shown in FIGS. 1 and 2 . As illustrated in FIG. 5 , this network management system would include the database 42 , the network manager 44 as well as the element manager 46 . This is important since if the network management system is not operating, communication can still be provided from the browser application 40 directly to the T-box 48 and then to the network element/application 50 . It is important to note that this communication can also proceed from the network application 50 to the T-box 48 and then directly to the browser/application 40 . This is true since the T-box 48 can transfer a user request from a native language into SOAP as well as translate the SOAP packet into the native language.
  • the user can also specify whether a native command or generic command would be utilized. Generally, the user would not concern themselves with the command names that were given to a particular vendor. In this case, the user would utilize the generic command set.
  • the GUI would include NE NAME as a pop down field automatically populated with the names of the network elements. For example, these names might correspond to LAB 7 Router, 1548M Cisco switch and UofORouter corresponding to the Cisco 7000 router.
  • the present subject matter utilizes the following commands: Connect, disconnect, setVlan, showVlan, setPortUp as well as setPortDown.
  • the input data includes parameters that the user can set. For example, in the case of the Virtual Lan (setVlan), the user can specify which port is connected to which Vlan. After making a selection, the user can submit the request. An applet will create the SOAP message and send it through the selected path. Request and reply log area will display the appropriate logs and the user interpretation view will display logs and alarms coming from the equipment.
  • setVlan Virtual Lan
  • the input data includes parameters that the user can set. For example, in the case of the Virtual Lan (setVlan), the user can specify which port is connected to which Vlan. After making a selection, the user can submit the request. An applet will create the SOAP message and send it through the selected path. Request and reply log area will display the appropriate logs and the user interpretation view will display logs and alarms coming from the equipment.
  • FIGS. 1 and 2 show the use of the present subject matter sending user requests from a browser/application to a network/application through at least one firewall.
  • FIG. 5 indicates that the present application would also operate in a situation in which no firewalls are present. However, it is noted that all of the embodiments can operate with or without firewalls.
  • FIG. 6 is a flow diagram showing the operation a method 600 for communicating between an application source located on a first side of a firewall and a network element located on a second side of the firewall, according to the present subject matter.
  • An applet to drive a user request is provided (Step 601 ).
  • the applet is provided to the application source by a web server included on a first side of a firewall and sent to a read/write server provided on a second side of the firewall.
  • a hypertext transfer protocol-simple object access protocol (HTTP-SOAP) packet of said user request is created (Step 603 ).
  • the HTTP portion of the HTTP-SOAP packet is removed (Step 604 ) in order to create a SOAP message.
  • HTTP-SOAP hypertext transfer protocol-simple object access protocol
  • a user request including the SOAP message is sent to the RWS (Step 605 ).
  • the SOAP message is then sent to the NMA (Step 606 ).
  • An appropriate model is built in the NMA (Step 607 ) and the SOAP encoded request is parsed in the NEA (Step 608 ) nea to complete a single nodal transaction.
  • a SOAP encoded request is then sent from the NMA to the NEA (Step 616 ) and the SOAP encoded request is sent from the NMA to the NEA (Step 617 ).
  • Data is encoded in the NEA to produce the SOAP packet (Step 619 ).
  • the SOAP packet is transmitted to the translator box (Step 621 ) and the SOAP packet is translated into an appropriate command (Step 622 ).
  • the command is transmitted to the network element (Step 624 ).

Abstract

A system for object oriented communication among platform independent systems over networks using SOAP, in which communications can be performed over a network utilizing a single communications protocol. A simple object access communications protocol (SOAP) is utilized for sending messages from one object to another across the network in a platform independent manner. This type of protocol can be utilized to control network elements provided at various locations.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application is a continuation of U.S. application Ser. No. 11/976,509, filed Oct. 25, 2007, now U.S. Pat. No. 7,734,756, which is a continuation of U.S. application Ser. No. 11/510,760, filed Aug. 28, 2006, now U.S. Pat. No. 7,325,053, titled, “Object Oriented Communication Among Platform-Independent Systems Over Networks Using Soap”, which is a continuation of U.S. application Ser. No. 09/900,041, filed Jul. 9, 2001, now U.S. Pat. No. 7,136,913, titled, “Object Oriented Communications System Over the Internet”, which in turn claims the benefit of U.S. provisional patent application No. 60/208,045, filed on May 31, 2000, and No. 60/242,708, filed on Oct. 25, 2000, as well as U.S. application Ser. No. 09/867,469, filed on May 31, 2001, now U.S. Pat. No. 7,007,094.
  • BACKGROUND OF THE INVENTION
  • 1. Field
  • The present subject matter relates to a software and hardware infrastructure allowing for the management of any network device regardless of its location utilizing only a single communications protocol.
  • 2. Background
  • Although a browser can be used to directly request images, video, sound etc. from a server, more usually, an HTML document converts the presentation of information served to the browser by a server. However, generally the contents of an HTML file are static in that the browser can only present a passive snapshot of the contents at the time the document is served. In order to present dynamic information, such as information generated by an application or device or to obtain from the user data which has been inserted into an HTML-generated form, conventional world wide web service employ a “raw” interface such as a common gateway interface (CGI). The HTML file provides no mechanism for presenting dynamic information generated by an application or device, except through the CGI.
  • With respect to obtaining data from a user for use by the application or device, although standard HTML provides a set of tags which implements a convenient mechanism for serving interactive forms to the browser, complete with text fields, check boxes and pull down menus, the CGI must be used to process submitted forms. Form processing is important to remote control, management, configuration, monitoring and diagnosing applications because forms processing is a convenient way to configure an application according to a user input utilizing the world wide web communications model. Unfortunately, form processing employing a CGI is extremely complex, requiring an application designer to learn and implement an unfamiliar interface. Therefore, a CGI is not a suitable interface for rapid development and prototyping of graphical user interfaces (GUI).
  • Furthermore, a developer must then master a native application source code language (such as C and C++), HTML and the CGI, in order to develop a complete application along with its user interface. Additionally, the CGI mechanism assumes access to the application on the customer's site, but not to the object. The person or process that invokes the CGI program must have full knowledge of that program. A firewall is not in control of the CGI. Therefore, the use of the CGI would make it impossible to fully secure communications between users. Finally, the CGI mechanism works only in the client server environment communicating to one server. This method cannot be applied to the distributed multi-process environment, if only a single communications protocol for the entire system is to be utilized.
  • Other systems could be used instead of the CGI. For example, an object model such as Microsoft's DCOM or the object management groups internet inter-ORB protocol (IIOP) or the common object request broker architecture (CORBA) could be employed. However, these technologies have some limitations when it comes to creating web services. For example, DCOM and IIOP/CORBA are rich environments, which means that implementations and applications that use them tend to be complex and symmetrical. In other words, to build a distributed application using them, one typically must require the same distributed object model running at both ends of the connection. However, the internet does not guarantee the specific kind of client or server software which would be running at the second end of the connection. All that is required is that the connection understands the hypertext transfer protocol (HTTP). Additionally, it is often technically impossible to insure that all applications would run either IIOP or DCOM.
  • Any server connected to the internet can potentially be accessed by an internet user, which raises some obvious security problems. To address these concerns, most organizations insert a firewall between their publically accessible web servers and the masses that can access the servers. Generally, a firewall can block incoming traffic based on various criteria and thereby increase an organization's confidence in the security of its system. While they are essential to the secure use of the internet, firewalls make the efficient use of distributed object protocols very challenging. Understanding why firewalls cause problems for distributed object protocols requires understanding of how a firewall is able to distinguish one protocol from another. For example, in the TCP/IP architecture, each widely used protocol is assigned its own port number and each request made using this protocol carries that number. HTTP, for example, is generally assigned port 80, while, for example, the file transfer protocol (FTP) relies on port 21. Most firewalls allow blocking a specific protocol by rejecting all traffic sent on the port used by that protocol. In general, firewalls are configured to allow traffic on port 80. If this was not the case, HTTP requests from browsers could not be received. However, many firewalls block most other ports. This would result in other protocols not being received by the user's local server.
  • Unlike HTTP, FTP and other widely used protocols, distributed object protocols do not generally have a single well known port number assigned to them. Instead, these protocols typically use dynamically assigned ports, with port numbers chosen arbitrarily as needed. If no firewall intervenes in the communication between the client and the server, this approach works fairly well. If a firewall is asserted, communication stops because the firewall blocks all traffic using this protocol since it is not configured to pass requests on arbitrary port numbers.
  • One response to this challenge is to use existing internet standards such as an HTTP and XML. More than any other application protocol, the HTTP connects most users to one another. Millions of web sites and browsers utilize protocol. The problem with HTTP alone is that it is mainly a mechanism for passing files from a server to a client. To create more ambitious web servers, the HTTP must be expanded.
  • One manner of extending the HTTP would be to use an object protocol such as the simple object access protocol (SOAP) copyrighted by IBM, Lotus Development Corporation, Microsoft and User Land Software. This protocol adds a set over the HTTP headers and rich XML payload to enable complex application-to-application communication over the internet. In other words, the SOAP messaging protocol uses HTTP to carry messages that are formatted with XML.
  • SUMMARY
  • The deficiencies of the prior art are addressed by the present subject matter which is directed to a system utilizing an object access protocol as the single communications protocol between the user, any intermediate software system, and a network element (hardware). The subject matter utilizes the same object protocol, not only as the foundation of the internet communication, but also for the lower level inter-object communication. The system can also be used to control the switches running the network. Because the server can utilize the simple network management protocol (SNMP) to configure the switches, the present subject matter would be able to control a network's back-end remotely, and will even be capable of changing bandwidth assignments. Because of its object access nature, the present subject matter is adaptable to control any network device be it a server, a switch, or any number of other devices such as network printers and fax machines. A host of emerging “smart” products including computer controlled appliances such as refrigerators and other kitchen appliances, climate control systems and medical devices can also be controlled.
  • The present subject matter is cross platform compatible since it is capable of running regardless of the platform because it is built in industry and standard protocols and is therefore not restricted to any given platform, thereby making a completely unique product.
  • The present subject matter will consist of a client and a number of servers. The client end would include a web browser interface enabling the utilization of HTTP compatibility with the SOAP which is designed specifically enable the transmission of XML payloads with special HTTP headers.
  • Every server of the present subject matter will run a parser filtering out the XML messages and sill translate these messages into necessary commands to be executed across network elements. The XML vocabulary will be translated into the necessary SNMP commands to be issued to the switches. The present subject matter will be scalable, thereby allowing for the addition of management capabilities by the integration of additional command protocols for communicating with other devices. The present subject matter will initially control devices that use the SNMP or Command Line Interface (CLI) protocol and can be scaled to add support for future protocols and devices as these become industry standards.
  • The architecture of the present subject matter allows a user to wrap existing or new communications equipment in a SOAP/XML wrapper, which would then allow for internet readiness or manageability via the internet anywhere in the world. The software wrapper is the computer program that understands object access protocol, i.e. contains a Protocol Virtual Machine (PVM), and runs on a single board computer, or on the hardware of the network element. A T-Box has a direct (not via the Internet) connection to the controlled network elements. The T-Box can communicate to the network elements via the Simple Network Management Protocol (SNMP) or Comment Line Interface (CLS) .Additionally, a network management system would be utilized with the SOAP/XML protocol as the foundation for inter-object communication.
  • The SOAP protocol extends the XML into the remote procedure call (RPC) paradigm in a standardized manner. The present subject matter extends the simple RPC paradigm to a more complex useful transaction-based approach whereby a “call” by user could be chained through a series of servers each providing a telecommunications management network (TMN) hierarchy management level over the internet. This web chaining of the SOAP requests is a unique enhancement.
  • The SOAP infrastructure is important to the technology of the present subject matter. Available SOAP parsers had to be broken up and modified into client and server side parsing engines. Along with the new parsers, the purposes of asynchronous identifications, a connection pooling mechanism was developed upon which the SOAP messages rode. The utilization of this system would allow network elements to be remotely controlled across a network.
  • Other and further advantages, objects and features of the subject matter will become apparent to those skilled in the art from a reading of the following detailed description of a preferred embodiment of the subject matter when taken in light of the accompanying drawings.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram showing the hardware of the present subject matter as well as an upward ordered message flow;
  • FIG. 2 is a block diagram of the present subject matter as well as showing a downward ordered message flow;
  • FIG. 3 is a diagram showing an alarm path flow;
  • FIG. 4 is a diagram showing alarm object communication and distribution; and
  • FIG. 5 is a diagram showing an alternate embodiment of the present subject matter.
  • FIG. 6 is a flow diagram showing the operation of the present subject matter.
  • DETAILED DESCRIPTION
  • The system design 10 of the present subject matter is shown in FIGS. 1 and 2. As shown therein, separate CPUs 12 and 14 would include portions of the system hardware of the present subject matter. Note that the application can have as many CPUs as servers. We have shown two CPUs only for clarity reasons. The CPU 12 would include a web browser 16 associated with a GUI which is an applet loaded by the web browser from the localized web server 20. This would prompt the user for data to perform a particular command. Once the required data is entered, the command is encoded into an HTTP-SOAP message. Although the drawings illustrate the utilization of two CPUs, the present subject matter can employ as many CPUs as there are servers. The use of only two CPUs in the present subject matter was for clarity purposes only.
  • In this subject matter, the implementation of the SOAP message is similar to SNMP format. It recognizes the Managed Information Base (MIB) tree as the representation of hardware component structure. The difference is that in existing implementations of SNMP messages are usually numeric. For example,
  • >Name-of-SNMP-program 10.3 set 23.21 11.11.2.12 2
  • The legend is: Name-of-SNMP-program node_address command (get/set) class.item object_id value.
  • Since SOAP is an XML based textual protocol, instead of numerals, it contains meaningful strings representing class, item, and object id in the component hierarchy. Within the SOAP envelope, the SNMP-like set of commands can be expanded if required.
  • Additionally, unlike most SNMP implementations, the present subject matter always guarantees the delivery of the message, referred to as “nailing connections”. The receiving server in our system always notifies the sender.
  • The second CPU 14 would include a web server (Apache) which is the entry point of the network management system of the present subject matter. The web server 20 would determine if the message is a SOAP message. If this is the case, it would strip off the HTTP header and forward the remaining SOAP/XML message to the SOAP server 22. This server is a servlet container which, upon receiving a SOAP message, a determination would be made to which server the message is destined. In this instance, the message will always be routed from or to a read/write server (RWS) 24. Upon receipt of the message from the SOAP server 22, the RWS 24 will store the data in a generic model in a relational database 30 in an object to relational table mapping. The RWS 24 will then forward or receive the message from a network management agent (NMA) 26.
  • The NMA 26 will then determine the course of action required for the particular type of request or command and build the appropriate model for it using G.855, G.85X recommendations as its basis. The NMA 26 will then forward commands to or receive comments from various network element agents (NEA) 28. Although a single NEA 28 is shown in FIGS. 1 and 2, it is noted that a number of NEAs can be employed. The NEA 28, upon receiving a nodal command from the NMA 26 will the build a M.3100 management model to support the nodal action. The NEA 28 will then forward a smaller command to a translation device (T-box) 32 for processing or translation. The T-box 32 then translates the SOAP command into the native language of the intended device such as network element 34, or SNMP.
  • The web browser 16 will generally be a third party provided browser. Most personal computers come with a preinstalled browser or can easily be downloaded. Both Netscape and Internet Explorer will be supported as both are Java enabled. However, it is also possible to use either front end applications written in any other computer language, as long as they are talk SOAP/XML. The web browser 16 will upload applets from the web server 18 for procedural contacts and communicate the network data transactions back to the web server 20 to be forwarded to the RWS 24. When a user is selecting a network element or set of network elements to perform an action, a network element record must already have been installed into the database 30 for that network element. The user will only be allowed to select from the list of network elements currently being managed. The web browser will also receive asynchronous events from the web server and display them.
  • The RWS 24 will receive or send user requests and store them in the database 30 as they are received. After a successful storage, a SOAP envelope will be sent to the NMA 26 to begin execution of the user request. The RWS 24 will also forward alarms to the web server 20 for display when it receives them from lower layer processors such as an NEA 28.
  • The NMA 26, when triggered by the RWS 24 will initiate processing of the user request. The NMA 26 will read and parse the SOAP request and then build a model required to satisfy that request. The NMA 26 will send a series of SOAP encoded singular node access requests to the NEA each with the data sufficient to satisfy the secondary request. Thus, a typical NMA network request is broken down into a set of simpler nodal requests. The NMA will implement a standard space model in order to satisfy the network management layer requirement. The NMA will process the request to either a successful or error termination condition. The NMA will log the cumulative status of the user request and also send a response SOAP packet back to the RWS 24 to be forwarded to the user. The NMA 26 will store the data required for each nodal requested to the database 30. Each NMA request and secondary NEA request all will have unique transaction Ids and database tables.
  • A Network Element Discovery server (NED) 25 can be provided between the NMA 26, the RWS 24 and the NEA 28 included in FIGS. 1 and 2. The NED will discover and store in the database 30 each network element's configuration. The configuration data may contain port, card, slot and shelf information. It may also discover the current set of provisional connections and their states.
  • The NED 25 will use the NEA 28 for access to the network elements in order to perform its discovery task. The NED will be used to populate the database tables initially. It will also perform an Audit/Learn function.
  • It is noted that a firewall 36 separates the web browser 16, the web server 20 and the SOAP server 22 from the remaining elements of the system.
  • The NEA 28 will be triggered from a SOAP envelope received from the NMA 26. The NEA will parse the XML document which encompasses the data necessary to complete a single nodal transaction. An M.3100 derivative model will be used to satisfy the elemental management layer requirement. The NEA 28 will proceed to
  • encode the appropriate SOAP packets to be delivered to one or more of the T-boxes 32 which are managing the network elements to where the request is destined. Although FIGS. 1 and 2 show the T-box 32 connected to a single network element 34, it can be appreciated that a single T-box can manage several network elements. To explain, one T-box can manage several network elements. When a success or failure message is received, the status is then stored in the database for logging purposes and then the status is sent back to the NMA 26.
  • The purpose of the database 30 is of course to store information. Once a user hits the appropriate button on the browser 16, an NMA request will be received by the RWS 24 and immediately stored in the database. Additionally, each NEA request is stored in the database before being processed by the NEA 28. Furthermore, the configuration of each network element is also stored in the database 30.
  • The T-box 32 contains embedded software. The T-box will be able to receive “M-GET”, “M-SET” and “M-ACTION” requests via the SOAP interface, as well as command line interfaces (CLI). The T-box will translate the SOAP command into the appropriate native console command (MML), (CLI) or SNMP, and send it via an ethernet interface to the actual network element in order to satisfy the given NEA request.
  • The HTTP-SOAP protocol provides the present subject matter a method of information exchange between functional components. Similar to any messaging protocol, it provides for data encapsulation with messages. The HTTP-SOAP protocol includes an envelope defining a framework for describing what is in a message and how to process it. It also includes a set of encoding rules for expressing instances of application defined data types as well as a convention for representing remote procedure calls and responses.
  • It is important to note that the T-box can control the network element from the applet directly to the T-box without control from additional servers. The applet is a JAVA program that runs within the web browser. However, any application written in any language can talk to the network element through the T-box using SOAP as one protocol.
  • An upward flow of data from a network element 34 to the web browser 16 in the first CPU 12 will now be described. The network element 34 sends a message to the T-box 32 over, perhaps, the ethernet as shown by Step 1. The T-box 32 includes a parser therein and utilizes the parser to translate the response received from the network element 34 into a SOAP response and sends this response to the NEA 28 at Step 2. It is noted that a plurality of NEAs would be utilized and the message relayed from the T-box 32 would be sent to the NEA 28 which is managing that particular network element. At Step 3, the NEA 28 forwards the nodal response created therein to the NMA 26. The NMA then forwards the entire transaction response to the RWS 24 at Step 4. The RWS 24 will then forward this response to the SOAP server 22 at Step 6, as well as to the database 30 at Step 5. The SOAP server 22 would then forward the response to the web server 20 which in turn would send the response back to the web browser 16 in the first CPU 12.
  • FIG. 2 illustrates a downward message flow from the CPU 12 ultimately to a network element 34. Initially, the web browser 16 will connect to the web server 20 at Step 2. In this case, the web server will automatically upload the
  • applet that will prompt the user for a command and a set of attributes used to control the network element 34. If authorized by the user, the web browser 16 would then be connected to the web server 20 in the second CPU 14 as shown by Step 2. At this point, the web browser will then build and send an HTTP-SOAP envelope to the web server 20. Upon receipt of the SOAP envelope, the web server 20 will immediately route it to the SOAP server 22 as shown by Step 3. Once the SOAP server 22 determines that a proper request has been made, it will be forwarded across the firewall 36 to the RWS server 24 as shown by Step 4. At Step 5, the RWS 24 will modify the request if required and then store it in the database 30. The RWS server will also forward the request to the NMA 26 as shown by Step 6. The NMA 26 will process this message and forward the necessary subcomponents to the proper NEA 28 for nodal processing. Step 8 indicates that the NEA 28 will forward the appropriate single-space command to the T-box 32. The T-box 32 will formulate and send the proper translation for the command to the network element 34 across the ethernet as shown by Step 9.
  • FIGS. 3 and 4 illustrate the alarm path network of the system of the present subject matter also indicating that the architecture is very scalable and allows for several NMAs as well as several NEAs and one or more GUIs and T-boxes. As alarms are received by the NEAs, they are immediately forwarded to the NMA for further processing and forwarding. Alarms can be received by the NEA at any time and are discriminated via the header field. Thus an in-progress provision cannot get confused with alarms being interpreted as responses. The directions of the alarm message will be from the Network Element to the T-Box and then to the NEA. The alarm will then proceed to the NMA, the RWS and the GUI (web browser). The alarms, by nature, go from the hardware equipment to the web browser.
  • A user that connects to the RWS from a GUI will register with the alarm distributor class for alarms. As alarms are received by the NEA, they are immediately forwarded to the NMAs for further processing and forwarding. Alarms can be received by the NEA at any time and are discriminated via the header field. The header attribute “alarm” indicates to the SOAP senders that this is an alarm data object. The body attributes contained in the rest of the alarm information. These attributes are such as NE name and message text.
  • The present subject matter employs a TCP/IP network with a connection to the internet. The network has a firewall between itself and the internet. It is possible for a network administrator to access and configure all equipment on the network through the use of telnet, SNMP, and other network management tools. These tools can only be used from behind the firewall. The firewall will, however, prevent these connections from being made from behind the firewall. With the present subject matter, it is now possible to HTTP connections which are still left open by the firewall to send in SNMP commands to the equipment beyond the firewall. This would allow the present subject matter to control the bandwidth being assigned to any part of network. This would also enable ISPs and other providers of bandwidth to sell bandwidth in a more dynamic manner because the bandwidth could be adjusted to meet demands more quickly and easily than currently possible.
  • The present subject matter also has the ability to allow a single network administrator to administer networks in different geographic locations. For example, if a service provider is located in Canada, network elements can be connected to a T-box in Canada utilizing a serial cable, an ethernet cable to a hub. The provider would then send email to a customer located, for example, in the United Kingdom confirming this connection. The customer would then email to an engineering technical support team located, for example, in China so that it can assign the correct IP addresses to the switches through a web interface. After these addresses are quickly assigned, the switches are registered for technical support if debugging will be required. The debugging of the switch can be done in various locations through the web interface. Once the registration is completed, the user will start provisioning of the network element using the web interface. Using one or more of the screens of the GUI, the provider in Canada will make selections relating to various equipment that must be connected. When the T-box in Canada receives a generic command, it will make a decision to translate this to CLI or SNMP for the network element. Most of the debugging commands usually include CLI access.
  • In a second scenario, several computers and peripheral devices are connected to one switch. It is noted that this switch can be used to enable or disable different ports that are used to connect the different devices together via the switch. Furthermore, the speed of the data that travels through these ports can also be altered.
  • In this manner, traffic can be regulated through the system. Alternatively, different virtual local area networks can be created and connected to that one switch. This is done for the purposes of isolating data that users can share on the computers or to isolate peripheral devices.
  • The present subject matter can be utilized to control “smart” devices such as computerized appliances and the like. In a home computerized environment, equipment can help the homeowner with climate control. The present subject matter can interface with electrical, wired or wireless devices or equipment. In such a scenario, the present subject matter can be used to program these devices and help in the automation process. The present subject matter is also capable of interfacing with wireless data systems and devices as well as interfacing with medical devices, distant learning equipment and various other telecommunications equipment.
  • The present subject matter offers a highly distributed network management application by using an XML based communication protocol. The translator for the XML based protocol to SNMP or TL1 can be embedded in a small hardware device serving as a web server controlling a number of network elements.
  • FIG. 5 illustrates an alternate embodiment of the present subject matter in which a user request is transmitted directly from a browser/application 40 to the T-box 48 and then to the network element or application 50 instead of proceeding directly through a database 42, network manager 44 and element manager 46 as illustrated in FIGS. 1 and 2. A graphical user interface (GUI) is used to control the communications between the browser/application 40 and the network element/application 50 directly through the T-box 48 or indirectly through the network manager 44 and element manager 46. As shown by the double headed arrows, communication is provided either upwardly or downwardly directly through the T-box 48 or indirectly through the T-box and database 42, network manager 44 and element manager 46.
  • The T-box 48 is provided with both a SOAP server as well as the PVM. The GUI is provided with two input devices on the screen. These input devices would indicate whether the user request is to proceed directly to the T-box 48 or via the network management system shown in FIGS. 1 and 2. As illustrated in FIG. 5, this network management system would include the database 42, the network manager 44 as well as the element manager 46. This is important since if the network management system is not operating, communication can still be provided from the browser application 40 directly to the T-box 48 and then to the network element/application 50. It is important to note that this communication can also proceed from the network application 50 to the T-box 48 and then directly to the browser/application 40. This is true since the T-box 48 can transfer a user request from a native language into SOAP as well as translate the SOAP packet into the native language.
  • The user can also specify whether a native command or generic command would be utilized. Generally, the user would not concern themselves with the command names that were given to a particular vendor. In this case, the user would utilize the generic command set. The GUI would include NE NAME as a pop down field automatically populated with the names of the network elements. For example, these names might correspond to LAB 7 Router, 1548M Cisco switch and UofORouter corresponding to the Cisco 7000 router.
  • The present subject matter utilizes the following commands: Connect, disconnect, setVlan, showVlan, setPortUp as well as setPortDown.
  • The input data includes parameters that the user can set. For example, in the case of the Virtual Lan (setVlan), the user can specify which port is connected to which Vlan. After making a selection, the user can submit the request. An applet will create the SOAP message and send it through the selected path. Request and reply log area will display the appropriate logs and the user interpretation view will display logs and alarms coming from the equipment.
  • It is noted that FIGS. 1 and 2 show the use of the present subject matter sending user requests from a browser/application to a network/application through at least one firewall. FIG. 5 indicates that the present application would also operate in a situation in which no firewalls are present. However, it is noted that all of the embodiments can operate with or without firewalls.
  • FIG. 6 is a flow diagram showing the operation a method 600 for communicating between an application source located on a first side of a firewall and a network element located on a second side of the firewall, according to the present subject matter. An applet to drive a user request is provided (Step 601). The applet is provided to the application source by a web server included on a first side of a firewall and sent to a read/write server provided on a second side of the firewall. A hypertext transfer protocol-simple object access protocol (HTTP-SOAP) packet of said user request is created (Step 603). The HTTP portion of the HTTP-SOAP packet is removed (Step 604) in order to create a SOAP message. A user request including the SOAP message is sent to the RWS (Step 605). The SOAP message is then sent to the NMA (Step 606). An appropriate model is built in the NMA (Step 607) and the SOAP encoded request is parsed in the NEA (Step 608) nea to complete a single nodal transaction. A SOAP encoded request is then sent from the NMA to the NEA (Step 616) and the SOAP encoded request is sent from the NMA to the NEA (Step 617). Data is encoded in the NEA to produce the SOAP packet (Step 619). The SOAP packet is transmitted to the translator box (Step 621) and the SOAP packet is translated into an appropriate command (Step 622). The command is transmitted to the network element (Step 624).
  • Whereas the preferred form of the present subject matter has been shown and described herein, it should be realized that there can be many modifications, substitutions and alterations thereto.

Claims (19)

What is claimed is:
1. A system for receiving communication from an application source and communicated from the application source to a network element, the system comprising:
at least one processing unit;
a routine to receive a communication containing a SOAP attribute over a communication protocol and providing the SOAP attribute over the communication protocol to the network element;
a routine receiving the SOAP attribute from the network element, including commands parsable by a network management application routine (NMA) receiving the communication;
a routine for parsing a SOAP message from the SOAP attribute by parsing the SOAP portion of the SOAP attribute to produce the SOAP message;
a translator routine, said translator routine receiving said SOAP message and translating said SOAP message into a command and/or data for the network element; and
a network element discovery (NED) routine for receiving said SOAP message from said NMA.
2. The system of claim 1, further comprising receiving the SOAP envelope over an underlying expanding messaging communication protocol of a user request provided by an application source for building the SOAP envelope over the underlying expanding messaging communication protocol of the user request provided by an underlying communication protocol server, and provides wherein the SOAP message parsed from the SOAP envelope over the underlying expanding messaging communication protocol.
3. The system for communicating as described in claim 2, comprising the underlying expanding messaging communication protocol implemented as HTTP, wherein said program code that builds a SOAP envelope over underlying communication protocol implements the underlying communication protocol as HTTP.
4. The system of claim 1 comprising a routine translating the SOAP message into corresponding command and/or data for the network element.
5. The system of claim 1 comprising means for receiving communications provided between network elements of SOAP commands and data over signaling and network communication protocols.
6. The system of claim 1, further comprising instructions to receive the SOAP envelope over underlying communication protocol of a user request provided by the application source for building the SOAP envelope over underlying communication protocol of the user request.
7. The system of claim 1, further comprising:
including commands parsable by a network management application routine (NMA) receiving the communication to translate said SOAP message into a command and/or data for the network element and permitting a network element agent routine (NEA) to parse said SOAP message to produce SOAP packets received from said NMA;
a network element discovery routine (NED) routine for receiving said SOAP message from said NMA, said SOAP message including network configuration data.
8. The system in accordance with claim 7, wherein said network configuration data includes port, card, slot and shelf information for a network element.
9. A computer program product comprising a computer-readable medium comprising program code executable on a first network device having a processing unit and accessing an application source for communication with a network element located on a second network device, comprising:
program code that builds a SOAP envelope over underlying communication protocol of a user request; and
program code that transmits said SOAP envelope over underlying communication protocol to an underlying communication protocol server capable of providing transmissions according to an underlying communication protocol, said SOAP message parsable from said SOAP envelope in the case of said SOAP envelope transmitted over underlying communication protocol, including commands parsable by a network management application routine (NMA); and
program code comprising a network element discovery routine (NED) routine for receiving said SOAP message from said NMA.
10. The computer program product as described in claim 9, wherein said program code that builds a SOAP envelope over underlying communication protocol implements the underlying communication protocol as HTTP.
11. The computer program product as described in claim 9, further comprising the SOAP envelope providing translation of the soap message into a command and/or data for building of said user request as a command and/or data for the second network device.
12. The computer program product as described in claim 9, further comprising instructions to receive the SOAP envelope over underlying communication protocol of a user request provided by the application source for building the SOAP envelope over underlying communication protocol of the user request.
13. The computer program product as described in claim 9, wherein the first network device has a location on a first side of a firewall and the second network device has a location on a second side of the firewall.
14. The computer program product as described in claim 13, wherein the first side of the firewall constitutes a protected side of the firewall.
15. Means, using at least one processing unit, for communicating messages from an application source for reception by a network element located across a firewall, comprising:
computer program means provided in the application source at a first side of the firewall for building an SOAP envelope over an underlying expanding messaging communication protocol of a user request;
computer program means provided in the application source for providing said SOAP envelope over the underlying expanding messaging communication protocol to an underlying communication protocol server compatible with web communication at the first side of the firewall;
computer program means provided in a network element agent server for receiving said SOAP envelope over the underlying expanding messaging communication protocol from the underlying communication protocol server; and
computer program means for sending a SOAP message from the SOAP envelope over the underlying expanding messaging communication protocol by parsing the SOAP portion of the SOAP envelope over the underlying expanding messaging communication protocol to produce the SOAP message, in a format suitable for transmission across the firewall, including commands parsable by a network management application routine (NMA) receiving the transmission across the firewall to translate said SOAP message into a command and/or data for the network element and permitting a network element agent routine (NEA) provided at the second side of the firewall to parse said SOAP message to produce SOAP packets received from said NMA.
16. The system for communicating as described in claim 15, comprising the underlying expanding messaging communication protocol implemented as HTTP.
17. The system in accordance with claim 15, comprising the computer program means for parsing the SOAP message from the SOAP envelope over the underlying expanding messaging communication protocol at the first side of the firewall.
18. The system in accordance with claim 15, further including a network element discovery routine (NED) routine for receiving said SOAP message from said NMA provided at the second side of the firewall, said SOAP message including network configuration data.
19. The system in accordance with claim 18, wherein said network configuration data includes port, card, slot and shelf information for a network element.
US14/453,487 2000-05-31 2014-08-06 Object Oriented Communication Among Platform Independent Systems over Networks Using SOAP Abandoned US20150134845A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/453,487 US20150134845A1 (en) 2000-05-31 2014-08-06 Object Oriented Communication Among Platform Independent Systems over Networks Using SOAP

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US20804500P 2000-05-31 2000-05-31
US24270800P 2000-10-25 2000-10-25
US09/867,469 US7007094B1 (en) 2001-05-31 2001-05-31 Object oriented communications system over the internet
US09/900,041 US7136913B2 (en) 2000-05-31 2001-07-09 Object oriented communication among platform independent systems across a firewall over the internet using HTTP-SOAP
US11/510,760 US7325053B2 (en) 2000-05-31 2006-08-28 Object oriented communication among platform-independent systems over networks using SOAP
US11/976,509 US7734756B2 (en) 2000-05-31 2007-10-25 Object oriented communication among platform independent systems over networks using soap
US12/795,329 US20100274895A1 (en) 2000-05-31 2010-06-07 Object oriented communication among platform independent systems over networks using soap
US14/453,487 US20150134845A1 (en) 2000-05-31 2014-08-06 Object Oriented Communication Among Platform Independent Systems over Networks Using SOAP

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/795,329 Continuation US20100274895A1 (en) 2000-05-31 2010-06-07 Object oriented communication among platform independent systems over networks using soap

Publications (1)

Publication Number Publication Date
US20150134845A1 true US20150134845A1 (en) 2015-05-14

Family

ID=37568926

Family Applications (5)

Application Number Title Priority Date Filing Date
US09/900,041 Expired - Fee Related US7136913B2 (en) 2000-05-31 2001-07-09 Object oriented communication among platform independent systems across a firewall over the internet using HTTP-SOAP
US11/510,760 Expired - Fee Related US7325053B2 (en) 2000-05-31 2006-08-28 Object oriented communication among platform-independent systems over networks using SOAP
US11/976,509 Expired - Fee Related US7734756B2 (en) 2000-05-31 2007-10-25 Object oriented communication among platform independent systems over networks using soap
US12/795,329 Abandoned US20100274895A1 (en) 2000-05-31 2010-06-07 Object oriented communication among platform independent systems over networks using soap
US14/453,487 Abandoned US20150134845A1 (en) 2000-05-31 2014-08-06 Object Oriented Communication Among Platform Independent Systems over Networks Using SOAP

Family Applications Before (4)

Application Number Title Priority Date Filing Date
US09/900,041 Expired - Fee Related US7136913B2 (en) 2000-05-31 2001-07-09 Object oriented communication among platform independent systems across a firewall over the internet using HTTP-SOAP
US11/510,760 Expired - Fee Related US7325053B2 (en) 2000-05-31 2006-08-28 Object oriented communication among platform-independent systems over networks using SOAP
US11/976,509 Expired - Fee Related US7734756B2 (en) 2000-05-31 2007-10-25 Object oriented communication among platform independent systems over networks using soap
US12/795,329 Abandoned US20100274895A1 (en) 2000-05-31 2010-06-07 Object oriented communication among platform independent systems over networks using soap

Country Status (1)

Country Link
US (5) US7136913B2 (en)

Families Citing this family (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7216043B2 (en) * 1997-02-12 2007-05-08 Power Measurement Ltd. Push communications architecture for intelligent electronic devices
US7296274B2 (en) * 1999-11-15 2007-11-13 Sandia National Laboratories Method and apparatus providing deception and/or altered execution of logic in an information system
US7136913B2 (en) * 2000-05-31 2006-11-14 Lab 7 Networks, Inc. Object oriented communication among platform independent systems across a firewall over the internet using HTTP-SOAP
US8600783B2 (en) 2000-08-18 2013-12-03 The Crawford Group, Inc. Business to business computer system for communicating and processing rental car reservations using web services
US7275038B1 (en) * 2000-08-18 2007-09-25 The Crawford Group, Inc. Web enabled business to business operating system for rental car services
US7899690B1 (en) 2000-08-18 2011-03-01 The Crawford Group, Inc. Extended web enabled business to business computer system for rental vehicle services
FR2813471B1 (en) * 2000-08-31 2002-12-20 Schneider Automation COMMUNICATION SYSTEM FOR AUTOMATED EQUIPMENT BASED ON THE SOAP PROTOCOL
US6934756B2 (en) * 2000-11-01 2005-08-23 International Business Machines Corporation Conversational networking via transport, coding and control conversational protocols
US7302634B2 (en) 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US7155496B2 (en) * 2001-05-15 2006-12-26 Occam Networks Configuration management utilizing generalized markup language
US7685508B2 (en) 2001-05-15 2010-03-23 Occam Networks Device monitoring via generalized markup language
DE10129322A1 (en) * 2001-06-19 2003-01-02 Siemens Ag Central administration of a call center
US20030051018A1 (en) * 2001-08-29 2003-03-13 Prathivadi Bayankara Giri Parthasarathy Light weight application management system
CA2359382A1 (en) * 2001-10-19 2003-04-19 Intrinsyc Software, Inc. Method of providing web services on embedded device
US7392391B2 (en) * 2001-11-01 2008-06-24 International Business Machines Corporation System and method for secure configuration of sensitive web services
US7475126B2 (en) * 2002-03-15 2009-01-06 Nortel Networks Limited Method and apparatus for system lineup and testing
FR2838593A1 (en) * 2002-04-12 2003-10-17 Michel Gouget Internet protocol remote maintenance/administration/file transfer having client connection responding server demands with first demand containing protocol/limiting response repetition.
EP1499963A2 (en) * 2002-04-29 2005-01-26 Siemens Aktiengesellschaft Automation device comprising an interface for the message-based and port-based access to an application
US20030212898A1 (en) * 2002-05-09 2003-11-13 Doug Steele System and method for remotely monitoring and deploying virtual support services across multiple virtual lans (VLANS) within a data center
JP2004046817A (en) * 2002-05-23 2004-02-12 Ricoh Co Ltd Program, storage medium, data management device, and data management system
US8108231B2 (en) * 2002-06-14 2012-01-31 The Crawford Group, Inc. Method and apparatus for improved customer direct on-line reservation of rental vehicles
US20040039612A1 (en) * 2002-06-14 2004-02-26 Neil Fitzgerald Method and apparatus for customer direct on-line reservation of rental vehicles
US9886309B2 (en) 2002-06-28 2018-02-06 Microsoft Technology Licensing, Llc Identity-based distributed computing for device resources
US8301800B1 (en) * 2002-07-02 2012-10-30 Actional Corporation Message processing for distributed computing environments
US7415503B2 (en) * 2002-07-12 2008-08-19 Honeywell International Inc. Control interface agent system and method
FR2842623B1 (en) * 2002-07-19 2004-10-01 Canon Kk METHOD FOR TRANSLATING A MESSAGE FROM A FIRST LANGUAGE LANGUAGE INTO A SECOND LANGUAGE LANGUAGE
AU2012203328B2 (en) * 2002-07-19 2014-07-31 Open Invention Network, Llc Electronic commerce community networks and intra/inter community secure routing implementation
US7200674B2 (en) * 2002-07-19 2007-04-03 Open Invention Network, Llc Electronic commerce community networks and intra/inter community secure routing implementation
NZ539830A (en) * 2002-10-10 2005-10-28 Intec Telecom Systems Plc Systems and methods for maintaining and distributing a commerce catalogue
US20040088395A1 (en) * 2002-10-30 2004-05-06 O'konski Timothy Method for probing a server
US7467391B2 (en) * 2002-10-30 2008-12-16 International Business Machines Corporation Allowing client applications to programmatically access web sites
DE10253548A1 (en) * 2002-11-15 2004-06-03 Db Systems Gmbh communication server
US7933983B2 (en) * 2002-12-17 2011-04-26 Hewlett-Packard Development Company, L.P. Method and system for performing load balancing across control planes in a data center
US20040205216A1 (en) * 2003-03-19 2004-10-14 Ballinger Keith W. Efficient message packaging for transport
EP1614255B1 (en) * 2003-04-04 2014-09-03 CA, Inc. Method and system for discovery of remote agents
US20050014121A1 (en) * 2003-07-15 2005-01-20 Hagen Eck Integrating an external course into an electronic learning system
US20050060376A1 (en) * 2003-09-12 2005-03-17 Moran Neal P. Secure computer telephony integration access
US20050108316A1 (en) * 2003-11-18 2005-05-19 Sbc Knowledge Ventures, L.P. Methods and systems for organizing related communications
US7685265B1 (en) * 2003-11-20 2010-03-23 Microsoft Corporation Topic-based notification service
US7676562B2 (en) * 2004-01-20 2010-03-09 Microsoft Corporation Computer system for accessing instrumentation information
JP2005301999A (en) * 2004-03-19 2005-10-27 Ricoh Co Ltd Remote management system, device to be managed by same, communication control method, program, and recording medium
US7502999B1 (en) * 2004-04-02 2009-03-10 Sun Microsystems, Inc. Automatically exposing command line interface commands as web services
US20050267995A1 (en) * 2004-04-29 2005-12-01 Newisys, Inc. Facilitating system management functionality via interaction between hardware domains
US7702724B1 (en) * 2004-05-27 2010-04-20 Oracle America, Inc. Web services message broker architecture
US20050288044A1 (en) * 2004-06-28 2005-12-29 International Business Machines Corporation System and method for using soap to invoke web services on handheld devices
EP1617329A1 (en) * 2004-07-13 2006-01-18 Alcatel Method of generating services
DE602004017606D1 (en) * 2004-09-17 2008-12-18 Alcatel Lucent Device for exchanging messages between customer devices (CPE) and servers
US7483994B1 (en) 2004-11-01 2009-01-27 Ameriprise Financial, Inc. System and method for creating a standard envelope structure
US8296354B2 (en) * 2004-12-03 2012-10-23 Microsoft Corporation Flexibly transferring typed application data
US20060143256A1 (en) 2004-12-28 2006-06-29 Galin Galchev Cache region concept
US7539821B2 (en) 2004-12-28 2009-05-26 Sap Ag First in first out eviction implementation
US7971001B2 (en) 2004-12-28 2011-06-28 Sap Ag Least recently used eviction implementation
US7552284B2 (en) * 2004-12-28 2009-06-23 Sap Ag Least frequently used eviction implementation
US7451275B2 (en) * 2004-12-28 2008-11-11 Sap Ag Programming models for storage plug-ins
US7523263B2 (en) * 2004-12-28 2009-04-21 Michael Wintergerst Storage plug-in based on shared closures
US8204931B2 (en) 2004-12-28 2012-06-19 Sap Ag Session management within a multi-tiered enterprise network
US7672949B2 (en) * 2004-12-28 2010-03-02 Sap Ag Connection manager having a common dispatcher for heterogeneous software suites
US7694065B2 (en) 2004-12-28 2010-04-06 Sap Ag Distributed cache architecture
US20060168229A1 (en) * 2004-12-29 2006-07-27 Shim Choon B System and method for network management using extensible markup language
WO2006080026A1 (en) * 2005-01-27 2006-08-03 Infosys Technologies Limited Protocol processing device and method
US20060187849A1 (en) * 2005-02-22 2006-08-24 Mohamed Hamedi Interpreter engine
US7831634B2 (en) 2005-04-29 2010-11-09 Sap Ag Initializing a cache region using a generated cache region configuration structure
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US7689660B2 (en) 2005-06-09 2010-03-30 Sap Ag Application server architecture
US20060289983A1 (en) * 2005-06-22 2006-12-28 Silent Solutions Llc System, method and device for reducing electromagnetic emissions and susceptibility from electrical and electronic devices
US7966412B2 (en) * 2005-07-19 2011-06-21 Sap Ag System and method for a pluggable protocol handler
US8707323B2 (en) 2005-12-30 2014-04-22 Sap Ag Load balancing algorithm for servicing client requests
US8087031B2 (en) * 2006-01-09 2011-12-27 Oracle America, Inc. Method and apparatus for data transfer between isolated execution contexts
US20070177583A1 (en) * 2006-01-31 2007-08-02 Microsoft Corporation Partial message streaming
US8271309B2 (en) 2006-03-16 2012-09-18 The Crawford Group, Inc. Method and system for providing and administering online rental vehicle reservation booking services
US20070294116A1 (en) * 2006-06-14 2007-12-20 Scott Paul Stephens Method and system for an online rental vehicle reservation-booking website including a travel agent path
US7827263B1 (en) * 2006-08-30 2010-11-02 Crimson Corporation Systems and methods for managing a computer over a network
CA2664941C (en) * 2006-10-06 2017-09-12 The Crawford Group, Inc. Method and system for communicating vehicle repair information to a business-to-business rental vehicle reservation management computer system
US20080097798A1 (en) * 2006-10-18 2008-04-24 The Crawford Group, Inc. Method and System for Creating and Processing Rental Vehicle Reservations Using Vouchers
US8160906B2 (en) 2006-12-12 2012-04-17 The Crawford Group, Inc. System and method for improved rental vehicle reservation management
CN100578458C (en) * 2007-03-22 2010-01-06 华为技术有限公司 Call request processing method in distributed system, distributed system and server
US20090006594A1 (en) * 2007-06-27 2009-01-01 Avigdor Eldar Method and system for remote manageability of networked computers
US8429328B2 (en) * 2007-06-29 2013-04-23 Sandisk Technologies Inc. System for communicating with a non-volatile memory storage device
US8433842B2 (en) * 2007-06-29 2013-04-30 Sandisk Technologies Inc. Method for communicating with a non-volatile memory storage device
US8160907B2 (en) 2007-07-25 2012-04-17 The Crawford Group, Inc. System and method for allocating replacement vehicle rental costs using a virtual bank of repair facility credits
EP2073440A1 (en) * 2007-12-21 2009-06-24 Alcatel Lucent Method, command converter and automatic configuration server for remote management of embedded devices
US8082312B2 (en) * 2008-12-12 2011-12-20 Event Medical, Inc. System and method for communicating over a network with a medical device
US8234259B2 (en) * 2009-05-08 2012-07-31 Raytheon Company Method and system for adjudicating text against a defined policy
US8954955B2 (en) * 2009-06-16 2015-02-10 Google Inc. Standard commands for native commands
US9021510B2 (en) * 2009-12-04 2015-04-28 International Business Machines Corporation Remote procedure call (RPC) bind service with physical interface query and selection
US9432825B2 (en) * 2010-01-13 2016-08-30 Oracle International Corporation Systems and methods for integrating a service access gateway with billing and revenue management systems
US8171094B2 (en) * 2010-01-19 2012-05-01 Event Medical, Inc. System and method for communicating over a network with a medical device
US8988708B2 (en) 2010-08-18 2015-03-24 Samsung Electronics Co., Ltd. Host device to monitor status of image forming apparatus and control method thereof
WO2012166927A1 (en) * 2011-06-02 2012-12-06 Numerex Corp. Wireless snmp agent gateway
US8990286B2 (en) 2012-04-12 2015-03-24 Oracle International Corporation Integration of web services with a clustered actor based model
US8856735B2 (en) 2012-07-25 2014-10-07 Oracle International Corporation System and method of generating REST2REST services from WADL
US8924557B2 (en) 2012-08-13 2014-12-30 Oracle International Corporation System and method for supporting session threshold for IMS SCIM/service brokering
US8949441B2 (en) 2012-08-13 2015-02-03 Oracle International Corporation System and method for optimizing media resource for IMS SCIM/service brokering
US9378060B2 (en) 2012-08-28 2016-06-28 Oracle International Corporation Runtime co-location of executing logic and frequently-accessed application data
US9654299B2 (en) 2012-09-19 2017-05-16 Oracle International Corporation Execution framework for policy management
US9736034B2 (en) 2012-09-19 2017-08-15 Oracle International Corporation System and method for small batching processing of usage requests
US9672011B2 (en) 2012-11-07 2017-06-06 Oracle International Corporation System and method for composing a telecommunication application by orchestrating application components
US9412262B2 (en) 2013-01-24 2016-08-09 L&P Property Management Company Wireless two-way communication protocol for automated furniture accessory integration
US9514637B2 (en) * 2013-01-24 2016-12-06 L & P Property Management Company Wireless two-way communication protocol for automated furniture accessory integration
US9648049B2 (en) 2013-02-04 2017-05-09 Oracle International Corporation System and method for extending IP multimedia subsystem to HTML5 environments
US9307031B2 (en) 2013-02-04 2016-04-05 Oracle International Corporation Generic model for customizing protocol behavior through javascript
US9712593B2 (en) 2013-02-04 2017-07-18 Oracle International Corporation Javascript API for WebRTC
US10476915B2 (en) 2013-02-04 2019-11-12 Oracle International Corporation Real-time communication signaling gateway
US9473581B2 (en) 2013-02-04 2016-10-18 Oracle International Corporation Integrated web-enabled session border controller
US9331967B2 (en) 2013-02-04 2016-05-03 Oracle International Corporation Browser/HTML friendly protocol for real-time communication signaling
US9509745B2 (en) 2013-02-04 2016-11-29 Oracle International Corporation Java API for programming web real-time communication applications
CN106209934A (en) * 2015-04-30 2016-12-07 西门子瑞士有限公司 Control device in fire alarm system and collocation method thereof
CN105138609B (en) * 2015-08-04 2019-07-30 广东瑞德智能科技股份有限公司 A kind of household appliance based on XML language describes method
US10489418B2 (en) * 2015-10-09 2019-11-26 Bank Of America Corporation System for inline message detail extraction and transformation
CN108833135B (en) * 2018-05-04 2023-06-06 深圳市共进电子股份有限公司 Mesh networking management method, management equipment and extender

Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734831A (en) * 1996-04-26 1998-03-31 Sun Microsystems, Inc. System for configuring and remotely administering a unix computer over a network
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US6088796A (en) * 1998-08-06 2000-07-11 Cianfrocca; Francis Secure middleware and server control system for querying through a network firewall
US6115745A (en) * 1997-11-25 2000-09-05 International Business Machines Corporation Scheduling of distributed agents in a dialup network
US6189042B1 (en) * 1997-04-09 2001-02-13 Alcatel LAN internet connection having effective mechanism to classify LAN traffic and resolve address resolution protocol requests
US20010023442A1 (en) * 1999-07-15 2001-09-20 Richard R. Masters Method and system for storing load balancing information with an http cookie
US20010032254A1 (en) * 1998-05-29 2001-10-18 Jeffrey C. Hawkins Method and apparatus for wireless internet access
US20010047415A1 (en) * 2000-01-31 2001-11-29 Skene Bryan D. Method and system for enabling persistent access to virtual servers by an ldns server
US20010052024A1 (en) * 1996-12-23 2001-12-13 Murthy V. Devarakonda Affinity-based router and routing method
US20020019844A1 (en) * 2000-07-06 2002-02-14 Kurowski Scott J. Method and system for network-distributed computing
US20020048269A1 (en) * 2000-08-04 2002-04-25 Hong Jack L. Intelligent demand driven recognition of URL objects in connection oriented transactions
US20020052941A1 (en) * 2000-02-11 2002-05-02 Martin Patterson Graphical editor for defining and creating a computer system
US6389448B1 (en) * 1999-12-06 2002-05-14 Warp Solutions, Inc. System and method for load balancing
US20020103846A1 (en) * 1998-07-15 2002-08-01 Radware Ltd. Load balancing
US6505254B1 (en) * 1999-04-19 2003-01-07 Cisco Technology, Inc. Methods and apparatus for routing requests in a network
US6513069B1 (en) * 1996-03-08 2003-01-28 Actv, Inc. Enhanced video programming system and method for providing a distributed community network
US6578066B1 (en) * 1999-09-17 2003-06-10 Alteon Websystems Distributed load-balancing internet servers
US6578068B1 (en) * 1999-08-31 2003-06-10 Accenture Llp Load balancer in environment services patterns
US6598077B2 (en) * 1999-12-06 2003-07-22 Warp Solutions, Inc. System and method for dynamic content routing
US6606708B1 (en) * 1997-09-26 2003-08-12 Worldcom, Inc. Secure server architecture for Web based data management
US6611861B1 (en) * 1998-02-27 2003-08-26 Xo Communications, Inc. Internet hosting and access system and method
US6658473B1 (en) * 2000-02-25 2003-12-02 Sun Microsystems, Inc. Method and apparatus for distributing load in a computer environment
US6667980B1 (en) * 1999-10-21 2003-12-23 Sun Microsystems, Inc. Method and apparatus for providing scalable services using a packet distribution table
US6678733B1 (en) * 1999-10-26 2004-01-13 At Home Corporation Method and system for authorizing and authenticating users
US6687746B1 (en) * 1999-08-30 2004-02-03 Ideaflood, Inc. System apparatus and method for hosting and assigning domain names on a wide area network
US6691165B1 (en) * 1998-11-10 2004-02-10 Rainfinity, Inc. Distributed server cluster for controlling network traffic
US6701363B1 (en) * 2000-02-29 2004-03-02 International Business Machines Corporation Method, computer program product, and system for deriving web transaction performance metrics
US6718383B1 (en) * 2000-06-02 2004-04-06 Sun Microsystems, Inc. High availability networking with virtual IP address failover
US6728780B1 (en) * 2000-06-02 2004-04-27 Sun Microsystems, Inc. High availability networking with warm standby interface failover
US6728748B1 (en) * 1998-12-01 2004-04-27 Network Appliance, Inc. Method and apparatus for policy based class of service and adaptive service level management within the context of an internet and intranet
US6732186B1 (en) * 2000-06-02 2004-05-04 Sun Microsystems, Inc. High availability networking with quad trunking failover
US6799177B1 (en) * 1999-05-05 2004-09-28 Verizon Corporate Services Group Inc. Systems and methods for securing extranet transactions
US6813611B1 (en) * 1999-06-08 2004-11-02 International Business Machines Corporation Controlling, configuring, storing, monitoring and maintaining accounting of bookkeeping information employing trees with nodes having embedded information
US6954777B1 (en) * 1999-07-29 2005-10-11 International Business Machines Corporation Method for extending capabilities of an arbitrary web server

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0700229B1 (en) * 1994-08-22 2006-06-28 Fujitsu Limited Connectionless communications system, test method, and intra-station control system
US5544154A (en) * 1995-03-09 1996-08-06 Telefonaktiebolaget Lm Ericsson Method for determining the load induced by a routing verification test on a network
US6457066B1 (en) * 1997-11-10 2002-09-24 Microsoft Corporation Simple object access protocol
US5999179A (en) * 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6219786B1 (en) * 1998-09-09 2001-04-17 Surfcontrol, Inc. Method and system for monitoring and controlling network access
US6483841B1 (en) * 1999-03-02 2002-11-19 Accton Technology Corporation System and method for reducing capacity demand of ethernet switch controller
US7149965B1 (en) * 1999-08-10 2006-12-12 Microsoft Corporation Object persister
US6772216B1 (en) * 2000-05-19 2004-08-03 Sun Microsystems, Inc. Interaction protocol for managing cross company processes among network-distributed applications
AU2001264944A1 (en) * 2000-05-25 2001-12-03 Transacttools, Inc. A method, system and apparatus for establishing, monitoring, and managing connectivity for communication among heterogeneous systems
US7007094B1 (en) * 2001-05-31 2006-02-28 Lab 7 Networks, Inc. Object oriented communications system over the internet
US7136913B2 (en) * 2000-05-31 2006-11-14 Lab 7 Networks, Inc. Object oriented communication among platform independent systems across a firewall over the internet using HTTP-SOAP
US7188158B1 (en) * 2000-07-15 2007-03-06 Hewlett-Packard Development Company, L.P. System and method for component-based software development
US8250570B2 (en) * 2000-10-31 2012-08-21 Hewlett-Packard Development Company, L.P. Automated provisioning framework for internet site servers
US6970935B1 (en) * 2000-11-01 2005-11-29 International Business Machines Corporation Conversational networking via transport, coding and control conversational protocols
US20020099738A1 (en) * 2000-11-22 2002-07-25 Grant Hugh Alexander Automated web access for back-end enterprise systems
US6996778B2 (en) * 2000-12-11 2006-02-07 Microsoft Corporation User interface for managing multiple network resources
US6816871B2 (en) * 2000-12-22 2004-11-09 Oblix, Inc. Delivering output XML with dynamically selectable processing
US20020161826A1 (en) * 2001-01-25 2002-10-31 Carlos Arteaga System and method for remote communication transactions
US7085824B2 (en) * 2001-02-23 2006-08-01 Power Measurement Ltd. Systems for in the field configuration of intelligent electronic devices
US7302634B2 (en) * 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US20020157023A1 (en) * 2001-03-29 2002-10-24 Callahan John R. Layering enterprise application services using semantic firewalls
US20030005412A1 (en) * 2001-04-06 2003-01-02 Eanes James Thomas System for ontology-based creation of software agents from reusable components
US20020147745A1 (en) * 2001-04-09 2002-10-10 Robert Houben Method and apparatus for document markup language driven server
US7152109B2 (en) * 2001-04-20 2006-12-19 Opsware, Inc Automated provisioning of computing networks according to customer accounts using a network database data model
US20030036917A1 (en) * 2001-04-25 2003-02-20 Metallect Corporation Service provision system and method
US7325047B2 (en) * 2001-05-23 2008-01-29 International Business Machines Corporation Dynamic undeployment of services in a computing network

Patent Citations (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6513069B1 (en) * 1996-03-08 2003-01-28 Actv, Inc. Enhanced video programming system and method for providing a distributed community network
US5734831A (en) * 1996-04-26 1998-03-31 Sun Microsystems, Inc. System for configuring and remotely administering a unix computer over a network
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US20010052024A1 (en) * 1996-12-23 2001-12-13 Murthy V. Devarakonda Affinity-based router and routing method
US6189042B1 (en) * 1997-04-09 2001-02-13 Alcatel LAN internet connection having effective mechanism to classify LAN traffic and resolve address resolution protocol requests
US6606708B1 (en) * 1997-09-26 2003-08-12 Worldcom, Inc. Secure server architecture for Web based data management
US6115745A (en) * 1997-11-25 2000-09-05 International Business Machines Corporation Scheduling of distributed agents in a dialup network
US6611861B1 (en) * 1998-02-27 2003-08-26 Xo Communications, Inc. Internet hosting and access system and method
US20010032254A1 (en) * 1998-05-29 2001-10-18 Jeffrey C. Hawkins Method and apparatus for wireless internet access
US20020103846A1 (en) * 1998-07-15 2002-08-01 Radware Ltd. Load balancing
US6088796A (en) * 1998-08-06 2000-07-11 Cianfrocca; Francis Secure middleware and server control system for querying through a network firewall
US6691165B1 (en) * 1998-11-10 2004-02-10 Rainfinity, Inc. Distributed server cluster for controlling network traffic
US6728748B1 (en) * 1998-12-01 2004-04-27 Network Appliance, Inc. Method and apparatus for policy based class of service and adaptive service level management within the context of an internet and intranet
US6505254B1 (en) * 1999-04-19 2003-01-07 Cisco Technology, Inc. Methods and apparatus for routing requests in a network
US6799177B1 (en) * 1999-05-05 2004-09-28 Verizon Corporate Services Group Inc. Systems and methods for securing extranet transactions
US6813611B1 (en) * 1999-06-08 2004-11-02 International Business Machines Corporation Controlling, configuring, storing, monitoring and maintaining accounting of bookkeeping information employing trees with nodes having embedded information
US6374300B2 (en) * 1999-07-15 2002-04-16 F5 Networks, Inc. Method and system for storing load balancing information with an HTTP cookie
US6473802B2 (en) * 1999-07-15 2002-10-29 F5 Networks, Inc. Method and system for storing load balancing information with an HTTP cookie
US20020040400A1 (en) * 1999-07-15 2002-04-04 F5 Networks, Inc. Method and system for storing load balancing information with an HTTP cookie
US20010023442A1 (en) * 1999-07-15 2001-09-20 Richard R. Masters Method and system for storing load balancing information with an http cookie
US6954777B1 (en) * 1999-07-29 2005-10-11 International Business Machines Corporation Method for extending capabilities of an arbitrary web server
US6687746B1 (en) * 1999-08-30 2004-02-03 Ideaflood, Inc. System apparatus and method for hosting and assigning domain names on a wide area network
US6578068B1 (en) * 1999-08-31 2003-06-10 Accenture Llp Load balancer in environment services patterns
US6578066B1 (en) * 1999-09-17 2003-06-10 Alteon Websystems Distributed load-balancing internet servers
US6667980B1 (en) * 1999-10-21 2003-12-23 Sun Microsystems, Inc. Method and apparatus for providing scalable services using a packet distribution table
US6678733B1 (en) * 1999-10-26 2004-01-13 At Home Corporation Method and system for authorizing and authenticating users
US6389448B1 (en) * 1999-12-06 2002-05-14 Warp Solutions, Inc. System and method for load balancing
US6598077B2 (en) * 1999-12-06 2003-07-22 Warp Solutions, Inc. System and method for dynamic content routing
US20030158951A1 (en) * 1999-12-06 2003-08-21 Leonard Primak System and method for dynamic content routing
US20010047415A1 (en) * 2000-01-31 2001-11-29 Skene Bryan D. Method and system for enabling persistent access to virtual servers by an ldns server
US20020052941A1 (en) * 2000-02-11 2002-05-02 Martin Patterson Graphical editor for defining and creating a computer system
US6658473B1 (en) * 2000-02-25 2003-12-02 Sun Microsystems, Inc. Method and apparatus for distributing load in a computer environment
US6701363B1 (en) * 2000-02-29 2004-03-02 International Business Machines Corporation Method, computer program product, and system for deriving web transaction performance metrics
US6718383B1 (en) * 2000-06-02 2004-04-06 Sun Microsystems, Inc. High availability networking with virtual IP address failover
US6728780B1 (en) * 2000-06-02 2004-04-27 Sun Microsystems, Inc. High availability networking with warm standby interface failover
US6732186B1 (en) * 2000-06-02 2004-05-04 Sun Microsystems, Inc. High availability networking with quad trunking failover
US20020019844A1 (en) * 2000-07-06 2002-02-14 Kurowski Scott J. Method and system for network-distributed computing
US20020073232A1 (en) * 2000-08-04 2002-06-13 Jack Hong Non-intrusive multiplexed transaction persistency in secure commerce environments
US20020048269A1 (en) * 2000-08-04 2002-04-25 Hong Jack L. Intelligent demand driven recognition of URL objects in connection oriented transactions

Also Published As

Publication number Publication date
US7734756B2 (en) 2010-06-08
US20020032790A1 (en) 2002-03-14
US7136913B2 (en) 2006-11-14
US7325053B2 (en) 2008-01-29
US20080059654A1 (en) 2008-03-06
US20060294253A1 (en) 2006-12-28
US20100274895A1 (en) 2010-10-28

Similar Documents

Publication Publication Date Title
US7734756B2 (en) Object oriented communication among platform independent systems over networks using soap
US6167448A (en) Management event notification system using event notification messages written using a markup language
US5961594A (en) Remote node maintenance and management method and system in communication networks using multiprotocol agents
US5742762A (en) Network management gateway
US6490617B1 (en) Active self discovery of devices that participate in a network
US5978845A (en) Network management relay mechanism
US5987513A (en) Network management using browser-based technology
US20050273593A1 (en) Method and system for filtering and suppression of telemetry data
EP0762281B1 (en) Network management with acquisition of formatted dump data from remote process
EP1720286A2 (en) Network management system and method
US7007094B1 (en) Object oriented communications system over the internet
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Using the Protocol Translator
Cisco Protocol Translator User Commands
Cisco Protocol Translator User Commands
Cisco Protocol Translator User Commands
Cisco Terminal Server User Commands
Cisco Terminal Server User Commands
Cisco Terminal Server User Commands

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION