Techniques for interfacing between a web service and an interface description language (IDL)-based remote procedure call (RPC) service, and an optical communication system for implementing the same

Abstract

To provide a technique to interface an IDL based RPC architecture with a web service approach.SOLUTION: An RPC architecture including a central manager gateway that can access a client via a web service protocol is included. The central manager gate way includes a server directly response side that can communicate with a plurality of network elements, and each of the network elements performs the IDL architecture and the RPC manager instance. The RPC manager instance "learns" a network topology for publishing a naming service, communicates with another RPC manager instance to maintain a topology database, and the network element selects a master element. The central manager gateway automatically finds a master network element for transferring a client request.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] This specification generally relates to a communication system using a Remote Procedure Call (RPC) interface, and more specifically, to a system and method for interfacing between a web service and an IDL-based RPC service, and an optical communication system using the same.

Background Art

[0002] With the development of the Internet and related technologies, web applications and services have become increasingly popular and important in the software industry. Among web technologies, Representational State Transfer (REST) has become one of the most prevalent and rapidly growing technologies. There is an increasing need for software that provides RESTful APIs to accommodate the development and integration of customized client-end user interfaces. Currently, most development languages include frameworks for building RESTful web services.

[0003] However, in many existing implementations, the Common Object Request Broker Architecture (CORBA), developed during the early stages of the Internet, is utilized. CORBA is a software standard defined by the Object Management Group, by which many systems adopt cross-platform communication to maximize the advantages of different programming languages for managing Distributed Network Element Services (NES). For example, considering C++ development, since the native C++ development environment does not have native support for the Graphical User Interface (GUI), C++ requires other development languages (e.g., JAVA (registered trademark)) for GUI development support. Similarly, CORBA uses the Interface Definition Language (IDL) to reconcile the interfaces and objects presented for different implementations (e.g., C, C++, Java (registered trademark), Pascal, Python (registered trademark), Ruby), thereby enabling developers to develop cross-platform communication software without the need to "rebuild from scratch" and, as a result, saving the costs and time associated with the development of such software systems. CORBA provides a clearly defined form of cross-platform communication with access at the object level in much of the underlying client-server communication code hidden from developers. Similarly, CORBA features a naming service that provides developers with a simple form of registering and looking up object references using logical names.

[0004] However, CORBA has been postponing a solution that is difficult to implement due to non-trivial issues. For example, both clients and servers in the CORBA architecture need to use the same IDL at runtime to ensure compatibility. Inconsistencies between IDLs will result in a complete breakdown of communication between the client and the server. This makes the implementation of CORBA relatively fragile because even minor changes and upgrades to the published functions / methods require synchronization between the server and all clients, which can be difficult to execute. Furthermore, many existing solutions utilize a certain degree of proprietary CORBA elements that require not only knowledge of CORBA itself but also the nature of the changes to the core services. This proprietary knowledge requires extensive training and unfortunately results in the complete redevelopment from scratch of legacy CORBA software services rather than the reuse of other functional software.

[0005] Reference should be made to the following detailed description, which is to be read in conjunction with the following drawings, in which like reference numerals represent like parts.

Brief Description of the Drawings

[0006]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8A

Figure 8B

Figure 8C

Figure 8D

[0007] As described above, CORBA-based implementations are in use in a large number of deployed software applications, but the present technology still has issues to be developed and maintained compared to currently widely used web-based technologies. On the other hand, since there are still many technical issues remaining in attempts to integrate CORBA and modern web-based implementations, there are still issues in the problem of creating a new software system that retains the functional components and legacy support of existing CORBA-based systems.

[0008] The existing CORBA development process involves defining IDL in plain text. The IDL language includes syntax and formatting similar to other compiler-type / interpreter-type languages, and defines methods, arguments, and various parameters. Then, the plain text IDL is compiled to generate adapters in the desired language, such as C++ or Java (registered trademark). The generated adapters are also sometimes referred to as pre-compiled IDL adapters that can be instantiated during the runtime (execution) of a given program. And, as shown in Figure 1, CORBA client and server applications form a 1:1 relationship between the client and the server based on their related adapters. Requests are made directly between the client and the server, and responses are returned based on those requests through the use of an object request broker.

[0009] Unfortunately, CORBA was developed when the Internet was in its initial stages and security was not the top concern. CORBA originally did not implement a security scheme, and the CORBA interface poses a substantial security risk. The mere exposure of the CORBA interface leaves the server as an easy target for the Internet and attackers, as there is no security check at the interface level, which is a potential threat to the entire software system.

[0010] Upgrades to the fundamental IDL and minor changes also pose significant challenges for using CORBA. For example, both the client and the server must have compatible IDL, so any changes force the code of both the client and the server to be recompiled with the updated IDL for synchronization purposes. Since the individual teams handling the client and server code often have a large number of developers who can make changes at a rate that virtually makes complete client / server IDL compatibility impossible, this level of synchronization becomes difficult to execute. Furthermore, even though the reuse of existing CORBA implementations by software engineers is often avoided as a security risk, the old knowledge and strictness of CORBA can outweigh the negative aspects of redevelopment of the code using modern technologies such as Simple Object Access Protocol (SOAP) and REST. Several approaches, such as REST and SOAP, for exposing CORBA interfaces via modern web services have been proposed to enable the reuse of CORBA. However, these approaches still require a significant amount of development time and experience since communication processes between the middleware and the CORBA interface must be developed.

[0011] Accordingly, according to an embodiment, a technique for interfacing an IDL-based RPC architecture, such as CORBA, with web service approaches such as SOAP and REST is disclosed. In particular, embodiments of the present disclosure include an RPC architecture having a client-direct side that enables client access via web service protocols such as SOAP and REST. The central manager gateway includes a server-direct side communicable with a plurality of network elements, each network element implementing a common IDL architecture and an RPC manager instance. Each of the network elements, particularly their RPC manager instances, can communicate with other RPC manager instances to "learn" the network topology for the system and maintain a topology database for the purpose of exposing a naming service, such as a CORBA naming service. The network elements may select a certain master element while leaving the others as slaves. The central manager gateway can automatically locate the master network element and forward client requests thereto. Similarly, the master network element can convert web service requests and execute one or more IDL methods to satisfy the request. Then, the master network element can convert the response to the executed IDL method into a web service message and return it to the originating client by, for example, the central manager gateway operating as a proxy, or directly back to the client for transmission depending on the desired configuration. Since REST implements a stateless architecture, web services do not support the persistence of data messages across REST API calls. The central manager gateway can manage and facilitate such persistence, thus supporting REST web service messages while maintaining the integrity of the CORBA infrastructure / services.

[0012] In one specific and non-limiting example of an embodiment of the present disclosure, an IDL framework that enables the generation of multiple Java (registered trademark) adapters is disclosed. The first adapter of the Java (registered trademark) adapter includes an IDL definition defined for a CORBA-based C++ system so as to enable compilation and general CORBA communication, and the second adapter of the Java (registered trademark) adapter includes a definition that provides runtime services. The runtime services can be provided, for example, by stub definitions that can be overridden or extended by an application programmer to perform specific logic for a given application. And the RESTful service provides IDL requirements, for example, a REST service compliant with CORBA, and can implement multiple adapters that provide end users with a way to customize and integrate application-specific logic. A graphical user interface (GUI) library based on IDL can also be generated for the purpose of providing client-side services. The GUI, various adapters, and other related components can be reused and compiled in client and server software so as to maximize code reuse (however, the server does not necessarily present the GUI). In the context of a REST server, the multiple adapters may be packaged libraries, and the methods defined and implemented therein can be directly called and packaged together with other features supported by an integrated development environment.

[0013] Accordingly, the present disclosure provides many advantages over existing systems that simply expose IDL-based services, or other approaches that inhibit code reuse by redesigning and developing existing applications that expose IDL-based services such as CORBA from scratch. For example, an application developed with the RPC architecture disclosed herein can utilize existing CORBA services while also providing a framework for rapid development and extensibility through high-level customization and code reuse. Additionally, modern services such as SOAP and REST can be made client-direct to provide secure and easily developed client access. Thus, the RPC architecture disclosed herein improves computer service systems by removing the need for legacy knowledge of maintaining legacy code applications (e.g., having full compatibility with existing CORBA services), improving security, and transparently bridging legacy RPC technologies such as CORBA with web service architectures such as SOAP and REST. Further, the RPC architecture according to the present disclosure enables a 1:N relationship between a client and an IDL-based service, such as CORBA, which transcends the limitation of typically providing a 1:1 relationship between a client and a server as described above with respect to FIG. 1.

[0014] In the drawings, FIG. 2 shows an optical communication system 200 according to the present disclosure. The optical communication system 200 is shown in a very simplified form for ease of explanation and not by way of limitation. The optical communication system 200 can be implemented as an undersea optical communication system, with at least a portion of the elements located below the sea surface. Further, the optical communication system 200 can be implemented as a wavelength division multiplexing (WDM) system capable of transmitting over a plurality of channel wavelengths. As shown, the optical communication system 200 includes an optical transmission path 203 extending between a plurality of cable landing stations, namely cable landing stations 202-1, 202-2, and 202-3.

[0015] As shown, optical communication 200 includes an optical fiber cable collectively shown as 210 spanning a relatively large geographical distance (e.g., tens, hundreds, or thousands of kilometers). Thus, a subsea optical network may comprise a plurality of "wet" optical components disposed, for example, along the seabed or on an offshore platform. However, the cable segment is not necessarily limited in this regard, and the optical communication system 200 may include at least some length of an onshore optical fiber segment. The examples and scenarios disclosed herein refer to a cable landing station, i.e., a CLS, but the disclosure is not necessarily limited in this regard. For example, the techniques disclosed herein are similarly applicable to any station located within an optical communication system including, for example, to name 2 - 3 examples, a network operation center (NOC) and a remote operation position (ROP).

[0016] Subsequently, the optical transmission path 203 includes at least one optical cable 210 comprising one or more optical fiber pairs. The optical transmission path 203 includes a plurality of optical components including repeaters 218-1, 218-2 and one or more branching units, such as BU225. The BU may include a re-programmable optical add / drop multiplexer (ROADM) or other suitable optical filter / component (which may include a circuit configuration for remote monitoring and control) for transmitting and receiving channel wavelengths from a branching path, such as branching path 214. Each cable landing station may include an element management system (EMS) to provide access to various optical components and to provide an interface to command / response elements (CREs) within the system. Each of the optical components shown in FIG. 2 is also referred to as a network element, and each network element enables remote access for configuration, monitoring, and maintenance purposes. For this purpose, the term network element refers to any component in the optical communication system 200 that includes circuit configurations and / or software that enable remote network-based communication through wired or wireless connections, such as, for example, a BU, ROADM, optical repeater, NMS, EMS, LME, PFE.

[0017] Each of the cable landing stations 202-1 to 202-3 may be disposed along the coast or on a platform. Each of the cable landing stations 202-1 to 202-3 may include a line termination equipment (LTE) such as a channel line card (not shown), a power feeding equipment (PFE) 212-1, etc. The PFE 212-1 may be configured to supply a constant voltage or current along the optical transmission path 203.

[0018] As further illustrated, the first cable headend 202-1 includes an NMS 204-1, an EMS 206-1, and an LME 208-1. The NMS 204-1 may be implemented as an NMS 304 that is further described in detail with reference to FIG. 3. Each NMS may be configured to communicate with N EMS systems. Each of the EMS systems may be configured to communicate locally to a given cable headend or with optical components such as adjacent repeaters and other elements. The LME device may be utilized to perform high loss loopback (HLLB) or other measurements to guarantee nominal performance along the optical transmission path 203 and detect defects, such as cable breaks.

[0019] Optionally, two or more cable headends may include similar components for redundancy and fault tolerance, as well as for local management of network elements. For example, the second cable headend 202-2 may include an NMS 204-2, an EMS 206-2, and an LME 208-2. As further described below, each of the NMS components 204-1, 204-2 may together form a single NMS system 304, whereby a user may log in to and service requests to any of the NMS components, for example, directly through a graphical user interface (GUI) or via an API. In this example, one of the NMS components may operate as a master, whereby slave NMS systems proxy requests for handling or transfer them to the master. In the event that the master NMS goes offline, the optical communication system 200 may be configured to automatically switch a slave NMS into the role of the master.

[0020] Figure 3 shows an example of a network management system (NMS) architecture 304 according to the present disclosure. The NMS architecture 304 is shown in a very simplified form for clarity and not by way of limitation. The NMS architecture 304 can be implemented in different configurations that collectively provide the NMS architecture 304, for example, including a plurality of NMS servers, EMS servers, LMEs, etc. Thus, the components can be distributed among a plurality of cable landing stations, for example, CLS202-1 ··· CLS202-3 in FIG. 2, to provide redundancy, fault tolerance, and multiple access points to users of the NMS architecture 200. Therefore, the NMS 204 may be implemented collectively as a single NMS server, for example, NMS204-1, or may include a plurality of NMS systems, for example, NMS204-1, 204-2, as shown in FIG. 2.

[0021] As further illustrated, the NMS 304 includes a plurality of related components including a controller 305, a memory 307, a system resource database 312, a security manager 320, and a user interface 324. The NMS 304 can be implemented in hardware (e.g., circuit configuration), software, public / private cloud, or a combination thereof. In an embodiment, the NMS 304 can be at least partially implemented as a plurality of non-transitory instructions stored in the memory 307 that can be executed by the controller 305 (sometimes also referred to as an NMS controller) to perform NMS processing, for example, the processing 800 of FIGS. 8A-8D. The controller generally referred to herein can be implemented as a processor (e.g., an x86 process or a virtual computer), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other suitable processing device / circuit configuration.

[0022] The user interface 324 may comprise a graphical user interface (GUI) component and / or an API component that receives and processes requests from a user, such as user 429 (Figure 4). In an embodiment, the API of the user interface may implement a REST architecture. In other embodiments, the API of the user interface 324 may implement a CORBA architecture. The security manager 320 may be configured to ensure that a request 301 received from a user is acceptable based on the relevant privileges and access rights of the user.

[0023] The NMS 204 may include a system resource database 312 stored in the memory 307. The system resource database 312 may be distributed, for example, among a plurality of components including a plurality of NMSs and EMSs, and the embodiment shown in FIG. 3 is not intended to be limiting. For example, each cable landing station may include an EMS that stores data indicating each associated optical component (which may also be referred to as a network element) including, for example, line cards, PFEs, repeaters, LMEs, equalizers, computer servers, and branch units. Then, the NMS 203 may utilize EMS data from each of the cable landing stations to collectively and logically form the system resource table 312, although the data may be physically distributed across different cable landing stations. The system resource database 312 may include a structured query language (SQL) database, flat files (e.g., proprietary universal markup language (XML)), in-memory data structures, or any combination thereof.

[0024] FIG. 4 shows a block diagram illustrating an example of an architecture 400 for remote procedure call (RPC) according to an embodiment of the present disclosure. As shown, the client side includes a user 429 who can utilize a client 407 to communicate with a central manager gateway 401. The client 407 may comprise a remote computing device such as a laptop, desktop computer, server computer, or a smartphone having a controller / processor, memory, a user interface, and the like. The central manager gateway 401 may also be referred to as the RPC gateway 401. Note that the central manager gateway 401 may be instantiated by one of the network elements 406-1 of the network element or by a different server computer of the optical communication system 200. The client 407 may comprise a REST client or other suitable client approach such as SOAP. The client 407 may utilize a web service object library that enables communication services and runtime instantiation of dynamic changes, for example, a REST framework. In contrast to IDL-based protocols, web services allow changes to be made at the protocol level without breaking client-server compatibility. Thus, the web service object library may be developed in any number of programming languages such as, for example, C, C++, Java®, Ruby, C#, VB.NET, Lua, Python®, or any other suitable programming language.

[0025] In the context of server - side components, the RPC architecture 400 includes a central manager gateway 401 and a Remote Procedure Call (RPC) manager 405 that can be implemented by a master network element. As shown, each of the network elements 406 - 1 to 406 - N may include a circuit configuration and / or software that executes an instance of the RPC manager 405. Those network elements that instantiate the RPC manager 405 are also sometimes referred to as network element managers. Each of the network elements 406 - 1 to 406 - N may be implemented as an NMS server such as the NMS server 304 described above with reference to FIG. 3. However, each of the network elements 406 - 1 to 406 - N may be implemented as another type of system including a rack - mounted computer server. In any case, each of the network elements 406 - 1 to 406 - N may include a plurality of instructions that, when executed by an associated processor / controller, cause a local instance of the RPC manager processing to be executed. The network elements can communicate with each other and can select a "master" element, for example, by voting or simply by one of the network elements first coming online to select the master. As shown in FIG. 4, since the network element 406 - 1 is the master element, it hosts the RPC manager 405 that is accessible to the client 407 by the central manager gateway 401.

[0026] Each instance of the RPC manager 405 may include a plurality of components including a protocol-independent interface 409 and a request broker 411. The protocol-independent interface 409 may include N parser modules for servicing requests via REST or other desired protocols. The parser modules enable the parsing of requests and determine whether a request is authorized (e.g., by using the security manager 320) if the request is valid (e.g., not in an improper format) and what the request's requirements are. The request broker 411 may include a general-purpose central manager IDL parser, which is described in more detail below with reference to FIG. 6. For example, the IDL parser, also known as an adapter, may utilize precompiled IDL output from CORBA IDL. In this example, the request broker 411 may provide a CORBA naming service 414. The CORBA naming service 414 enables other CORBA server applications to publish references to objects that use logical names. Thus, the client 407 may request an operation to be performed by a local logical name by requesting that the RPC manager 405 look up a name via the naming service 414.

[0027] For example, as shown in FIG. 5, network element B406-2 and network element C406-3 can be uniquely identified within the optical communication system 200 based on the network element address 501. The network element address 501 may include a character string that follows a scheme that enables each cable headend to have a plurality of related network elements. However, other naming schemes may be used, and the example shown in FIG. 5 is not intended to be limiting. Each network element address can include a predetermined series of entity type / entity ID pairs that convey the hierarchy of network elements and sub-components within the cable station, uniquely identifying each entity. For example, a dual TLA network element is uniquely identified under its cable and fiber pair scope, such as "Cable.1 / FP.1 / DTLA.1."

[0028] As further shown in FIG. 5, the network element address 501 can identify at least one of the cable headend identifier 502, the fiber pair identifier 503, the element type ID 504, and the element ID 505. Additionally, the network element address can include a sub-component ID, such as sub-component ID 506. Thus, each network element can be assigned a network element address that can be registered with the naming service 414. Note that even while the master network element, such as network element A406-1 shown in FIG. 4, is performing a name lookup for the purpose of servicing a request, other network elements, such as network elements A406-2 to 406-N, can also receive registrations to update and synchronize their local name services in the event that a new master network element is selected (e.g., due to a defect, cable break, power outage, etc.).

[0029] In FIG. 4, each instance of the RPC manager 405 can receive a registration message from other network elements within the optical communication system 200. The registration data can be stored in the topology table 412 for use by the naming service 414. The registration data can include an IP address (such as IPv4, IPv6), a host name, a device type, and characteristics of other network elements. In some cases, the topology table 412 for each network element can be stored in the associated system resource database 312 (FIG. 3). In an embodiment, the topology table 412 defines a hierarchical object model of each network element and its subcomponents, and each component is presented as an entity with attributes and a child entity representing a subcomponent. And each entity may be uniquely identified by its network element address and can include a full name attribute to provide a user-friendly name such as "A.FP1.DTLA1" as described above with respect to FIG. 5. Each instance of the RPC manager 405 can support the comprehensive IDL getTopology() method for retrieving a topology snapshot. Topology change events, such as CORBA events, can be sent when the attribute values change from each network element / entity, whereby each RPC manager 405 can maintain a synchronized topology data model (see FIG. 7).

[0030] In operation, client 407 sends a request message 408. The request message 408 can be formatted in a web service protocol such as, for example, SOAP or REST. Thus, the request message 408 can be accurately described to have a self-describing format in which the information schema can be derived from the message itself. For example, JSON self-describes in this format that allows for relatively easy parsing and message adaptability. In contrast, IDL-based schemes such as CORBA require understanding of the message scheme in IDL. The request message 408 can identify at least one network element and the operation to be performed. The network element can be identified by a network element address, for example, the network element address 501 shown in FIG. 5. The operation can include a GET operation to obtain attributes / data requested for a desired network element such as configuration parameters, log data, uptime, status, etc. The operation can further include a SET operation to change specific attributes / data.

[0031] The central manager gateway 401 can receive the request message 408. Then, the central manager gateway 401 can determine the current master network element to process the request. For example, as shown in FIG. 4, network element A 406-1 is operating as the master network element. Thus, the central manager gateway 401 locates network element A 406-1 and forwards the request message 408 to it. Then, network element A 406-1 receives the request message 408 and processes it.

[0032] Network element A406-1, and more specifically the RPC manager 405, may utilize the protocol-independent interface 409 to parse the request message 408, for example, using an HTTP parser module, to extract the network element address and the desired operation. The network element A406-1 may perform authentication (e.g., using the security manager 320) to determine whether to permit the requested operation, either before or after determining that the requested network element exists and any necessary management of persistence while maintaining the stateless nature of the REST interface. The RPC manager 405 can query the topology table 412 to determine whether the extracted network element address is known in the system. In the event that the network element address is not known, the RPC manager 405 may send a NAK message, e.g., an HTTP error code such as HTTP NOT_FOUND (404). If the network element is found in the topology table 412 (and the request is permitted), the RPC manager 405 determines whether the operation of the request message 408 can be performed via local data such as information / attributes stored in the topology table 412. For example, some requests, such as for status and uptime, can be serviced without necessarily communicating with a remote network element using CORBA messaging. Such an example includes obtaining a list of sub-components (e.g., LME ports, LME switch positions) under a network element (e.g., LME), and retrieving attributes of the network element and its sub-components, such as operational state, fault LED state, and / or inventory information (including, e.g., circuit pack model and physical location).

[0033] In the event that the requested operation is not executable using local data, the RPC manager 405 can communicate with the network element associated with the network element address extracted using the request broker 411. This communication may include, for example, using an IDL-based messaging scheme that sends a message 422 conforming to the CORBA protocol. For example, the request broker 411 may have pre-compiled IDL instances (or adapters) associated with each of the network elements in the system. Thus, the request broker 411 can retrieve the pre-compiled IDL from the IDL store 413 to instantiate the client in IDL that is compatible with the target network element. As described above, the client's IDL must be consistent with the server's IDL in CORBA-based client-server communication. Therefore, the IDL store 413 may include a library of pre-compiled IDL adapters, and each pre-compiled IDL adapter corresponds to one or more network elements. Then, the request broker 411 can convert the request message 408 into an equivalent IDL-based message based at least in part on the extracted network element address and the requested operation. And further, the request broker 411 can identify one or more remote procedure calls to be executed using the IDL corresponding to the network element associated with the extracted network element address. For example, the requested operation may be to retrieve a specific configuration setting, and the IDL may define a remote procedure call GET_PARAMETER() that can be used to satisfy the requested operation. Then, the request broker 411 can send the message 422 to the network element associated with the network element address.

[0034] In one example of a scenario, the request broker 411 may identify two or more remote procedure calls to be executed using one or more precompiled IDL adapters to satisfy the request message 408. For example, a request may need to communicate with two or more network elements such as requests for log data, status, etc. In other examples, a request may need to call two or more different remote procedure calls on a network element. For example, a request for multiple measurements such as error count, power level, and retransmission count may need to call multiple remote procedure calls using the messaging 422 to satisfy one request received by the RPC manager 405 from the user 429. Thus, one request message 408 may result in communication of a message 422 with two or more network elements by calling / executing one or more remote procedure calls of the two or more network elements.

[0035] Thus, the RPC architecture 400 according to the present disclosure enables a 1:N relationship between the client 407 and a plurality of IDL-based server instances, i.e., network elements 406-1 to 406-N. In the context of CORBA, such a 1:N relationship transcends the architecture limitations since CORBA is limited to a 1:1 direct client-server communication flow (see FIG. 1 above).

[0036] FIG. 6 shows an example of an IDL inheritance model 600 according to an aspect of the present disclosure. As shown, the IDL inheritance model 600 includes a general-purpose central manager-based IDL 601, a web service 602 (e.g., a REST server), an RPC manager-based IDL 603, an RPC manager A IDL 604, and an RPC manager B IDL 605. The general-purpose central manager IDL 601 defines an interface common to all server components. The web service 602 may be instantiated by an RPC manager 406 (FIG. 4) to handle user requests, e.g., REST requests, SOAP requests, and may implement a general-purpose central manager-based IDL for the purpose of converting requests into equivalent remote procedure calls as described above with respect to FIG. 4.

[0037] Similarly, the RPC manager base IDL 603 can define a common interface for each network element, such as a remote procedure call to obtain status information, operation parameters, and diagnostic information. The RPC manager A IDL 604 and the RPC manager B IDL 605 can further define a specific interface for one or more types of network elements. For example, the RPC manager A IDL 604 can define a specific interface for a line monitoring device (LME), and the RPC manager B IDL 605 can define a specific interface for an optical relay device. Therefore, network elements, such as network elements 406-1 to 406-3, can derive a specific IDL for their device types to ensure that an appropriate interface for servicing requests is available. In another example, the RPC manager A IDL 604 and the RPC manager B IDL 605 can define "stub" or placeholder functions that can be dynamically set at runtime to allow a user to customize the logic associated with each predetermined placeholder function. Therefore, each client / server instance can load two or more precompiled IDL adapters, namely, at least a first IDL adapter that defines a common / default method and function for communicating via, for example, CORBA, and a second IDL adapter that has a stub / placeholder function that enables runtime customization of the published RPC operations.

[0038] FIG. 7 shows an example of an event communication flow according to an embodiment of the present disclosure. As shown, network element B406-2 transmits an IDL-based event message 702. For example, the IDL-based event message 702 may conform to the CORBA protocol. Network element A406-1 operates as a master for RPC management purposes and receives the IDL-based event message 702. Network element A406-1 converts the IDL-based event 702 into a web service message 703 by instantiating an RPC manager 405. The web service message 703 includes at least an identifier of a network element address and an event type. Then, network element A406-1 transmits the web service message 703 to client 407.

[0039] FIGS. 8A-8D collectively provide an example of a process 800 for servicing requests by an RPC architecture embodying the above aspects and embodiments. The process 800 may be expressed as a plurality of machine-readable instructions executable by a controller 305 (FIG. 3) of the NMS 304 when operating as an RPC manager or a central manager gateway instance.

[0040] In operation 802, the server of the central manager gateway 401 receives a web service request from a client, e.g., client 407 (FIG. 4). The web service request can be in a format that conforms to, e.g., REST or SOAP. The web service request can include one or more target network element addresses and an identifier of the operation to be performed on the target network element. In operation 804, the central manager gateway 401 identifies which of the network elements is operating as the master. In the event that there is no master network element, in operation 808, the central manager gateway 401 sends a negative acknowledgment (NAK) message, e.g., an HTTP error code. The NAK message can be sent in the same format as the request received in operation 802, e.g., REST, JSON, etc. On the other hand, in operation 806, the central manager gateway 401 forwards / sends the web service request to the master RPC manager, e.g., network element A 406-1 as shown in FIG. 4.

[0041] In operation 810, the master RPC manager receives the transferred web service request. In operation 812, the master RPC manager extracts the target network element address and operation from the received web service request, for example, using an HTTP parser module. The format of the network element address may conform to the format illustrated and described above with respect to FIG. 5. In operation 814, the master RPC manager determines whether there is a network element associated with the extracted target network element address. This may include, for example, querying the topology table 412 to determine whether the extracted target network element address is known. If the target network element address exists, the process continues to operation 818; otherwise, the process continues to operation 816, where the master RPC manager sends and returns a NAK message to the client. The NAK message may be sent in the same format as the request received in operation 802.

[0042] In operation 818, the master RPC manager determines whether local data can be used to service the request. As described above, some information such as uptime, status, etc. may be stored in the topology table 412 or the memory 307. Therefore, the attributes / characteristics stored in the local data can be used to service the request. If the local data satisfies the request, the master RPC manager retrieves information from the local data and generates a response message. In operation 822, the master RPC manager sends the generated response message to the client in the same format as the request received in operation 802, for example, JSON, XML, or other REST / SOAP compatible format.

[0043] In operation 824, the master RPC manager may select and instantiate a precompiled IDL adapter (or simply an adapter) corresponding to the target's network element associated with the extracted target network element address. Operation 824 may include the master RPC manager querying / executing a lookup on IDL store 413 to identify the IDL that will enable the RPC manager to communicate with the target's network element. As described above with respect to FIG. 6, multiple network elements may be associated with the same RPC manager's IDL. Thus, the RPC manager may simply retrieve a precompiled IDL adapter based on the known type of the target's network element. Alternatively or additionally, IDL store 413 may associate each network element with a specific precompiled IDL adapter, for example in a 1:1 relationship. Therefore, the master RPC manager may determine the precompiled IDL adapter to use based on the association between the target's network element and its corresponding IDL in IDL store 413.

[0044] In any event, following operation 826, the master RPC manager can identify one or more remote procedure calls, such as functions / methods, to call on the target network element based on the pre-compiled IDL adapter instantiated / selected in operation 824. In operation 828, the master RPC manager executes one or more remote procedure calls identified for the target network element. In operation 830, the master RPC manager receives the response from the executed remote procedure call and generates a response message based on the response in the same format as the request received from the client in operation 802, e.g., XML / JSON. In operation 832, the master RPC manager sends the generated response message to the client, for example, by routing the response message generated through the central manager gateway 401 or by sending the generated response message directly to the client.

[0045] According to an aspect of the present disclosure, a network management system is disclosed. The network management system includes a memory and a controller that receives a user request from a remote computing device, the user request including at least one network element address and an identifier of an operation to be performed on the at least one network element address, extracts the at least one network element address and the identifier of the operation to be performed on the at least one network element address, selects a precompiled Interface Definition Language (IDL) adapter associated with the at least one network element address from the memory, selects at least one Remote Procedure Call (RPC) function that satisfies the user request based on the selected precompiled IDL adapter, executes the at least one RPC function by sending at least one IDL-based message to one or more network elements associated with the at least one network element address, and sends a response message to the remote computing device based on a response from the executed at least one RPC function, the response message being in the same format as the user request.

[0046] According to another aspect of the present disclosure, a computer-implemented method for servicing a remote procedure call request is disclosed. The computer-implemented method includes an operation of receiving, by a controller, a user request from a remote computing device, the user request including a self-describing message including at least one network element address and an identifier of an operation to be performed on the at least one network element address; an operation of extracting, by the controller, the at least one network element address and the identifier of the operation to be performed on the at least one network element address; an operation of selecting, by the controller, a pre-compiled interface description language (IDL) adapter associated with the at least one network element address from memory; an operation of selecting, by the controller, at least one remote procedure call (RPC) function to satisfy the user request based on the selected pre-compiled IDL adapter; an operation of executing, by the controller, the at least one RPC function by sending at least one IDL-based message to one or more network elements associated with the at least one network element address; and an operation of sending, by the controller, a response message to the remote computing device based on a response from the at least one RPC function executed, the response message being in the same format as the user request.

[0047] According to yet another aspect of the present disclosure, an optical communication system is disclosed. The optical communication system includes an optical communication path extending between a plurality of cable headends, each of the plurality of cable headends being associated with one or more of a plurality of network elements disposed along the optical communication path, the system including an RPC gateway server, the RPC gateway server receiving a user request, the user request including an identifier of an operation and an identifier of at least one network element that performs the operation and operates as a master network element, the master network element being caused to send a first message to the identified master network element, the first message causing the master network element to select a pre-compiled Interface Definition Language (IDL) adapter corresponding to the network element associated with the identifier of the at least one network element, and causing the master network element to send at least one message to the network element based on the selected IDL adapter and the operation.

[0048] Embodiments of the methods disclosed herein may be implemented using a controller, a processor, and / or other programmable devices. For that purpose, the methods described herein may be implemented on a tangible non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, perform the methods.

[0049] Thus, for example, NMS304 may include a storage medium that stores instructions (e.g., in firmware or software) to perform the operations described herein. The storage medium can include any type of tangible medium, such as any type of disk including floppy disks, optical disks, compact disc read-only memory (CD-ROM), compact disc rewritable (CD-RW), and magneto-optical disks, read-only memory (ROM), random access memory (RAM) such as dynamic and static RAM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical cards, or any other type of medium suitable for storing electronic instructions, including semiconductor devices.

[0050] It will be understood by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuit arrangements embodying the principles of the present disclosure. Similarly, any block diagrams, flowcharts, flow diagrams, state transition diagrams, pseudocode, etc., are substantially shown in a computer-readable medium, and thus represent various processes that may be executed by such a computer or processor, whether or not such a computer or processor is explicitly shown. A mere module that is suggested to be software or a software module may be shown herein as any combination of elements of a flowchart or processing step and / or other elements that indicate performance of the description in the text. Such modules may be executed by hardware that is explicitly or implicitly shown.

[0051] The functions of the various elements shown in the drawings include any functional blocks labeled "processor" and can be provided through the use of dedicated hardware and software-executable hardware associated with appropriate software. The functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Further, the explicit use of the term "processor" should not be construed as exclusively referring to software-executable hardware, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other conventional and / or custom hardware may also be included.

[0052] Unless otherwise specified, the use of the word "substantially" can be construed to include the exact relationships, situations, arrangements, orientations, and / or other characteristics, and their variations as understood by those skilled in the art, and within the scope of such variations, do not substantially affect the disclosed methods and systems. Throughout the present disclosure, the use of the articles "a", "an", and / or "the" to modify nouns is used for convenience and can be understood to include one or more of the nouns being modified, unless otherwise specified. The terms "comprising", "including", and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements.

[0053] The methods and systems have been described with respect to specific embodiments thereof, but they are not so limited. Clearly, many variations and modifications can become apparent from the above teachings. Many additional changes to the details, materials, and arrangements of the parts described and illustrated herein can be made by those skilled in the art.

[0054] The foregoing description of the example embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be defined not by this detailed description, but rather by the claims appended hereto.

Claims

1. A memory for storing instructions; and one or more processors, coupled to the memory, operable to execute the instructions; Equipped with The instructions, when executed, cause the one or more processors to: receiving a request message from a remote computing device, the request message including a network element address, the network element address associated with a network element in an optical communication system; selecting a precompiled Interface Description Language (IDL) adapter associated with the network element address from a library of a plurality of precompiled IDL adapters stored in the memory; identifying at least one remote procedure call (RPC) function to execute based on the selected precompiled IDL adaptor; Transforming the request message into an IDL-based message by the selected precompiled IDL adapter; causing the IDL-based message to be sent to the network element associated with the network element address; and causing the remote computing device to send a response message based on a response from the execution of the at least one RPC function, wherein the response message is in the same format as the request message. Device.

2. The request message complies with the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard; 2. The apparatus of claim 1.

3. said at least one RPC function being implemented according to a Common Object Request Broker Architecture (CORBA) architecture; 3. The apparatus of claim 2.

4. The network element address includes: (i) a cable land station identifier; (ii) an element type; (iii) an element identifier (ID); and / or (iv) a subcomponent ID.

2. The apparatus of claim 1.

5. a topology table stored in the memory, the topology table including a plurality of network element addresses each corresponding to a different network element in an optical communication system; 2. The apparatus of claim 1.

6. each of the precompiled IDL adaptors in the library of precompiled IDL adaptors is associated with one or more network elements in an optical communications system; 2. The apparatus of claim 1.

7. When the one or more processors select the precompiled IDL adaptor associated with the network element address from the library of precompiled IDL adaptors stored in the memory, the one or more processors: performing a lookup on an IDL store, the IDL store including a plurality of associations between a plurality of network elements and a plurality of precompiled IDL adapters; 2. The apparatus of claim 1.

8. For at least one processor: receiving a request message from a remote computing device, the request message including a network element address; selecting a precompiled Interface Description Language (IDL) adapter associated with the network element address from a library of a plurality of precompiled IDL adapters; identifying at least one remote procedure call (RPC) function to execute based on the selected precompiled IDL adapter; converting the request message to an IDL-based message by the selected precompiled IDL adapter; sending the IDL-based message to a network element associated with the network element address; and sending a response message to the remote computing device based on a response from the execution of the at least one RPC function, wherein the response message is in the same format as the request message; and a computer readable program code executable by the at least one processor to cause the at least one processor to execute the method.

9. The request message complies with the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard; 9. Computer readable program code according to claim 8.

10. said at least one RPC function being implemented according to a Common Object Request Broker Architecture (CORBA) architecture; 9. Computer readable program code according to claim 8.

11. The network element address includes: (i) a cable land station identifier; (ii) an element type; (iii) an element identifier (ID); and / or (iv) a subcomponent ID.

9. Computer readable program code according to claim 8.

12. and causing the at least one processor to perform a procedure for accessing a topology table, the topology table including a plurality of network element addresses each corresponding to a different network element in an optical communication system.

9. Computer readable program code according to claim 8.

13. each of the precompiled IDL adaptors in the library of precompiled IDL adaptors is associated with one or more network elements in an optical communications system; 9. Computer readable program code according to claim 8.

14. When causing the at least one processor to perform the step of selecting the precompiled IDL adapter associated with the network element address from the library of the plurality of precompiled IDL adapters, the at least one processor further comprises: performing a lookup on an IDL store, the IDL store including a plurality of associations between a plurality of network elements and a plurality of precompiled IDL adapters; 9. Computer readable program code according to claim 8.

15. A non-transitory computer readable storage medium having stored thereon the computer readable program code according to any one of claims 8 to 14.

16. A computer-implemented method comprising: receiving a request message from a remote computing device, the request message including a network element address; selecting, by one or more processors, a precompiled Interface Description Language (IDL) adapter associated with the network element address from a library of a plurality of precompiled IDL adapters stored in memory; identifying, by the one or more processors, at least one remote procedure call (RPC) function to execute based on the selected precompiled IDL adapter; converting the request message to an IDL-based message by the selected precompiled IDL adapter; sending the IDL-based message to a network element associated with the network element address; and sending a response message to the remote computing device based on a response from the execution of the at least one RPC function, the response message being in the same format as the request message; A method for providing the above.

17. The request message complies with the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard; 17. The method of claim 16.

18. said at least one RPC function being implemented according to a Common Object Request Broker Architecture (CORBA) architecture; 17. The method of claim 16.

19. The network element address includes: (i) a cable land station identifier; (ii) an element type; (iii) an element identifier (ID); and / or (iv) a subcomponent ID.

17. The method of claim 16.

20. accessing a topology table stored in the memory, the topology table including a plurality of network element addresses each corresponding to a different network element in the optical communication system; 17. The method of claim 16.

21. The step of selecting, from the memory, the precompiled IDL adapter associated with the network element address by one or more processors comprises: performing a lookup on an IDL store, the IDL store including a plurality of associations between a plurality of network elements and a plurality of precompiled IDL adapters; 17. The method of claim 16.

Images