A technology for interfacing web services with interface description language (IDL)-based remote procedure call (RPC) services, and an optical communication system for implementing it.

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 common and fast-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 programming languages include frameworks for building RESTful web services.

[0003] However, many existing implementations utilize the Common Object Request Broker Architecture (CORBA), developed during the early stages of the internet. CORBA is a software standard defined by the Object Management Group, in which many systems employ cross-platform communication to manage distributed network element services (NES) while maximizing the advantages of different programming languages. For example, considering C++ development, the native C++ development environment does not have native support for graphical user interfaces (GUIs), so C++ requires other development languages ​​(e.g., Java®) for GUI development support. Similarly, CORBA uses an Interface Definition Language (IDL) to coordinate interfaces and objects presented to different implementations (e.g., C, C++, Java®, Pascal, Python®, Ruby), thereby allowing developers to develop cross-platform communication software without having to "rebuild from scratch again," and as an extension, saving the costs and time associated with developing such software systems. CORBA provides a clearly defined form of cross-platform communication where there is access at the object level to much of the underlying client-server communication code hidden from the developer. Similarly, CORBA features a naming service that provides developers with a simple form of registering and looking up references to objects using logical names.

[0004] However, CORBA postpones solutions that are difficult to implement due to significant challenges. For example, both clients and servers in a CORBA architecture must use the same IDL at runtime to ensure compatibility. Inconsistencies between IDLs result in a complete disruption of communication between clients and servers. This makes CORBA implementation relatively vulnerable, as even minor changes and upgrades to published features / methods require synchronization between servers and all clients, which can become difficult to implement. Furthermore, many existing solutions utilize some proprietary CORBA elements that require not only knowledge of CORBA itself but also the nature of changes to the core services. This proprietary knowledge requires extensive training and, unfortunately, results in the complete redevelopment of legacy CORBA software services from scratch rather than the reuse of other functional software.

[0005] The following detailed description should be read in conjunction with the following drawings, and similar symbols represent similar parts. [Brief explanation of the drawing]

[0006] [Figure 1] Figure 1 is a simplified block diagram of the communication architecture for CORBA clients and servers. [Figure 2] Figure 2 is a simplified block diagram of an exemplary embodiment of the optical communication system according to this disclosure. [Figure 3] Figure 3 is a simplified block diagram of an exemplary embodiment of a network management system (NMS) suitable for use in the optical communication system shown in Figure 2. [Figure 4] Figure 4 is a simplified block diagram of an exemplary embodiment of a remote procedure call (RPC) architecture for use in the optical communication system shown in Figure 2. [Figure 5]Figure 5 shows an example of a network element address format for use in the RPC architecture shown in Figure 4. [Figure 6] Figure 6 shows a simplified block diagram of the interface description language (IDL) inheritance model according to the embodiments of this disclosure. [Figure 7] Figure 7 shows an example of communication for an IDL-based event message according to an embodiment of the present disclosure. [Figure 8A] Figure 8A summarizes an example of a method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Figure 8B] Figure 8B summarizes an example of a method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Figure 8C] Figure 8C summarizes an example of a method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Figure 8D] Figure 8D summarizes an example of a method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Modes for carrying out the invention]

[0007] As mentioned above, while CORBA-based implementations are in use in numerous deployed software applications, this technology still presents challenges for development and maintenance compared to currently widely used web-based technologies. Furthermore, the numerous technical challenges remain in attempts to integrate CORBA with modern web-based implementations, making the creation of new software systems that retain the functional components and legacy support of existing CORBA-based systems a significant challenge.

[0008] The existing CORBA development process involves defining IDL in plain text. The IDL language, like other compiled / interpreted languages, includes syntax and formatting, defining methods, arguments, and various parameters. The plain text IDL is then compiled to generate an adapter in the desired language, such as C++ or Java®. The generated adapter is sometimes also called a precompiled IDL adapter, which can be instantiated during the runtime (execution) of a given program. As shown in Figure 1, CORBA client and server applications form a one-to-one relationship between client and server based on their respective adapters. Requests are made directly between the client and 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 early stages and security was not the primary concern. CORBA originally did not implement security measures, and the CORBA interface poses a significant security risk. The careless exposure of the CORBA interface is a potential threat to the entire software system because CORBA lacks interface-level security checks, leaving servers exposed to the internet and attackers as easy targets.

[0010] Fundamental IDL upgrades and minor changes also present significant challenges to using CORBA. For example, both the client and server must have IDL alignment, meaning any change necessitates recompiling both the client and server code with the updated IDL for synchronization purposes. This level of synchronization becomes difficult to achieve, as separate teams handling client and server code often have numerous developers capable of implementing changes at a rate that virtually makes complete client / server IDL compatibility impossible. Furthermore, even though the reuse of existing CORBA implementations by software engineers is often avoided due to security risks, the outdated knowledge and rigor of CORBA can outweigh the negative aspects of redeveloping the code using modern technologies such as Simple Object Access Protocol (SOAP) and REST. Several approaches have been proposed to expose CORBA interfaces through modern web services, such as REST and SOAP, to enable CORBA reuse. However, these approaches still require considerable development time and experience, as they necessitate developing communication processing between middleware and the CORBA interface.

[0011] Accordingly, according to embodiments, techniques for interface an IDL-based RPC architecture, such as CORBA, with web service approaches such as SOAP and REST are disclosed. In particular, embodiments of this disclosure include an RPC architecture including a central manager gateway having a client-direct responding side that enables client access via web service protocols such as SOAP and REST. The central manager gateway further includes a server-direct responding side that can communicate with a plurality of network elements, each network element implementing a common IDL architecture and RPC manager instance. Each of the network elements, in particular their RPC manager instance, may communicate with other RPC manager instances to "learn" a network topology for the system and maintain a topology database for the purpose of exposing a naming service, such as a CORBA naming service. Network elements may select a master element while others remain slaves. The central manager gateway may automatically identify the master network element and forward client requests thereto. Similarly, the master network element may translate web service requests and execute one or more IDL methods to satisfy those requests. The master network element then translates the response to the executed IDL method into a web service message, which can be sent back to the originating client, for example, by a central manager gateway acting as a proxy, or, depending on the desired configuration, directly back to the client. Because REST implements a stateless architecture, web services do not support data message persistence across REST API calls. The central manager gateway manages and facilitates such persistence, thus maintaining the integrity of the CORBA infrastructure / services while also supporting REST web service messages.

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

[0013] Therefore, this disclosure offers many advantages over other approaches that hinder code reuse by redesigning and developing existing systems that carelessly expose IDL-based services, or existing applications that predate the exposure of IDL-based services such as CORBA. For example, applications developed with the RPC architecture disclosed herein can utilize existing CORBA services while also providing a rapidly developable and extensible framework with a high level of customization and code reuse. Furthermore, modern services such as SOAP and REST can be client-direct to provide secure and easily developed client access. Thus, the RPC architecture disclosed herein improves computer service systems by eliminating the requirements of traditional knowledge to maintain legacy code applications (e.g., fully compatible with existing CORBA services), design new client applications, improved security, and the ability to transparently bridge legacy RPC technologies such as CORBA with web service architectures such as SOAP and REST. Furthermore, the RPC architecture described herein enables a 1:N relationship between the client and an IDL-based service, such as CORBA, which transcends the limitations that typically impose a 1:1 relationship between the client and server, as described above in Figure 1.

[0014] In the drawings, Figure 2 shows the 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 as an limitation. The optical communication system 200 may be implemented as an underwater optical communication system, with at least some of its elements located below the sea surface. Furthermore, the optical communication system 200 may be implemented as a wavelength division multiplexing (WDM) system capable of transmitting over multiple channel wavelengths. As shown in the figures, the optical communication system 200 includes an optical transmission path 203 extending between multiple cable ground stations, i.e., cable ground stations 202-1, 202-2, and 202-3.

[0015] As illustrated, the optical communication 200 includes optical fiber cables, collectively shown as 210, that extend over relatively large geographical distances (e.g., tens, hundreds, or thousands of kilometers). Thus, a submarine optical network may comprise multiple “wet” optical components, for example, laid along the seabed or on a marine platform. However, the cable segments are not necessarily limited in this regard, and the optical communication system 200 may include at least a certain length of terrestrial optical fiber segments. The examples and scenarios disclosed herein refer to cable ground stations, i.e., CLSs, but the disclosure is not necessarily limited in this regard. For example, the technology disclosed herein is similarly applicable to any station located within an optical communication system, including, for example, a Network Operations Center (NOC) and a Remote Operation Position (ROP), to name a few examples.

[0016] Next, the optical transmission path 203 includes at least one optical cable 210 having one or more pairs of optical fibers. The optical transmission path 203 includes multiple optical components, including repeaters 218-1, 218-2 and one or more branching units, e.g., BU 225. The BU may include a reprogrammable optical add / drop multiplexer (ROADM) or other suitable optical filter / component (e.g., including circuit configurations for remote monitoring and control) for transmitting and receiving channel wavelengths from branching paths, e.g., branching path 214. Each cable ground station may include an element management system (EMS) to provide access to various optical components and to interface to command / response elements (CREs) in the system. Each of the optical components shown in Figure 2 is also called a network element, and each network element is remotely accessible for configuration, monitoring, and maintenance purposes. For this purpose, the term "network element" refers to any component in an optical communication system 200 that includes circuit configurations and / or software enabling remote network-based communication via wired or wireless connections, such as a BU, ROADM, optical repeater, NMS, EMS, LME, or PFE.

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

[0018] As further illustrated, the first cable ground station 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, which will be further detailed with reference to Figure 3. Each NMS may be configured to communicate with N EMS systems. Each EMS system may be configured to communicate locally with a given cable ground station or with optical components such as adjacent repeaters and other elements. The LME device may be used to perform high-loss loopback (HLLB) or other measurements to ensure nominal performance along the optical transmission path 203 and to detect defects, such as cable breakage.

[0019] Selectively, two or more cable ground stations may include similar components for redundancy and fault tolerance, as well as for local management of network elements. For example, a second cable ground station 202-2 may include NMS204-2, EMS206-2, and LME208-2. Furthermore, as described below, each of the NMS components 204-1 and 204-2 may collectively form a single NMS system 304, thereby allowing a user to log in to any NMS component and have requests served, for example, directly via a graphical user interface (GUI) or via an API. In this example, one of the NMS components may act as a master, thereby allowing the slave NMS system to proxy or forward requests to the master for handling. In the event that the master NMS goes offline, the optical communication system 200 may be configured to automatically switch the slave NMS to the master role.

[0020] FIG. 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 limitation. The NMS architecture 304 can be implemented in different configurations, for example, including a plurality of NMS servers, EMS servers, LMEs, etc., to collectively provide the NMS architecture 304. 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, a public / private cloud, or a combination thereof. In an embodiment, the NMS 304 can be at least partly implemented as a plurality of non-transitory instructions stored in the memory 307 and executed by a controller 305 (sometimes also referred to as an NMS controller) to perform NMS processing, for example, processing 800 in 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 (FIG. 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 headend 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 headends to form the system resource table 312 collectively and logically, although the data may be physically distributed across different cable headends. The system resource database 312 may include a structured query language (SQL) database, a flat file (e.g., a proprietary universal markup language (XML)), an in-memory data structure, or any combination thereof.

[0024] Figure 4 shows a block diagram illustrating an example of an architecture 400 for remote procedure calls (RPC) according to an embodiment of the present disclosure. As shown in the figure, 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 be a laptop, desktop computer, server computer, or a remote computing device such as a smartphone having a controller / processor, memory, and a user interface. The central manager gateway 401 is also sometimes referred to as the RPC gateway 401. The central manager gateway 401 may be instantiated by one network element 406-1 of the network elements, or by different server computers of the optical communication system 200. The client 407 may be a REST client, or other suitable client approach such as SOAP. The client 407 may utilize a web service object library, such as the REST framework, which enables runtime instantiation of communication services and dynamic changes. In contrast to IDL-based protocols, web services allow changes to be made at the protocol level without breaking client-server compatibility. Therefore, the web service object library can be developed in any number of programming languages, such as 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, which may be implemented by a master network element. As shown in the diagram, each of the network elements 406-1 to 406-N may include a circuit configuration and / or software that runs an instance of the RPC manager 405. These network elements that instantiate the RPC manager 405 may also be called 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 Figure 3. However, each network element 406-1 to 406-N may be implemented as another type of system, including a rack-mount computer server. In any case, each network element 406-1 to 406-N may include a number of instructions that, when executed by the associated processor / controller, cause a local instance of RPC manager processing to run. Network elements can communicate with each other and select a “master” element, for example, through voting, or simply by one of the network elements coming online first. As shown in Figure 4, network element 406-1 is the master element and therefore hosts an RPC manager 405 that is accessible to client 407 via the central manager gateway 401.

[0026] Each instance of the RPC manager 405 may include multiple components, including a protocol-independent interface 409 and a request broker 411. The protocol-independent interface 409 may include N parser modules to service requests via REST or other desired protocols. The parser modules enable the parsing of requests, determine whether the request is valid (e.g., not in an invalid format), determine whether the request is permitted (e.g., by using the security manager 320), and determine what the request is. The request broker 411 may include a general-purpose central manager IDL parser, which is described in more detail below with reference to Figure 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 using logical names. Therefore, client 407 may request an action to be performed by a local logical name by asking RPC manager 405 to look up the name via naming service 414.

[0027] For example, as shown in Figure 5, network elements B406-2 and 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 contain a string of characters that follows a scheme that allows each cable ground station to have multiple associated network elements. However, other naming schemes may be used, and the example shown in Figure 5 is not intended to be limiting. Each network element address may contain a predetermined set of entity type / entity ID pairs that transmit the hierarchy of network elements and subcomponents within the cable station, uniquely identifying each entity. For example, a dual TLA network element may be uniquely identified under its cable and fiber pair scope, such as "Cable.1 / FP.1 / DTLA.1."

[0028] As further shown in Figure 5, the network element address 501 may identify at least one of the following: the cable ground station identifier 502, the fiber-to-fiber identifier 503, the element type ID 504, and the element ID 505. In addition, the network element address may include a subcomponent ID, for example, subcomponent ID 506. Thus, each network element may be assigned a network element address that can be registered with the naming service 414. Furthermore, while the master network element, for example, network element A406-1 shown in Figure 4, is performing a name lookup for the purpose of servicing a request, other network elements, for example, network elements A406-2 to A406-N, may also receive registrations that update and synchronize their local name services in events in which a new master network element is selected (for example, due to a defect, cable damage, power outage, etc.).

[0029] In Figure 4, each instance of the RPC manager 405 can receive registration messages from other network elements within the optical communication system 200. Registration data may be stored in a topology table 412 for use by the naming service 414. Registration data may include IP addresses (IPv4, IPv6, etc.), hostnames, device types, and other network element characteristics. In some cases, a topology table 412 for each network element may be stored in the associated system resource database 312 (Figure 3). In embodiments, the topology table 412 defines a hierarchical object model of each network element and its subcomponents, where each component is presented as a child entity indicating entities and subcomponents with attributes. Each entity may be uniquely identified by its network element address and may include a full name attribute to provide a user-friendly name such as "A.FP1.DTLA1" as described above with respect to Figure 5. Each instance of the RPC manager 405 can support the comprehensive IDL getTopology() method for retrieving topology snapshots. Topology change events, such as CORBA events, can be sent when attribute values ​​change from each network element / entity, thereby allowing each RPC manager 405 to maintain a synchronized topology data model (see Figure 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 SOAP or REST. Therefore, the request message 408 can be written precisely so that it has a self-describing format from which the information schema can be derived. For example, JSON is self-describing in this format, which allows for relatively easy parsing and message adaptability. In contrast, IDL-based schemes such as CORBA require the IDL to understand the message's format. The request message 408 may specify at least one network element and an action to perform. The network element may be identified by a network element address, for example, the network element address 501 shown in Figure 5. The action may include a GET operation to obtain requested attributes / data for a desired network element, such as configuration parameters, log data, uptime, status, etc. The action may further include a SET operation to modify specific attributes / data.

[0031] The central manager gateway 401 can receive the request message 408. The central manager gateway 401 can then determine which master network element is currently processing the request. For example, as shown in Figure 4, network element A406-1 is operating as the master network element. Therefore, the central manager gateway 401 identifies network element A406-1 and forwards the request message 408 to it. Network element A406-1 then receives and processes the request message 408.

[0032] Network element A406-1, more specifically RPC manager 405, may utilize protocol-independent interface 409 to parse request message 408, for example using an HTTP parser module, to extract the network element address and the desired action. Network element A406-1 may perform authentication (for example using security manager 320) to determine whether to permit the requested action before or after determining that the requested network element exists and, further, managing any persistence required while maintaining the stateless attribute of the REST interface. RPC manager 405 may query 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 unknown, RPC manager 405 may send a NAK message, for example, an HTTP error code such as HTTP NOT_FOUND (404). If the network element is found in topology table 412 (and the request is permitted), RPC manager 405 determines whether the action in request message 408 can be performed via local data such as information / attributes stored in topology table 412. For example, some requests, such as status and uptime, can be served without necessarily communicating with remote network elements using CORBA messaging. One such example involves obtaining a list of subcomponents (e.g., LME ports, LME switch locations) under a network element (e.g., LME), and retrieving attributes of the network element and subcomponents, such as operating status, fault LED status, and / or inventory information (e.g., circuit pack model and physical location).

[0033] In events where the requested action cannot be performed using local data, the RPC manager 405 can communicate with the network element associated with the extracted network element address using the request broker 411. This communication may include, for example, using an IDL-based messaging scheme to send a message 422 that conforms to the CORBA protocol. For example, the request broker 411 may have a precompiled IDL instance (or adapter) associated with each network element in the system. Therefore, the request broker 411 may retrieve precompiled IDL from the IDL store 413 to instantiate the client with IDL 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 precompiled IDL adapters, each corresponding to one or more network elements. The request broker 411 may then translate the request message 408 into an equivalent IDL-based message based at least to some extent on the extracted network element address and the requested action. Furthermore, the request broker 411 may 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 action 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 action. The request broker 411 may then send message 422 to the network element associated with the network element address.

[0034] In one 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 require communication with two or more network elements, such as requests for log data, status, etc. In another example, a request may require calling two or more different remote procedure calls on network elements. For example, a request for multiple measurements, such as error count, power level, and retransmission count, may require calling multiple remote procedure calls using messaging 422 to satisfy a single request received by the RPC manager 405 from user 429. Thus, a single request message 408 may result in communication of message 422 with two or more network elements by calling / executing one or more remote procedure calls on two or more network elements.

[0035] Therefore, the RPC architecture 400 provided in this disclosure enables a 1:N relationship between a client 407 and multiple 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 limitations of the architecture, as CORBA is limited to a 1:1 direct client-server communication flow (see Figure 1 above).

[0036] Figure 6 shows an example of an IDL inheritance model 600 according to an aspect of this disclosure. As shown in the figure, the IDL inheritance model 600 includes a generic 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 generic central manager IDL 601 defines a common interface for all server components. The web service 602 may be instantiated by an RPC manager 406 (Figure 4) to handle user requests, e.g., REST requests, SOAP requests, and as described above with respect to Figure 4, the generic central manager-based IDL can be implemented for the purpose of translating requests into equivalent remote procedure calls.

[0037] Similarly, the RPC Manager Base IDL 603 may define common interfaces for each network element, such as remote procedure calls for retrieving status information, operational parameters, and diagnostic information. RPC Manager A IDL 604 and RPC Manager B IDL 605 may further define specific interfaces for one or more types of network elements. For example, RPC Manager A IDL 604 may define a specific interface for a Line Monitoring Equipment (LME), and RPC Manager B IDL 605 may define a specific interface for an optical relay device. Thus, network elements, for example, network elements 406-1 to 406-3, may derive specific IDLs for their device types to ensure that an appropriate interface for servicing requests is available. In another example, RPC Manager A IDL 604 and RPC Manager B IDL 605 may define “stubs” or placeholder functions that can be dynamically configured at runtime, allowing users to customize the logic associated with each given placeholder function. Therefore, each client / server instance can load two or more precompiled IDL adapters, namely, at least one first IDL adapter that defines common / default methods and functions for communication via CORBA, and a second IDL adapter that has stub / placeholder functions that allow runtime customization of exposed RPC behavior.

[0038] Figure 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, acting as a master for RPC management purposes, receives the IDL-based event message 702. Network element A406-1 translates 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 a network element address and an event type identifier. Network element A406-1 then transmits the web service message 703 to client 407.

[0039] Figures 8A to 8D provide a summary of examples of processing 800 for servicing requests using an RPC architecture that embodies the above aspects and embodiments. Processing 800 can be expressed as a series of machine-readable instructions that can be executed by the controller 305 (Figure 3) of the NMS 304 when it is 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, for example, client 407 (Figure 4). The web service request may be in a format conforming to REST or SOAP, for example. The web service request may include the addresses of one or more target network elements and an identifier for the operation to be performed on the target network elements. In operation 804, the central manager gateway 401 identifies which of the network elements is acting as the master. In the event that no master network element exists, in operation 808, the central manager gateway 401 sends a negative response (NAK) message, for example, an HTTP error code. The NAK message may be sent in the same format as the request received in operation 802, for example, REST, JSON, etc. Meanwhile, in operation 806, the central manager gateway 401 forwards / sends the web service request to the master RPC manager, for example, network element A406-1 as shown in Figure 4.

[0041] In operation 810, the master RPC manager receives the forwarded 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 Figure 5. In operation 814, the master RPC manager determines whether a network element exists that is associated with the extracted target network element address. This may include, for example, querying topology table 412 to determine if the extracted target network element address is known. If the target network element address exists, processing continues to operation 818; otherwise, processing continues to operation 816, in which the master RPC manager sends a NAK message back 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 and status, can be stored in topology table 412 or in memory 307. Therefore, attributes / features stored in local data can be used to service the request. If local data satisfies the request, the master RPC manager retrieves the information from 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, e.g., 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 network element associated with the extracted target network element address. Operation 824 may include a master RPC manager querying / performing a lookup on the IDL store 413 to identify the IDL that the RPC manager can communicate with the target network element. As shown above with respect to Figure 6, multiple network elements may be associated with the same RPC manager's IDL. Therefore, the RPC manager may simply retrieve a precompiled IDL adapter based on a known type of target network element. Alternatively or further, the IDL store 413 may associate each network element with a specific precompiled IDL adapter, for example, in a one-to-one relationship. Thus, the master RPC manager may determine which precompiled IDL adapter to use in the IDL store 413 based on the relationship between the target network element and its corresponding IDL.

[0044] In any event, following operation 826, the master RPC manager may identify one or more remote procedure calls, e.g., functions / methods, to call on the target network element based on the precompiled IDL adapter instantiated / selected in operation 824. In operation 828, the master RPC manager executes the one or more identified remote procedure calls on 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 generated response message through the central manager gateway 401 or by sending the generated response message directly to the client.

[0045] A network management system is disclosed according to an aspect of this disclosure. The network management system includes memory and a controller which receives a user request from a remote computing device, the user request includes at least one network element address and an identifier for an operation to be performed on at least one network element address, extracts at least one network element address and an identifier for an operation to be performed on at least one network element address, selects a precompiled interface description language (IDL) adapter from memory associated with at least one network element address, selects at least one remote procedure call (RPC) function that satisfies the user request based on the selected precompiled IDL adapter, executes at least one RPC function by sending at least one IDL-based message to one or more network elements associated with at least one network element address, and sends a response message to the remote computing device based on the response from the executed at least one RPC function, the response message being in the same format as the user request.

[0046] In other aspects of this disclosure, a computer implementation for servicing remote procedure call requests is disclosed. The computer implementation includes an operation by a controller to receive a user request from a remote computing device, wherein the user request includes a self-describing message including at least one network element address and an identifier for an operation to be performed on at least one network element address; an operation by the controller to extract at least one network element address and an identifier for an operation to be performed on at least one network element address; an operation by the controller to select a precompiled interface description language (IDL) adapter from memory associated with at least one network element address; an operation by the controller to select at least one remote procedure call (RPC) function that satisfies the user request based on the selected precompiled IDL adapter; an operation by the controller to execute at least one RPC function by sending at least one IDL-based message to one or more network elements associated with at least one network element address; and an operation by the controller to send 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.

[0047] In yet another aspect of this disclosure, an optical communication system is disclosed. The optical communication system comprises an optical communication path extending between a plurality of cable ground stations, each of which is associated with one or more network elements of a plurality of network elements arranged along the optical communication path, the system comprising an RPC gateway server, the RPC gateway server receiving user requests, the user request comprising a self-describing message comprising an identifier of an operation and an identifier of at least one network element that performs the operation and identifies a network element to act as a master network element, and the first message causes the master network element to select a precompiled interface description language (IDL) adapter corresponding to a network element associated with the identifier of at least one network element, and causes the master network element to send at least one message to a network element based on the selected IDL adapter and the operation.

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

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

[0050] Any block diagrams herein will be understood by those skilled in the art to represent a conceptual diagram of an explanatory circuit configuration embodying the principles of this disclosure. Similarly, any block diagrams, flowcharts, flow diagrams, state transition diagrams, pseudocode, etc., since substantially shown in a computer-readable medium, will be understood to represent various operations that can be performed by such a computer or processor, whether explicitly stated or not. Software modules, or mere modules suggested to be software, may be represented herein as any combination of elements of a flowchart or processing steps and / or other elements indicating the performance described herein. Such modules may be performed by explicitly or implicitly stated hardware.

[0051] The functionality of the various elements shown in the drawings may be provided through the use of dedicated hardware and software-executable hardware associated with appropriate software, including any functional block labeled “Processor.” Functionality may be provided by a single dedicated processor, a single shared processor, or by multiple individual processors, some of which may be shared. Furthermore, the explicit use of the term “Processor” should not be interpreted as referring exclusively to software-executable hardware, but 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), random-access memory (RAM), and non-volatile storage for storing software. Other conventional and / or custom hardware may also be included.

[0052] Unless otherwise specified, the use of the word “substantially” should be interpreted to include the exact relationships, circumstances, arrangements, orientations and / or other features, as well as variations thereof as understood by those skilled in the art, and to the extent of such variations, they should not substantially affect the disclosed methods and systems. Throughout this disclosure, the use of the articles “a” and / or “an” and / or “the” modifying nouns is for convenience and, unless otherwise specified, should be understood to include one or more of the nouns being modified. The terms “equip,” “include,” and “possess” are intended to be inclusive and to mean that there may be additional elements beyond those listed.

[0053] While methods and systems have been described for specific embodiments, they are not limited thereto. Clearly, many modifications and variations may become apparent from the viewpoint of the teachings above. Many additional changes to the details, materials, and arrangement of the parts described herein can be made by those skilled in the art.

[0054] The preceding description of examples of embodiments is provided for illustrative and descriptive purposes. It is exhaustive and not intended to limit this disclosure to any specific form disclosed. Many modifications and variations are possible in view of this disclosure. The scope of this disclosure is intended to be limited not by this detailed description but by the claims appended herein. [Other possible items] [Item 1] Memory for storing instructions; and, One or more processors coupled to the memory, operable to execute the instructions, Equipped with, If the instruction is executed, it will cause the one or more processors to: A request message is received from a remote computing device, where the request message includes a network element address, and the network element address is associated with a network element in an optical communication system; The precompiled interface description language (IDL) adapter associated with the network element address is selected from a library of multiple precompiled IDL adapters stored in the memory; Based on the selected precompiled IDL adapter, identify at least one remote procedure call (RPC) function to execute; The selected precompiled IDL adapter converts the request message into an IDL-based message; The IDL-based message is sent to the network element associated with the network element address; and, The remote computing device is instructed to send a response message based on the response from the execution of at least one of the RPC functions, wherein the response message is in the same format as the request message. Device. [Item 2] The aforementioned request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard. The device described in item 1. [Item 3] The aforementioned at least one RPC function is executed based on the Common Object Request Broker Architecture (CORBA) architecture. The device described in item 2. [Item 4] The network element address includes: (i) the identifier of the cable ground station, (ii) the element type, (iii) the element identifier (ID), and / or (iv) the subcomponent ID. The device described in item 1. [Item 5] The memory stores a topology table, which includes a plurality of network element addresses, each corresponding to a different network element in the optical communication system. The device described in item 1. [Item 6] Each of the precompiled IDL adapters in the library of the multiple precompiled IDL adapters is associated with one or more network elements in an optical communication system. The device described in item 1. [Item 7] When one or more processors select the precompiled IDL adapter associated with the network element address from the library of precompiled IDL adapters stored in memory: A lookup can be performed on the IDL adapter table, where the IDL adapter table includes multiple relationships between multiple network elements and multiple precompiled IDL adapters. The device described in item 1. [Item 8] On at least one processor: A procedure for receiving a request message from a remote computing device, wherein the request message includes a network element address; A procedure for selecting a precompiled interface description language (IDL) adapter associated with the aforementioned network element address from a library of multiple precompiled IDL adapters; A procedure for identifying at least one remote procedure call (RPC) function to execute based on the selected precompiled IDL adapter; A procedure for converting the request message into an IDL-based message using the selected precompiled IDL adapter; A procedure for sending the IDL-based message to the network element associated with the network element address; and, A procedure for sending a response message to the remote computing device based on a response from the execution of at least one RPC function, wherein the response message is in the same format as the request message. Computer-readable program code executable by at least one processor to cause the execution of the above. [Item 9] The aforementioned request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard. Computer-readable program code as described in item 8. [Item 10] The aforementioned at least one RPC function is executed based on the Common Object Request Broker Architecture (CORBA) architecture. Computer-readable program code as described in item 8. [Item 11] The network element address includes: (i) the identifier of the cable ground station, (ii) the element type, (iii) the element identifier (ID), and / or (iv) the subcomponent ID. Computer-readable program code as described in item 8. [Item 12] The at least one processor is further made to perform a procedure to access a topology table, the topology table including a plurality of network element addresses, each corresponding to a different network element in the optical communication system. Computer-readable program code as described in item 8. [Item 13] Each of the precompiled IDL adapters in the library of the multiple precompiled IDL adapters is associated with one or more network elements in an optical communication system. Computer-readable program code as described in item 8. [Item 14] In order to cause the at least one processor to perform the procedure 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 may further: The procedure involves performing a lookup on the IDL adapter table, the IDL adapter table containing multiple relationships between multiple network elements and multiple precompiled IDL adapters. Computer-readable program code as described in item 8. [Item 15] A non-temporary computer-readable storage medium containing computer-readable program code as described in any of items 8 through 14. [Item 16] In the step of receiving a request message from a remote computing device, the request message includes a network element address; One or more processors select a precompiled interface description language (IDL) adapter associated with the network element address from a library of multiple precompiled IDL adapters stored in memory; A step in which one or more processors identify at least one remote procedure call (RPC) function to be executed based on the selected precompiled IDL adapter; The step of converting the request message into an IDL-based message using the selected precompiled IDL adapter; The step of sending the IDL-based message to the network element associated with the network element address; and, A step of sending a response message to the remote computing device based on a response from the execution of at least one RPC function, wherein the response message is in the same format as the request message. A method for providing this. [Item 17] The aforementioned request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard. The method described in item 16. [Item 18] The aforementioned at least one RPC function is executed based on the Common Object Request Broker Architecture (CORBA) architecture. The method described in item 16. [Item 19] The network element address includes: (i) the identifier of the cable ground station, (ii) the element type, (iii) the element identifier (ID), and / or (iv) the subcomponent ID. The method described in item 16. [Item 20] The step further comprises accessing a topology table stored in the memory, wherein the topology table includes a plurality of network element addresses, each corresponding to a different network element in the optical communication system. The method described in item 16. [Item 21] The step of selecting the precompiled IDL adapter associated with the network element address from the memory to one or more processors is: The procedure includes the step of performing a lookup on an IDL adapter table, the IDL adapter table including multiple relationships between multiple network elements and multiple precompiled IDL adapters. The method described in item 16.

Claims

1. It is an optical communication system: An optical communication path extending between multiple cable ground stations, each of which is associated with one or more network elements among a plurality of network elements arranged along the optical communication path; Memory capable of storing libraries of multiple precompiled interface description language (IDL) adapters and topology tables of the multiple network elements; and A remote procedure call (RPC) gateway server capable of communicating with remote computing devices. Equipped with, The aforementioned RPC gateway server further states: The request message received from the remote computing device is analyzed based on the format of the request message to extract the network element address associated with a particular network element among the multiple network elements in the optical communication system, and the operation of the request message to be performed; In order to determine whether the extracted network element address is known, query the topology table; Based on the fact that the network element address is known, it is determined whether the operation of the request message can be performed using the local data stored in the topology table; In response to the determination that the operation cannot be performed using the local data, the precompiled IDL adapter associated with the network element address is selected from the library of the multiple precompiled IDL adapters stored in the memory; The selected precompiled IDL adapter converts the request message into an IDL-based message; To enable the aforementioned operation to be performed, the IDL-based message is sent to the network element associated with the extracted network element address; and, A response message is sent to the remote computing device based on the response from the execution of the aforementioned operation, the response message having the same format as the request message. It is possible to operate in this way. Optical communication system.

2. The optical communication system according to claim 1, wherein the operation is at least one remote procedure call (RPC) function identified based on the selected precompiled IDL adapter.

3. The optical communication system according to claim 1, wherein the request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard format.

4. The optical communication system according to claim 3, wherein the operation includes at least one RPC function performed based on the Common Object Request Broker Architecture (CORBA) architecture.

5. The optical communication system according to claim 1, wherein the network element address includes: (i) an identifier of a cable ground station, (ii) an element type, (iii) an element identifier (ID), and / or (iv) a subcomponent ID.

6. The optical communication system according to claim 1, wherein the topology table includes a plurality of network element addresses corresponding to different network elements in the optical communication system.

7. The optical communication system according to claim 1, wherein each of the plurality of precompiled IDL adapters in the library of plurality of precompiled IDL adapters is associated with one or more network elements in the optical communication system.

8. When the RPC gateway service selects the precompiled IDL adapter associated with the network element address from the library of multiple precompiled IDL adapters stored in memory: The optical communication system according to claim 1, wherein the system is operable to perform lookups within the library of the plurality of precompiled IDL adapters, and the library of the plurality of precompiled IDL adapters includes a plurality of associations between a plurality of network elements in the topology table and the plurality of precompiled IDL adapters in the library of the plurality of precompiled IDL adapters.

9. If executed by at least one processor, to the at least one processor: A procedure for analyzing a request message received from a remote computing device based on the format of the request message, and extracting the network element address associated with a particular network element among multiple network elements in an optical communication system, and the operation of the request message to be performed; A procedure for querying a topology table to determine whether the extracted network element address is known or not; A procedure for determining whether the operation of the request message can be performed using local data stored in the topology table, based on the fact that the network element address is known; A procedure to select a precompiled IDL adapter associated with the network element address from a library of multiple precompiled interface description language (IDL) adapters stored in memory, in response to a determination that the aforementioned operation cannot be performed using the local data; A procedure for converting the request message into an IDL-based message via the selected precompiled IDL adapter; To enable the aforementioned operation to be performed, a procedure for sending the IDL-based message to the network element associated with the extracted network element address; and, A procedure for sending a response message to the remote computing device based on the response from the execution of the aforementioned operation, wherein the response message is in the same format as the request message. To execute Computer-readable program code.

10. The computer-readable program code according to claim 9, wherein the request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard format.

11. The computer-readable program code according to claim 9, wherein the operation includes at least one RPC function that is performed based on the Common Object Request Broker Architecture (CORBA) architecture.

12. The computer-readable program code according to claim 9, wherein the network element address includes: (i) an identifier of a cable ground station, (ii) an element type, (iii) an element identifier (ID), and / or (iv) a subcomponent ID.

13. The computer-readable program code according to claim 9, wherein, when executed by the at least one processor, the at least one processor is further caused to perform a procedure to access the topology table, the topology table comprising a plurality of network element addresses corresponding to different network elements in the optical communication system, respectively.

14. The computer-readable program code according to claim 9, wherein each of the plurality of precompiled IDL adapters in the library of the plurality of precompiled IDL adapters is associated with one or more network elements in the optical communication system.

15. The procedure for selecting the aforementioned precompiled IDL adapter further includes: The computer-readable program code according to claim 9, comprising steps to perform a lookup within the library of the plurality of precompiled IDL adapters, wherein the library of the plurality of precompiled IDL adapters includes a plurality of associations between the plurality of network elements in the topology table and the plurality of precompiled IDL adapters in the library of the plurality of precompiled IDL adapters.

16. A method performed by a computer, The process involves analyzing a request message received from a remote computing device based on the format of the request message to extract the network element address associated with a particular network element among multiple network elements in an optical communication system, and the operation of the request message to be performed; Querying a topology table to determine whether the extracted network element address is known or not; Based on the fact that the network element address is known, determine whether the operation of the request message can be performed using the local data stored in the topology table; In response to the determination that the aforementioned operation cannot be performed using the local data, select a precompiled IDL adapter associated with the network element address from a library of multiple precompiled interface description language (IDL) adapters stored in memory; Converting the request message into an IDL-based message via the selected precompiled IDL adapter; To enable the above operation to be performed, the IDL-based message is sent to the network element associated with the extracted network element address; and, A response message is sent to the remote computing device based on the response from the execution of the aforementioned operation, and the response message is in the same format as the request message. A method for providing this.

17. The method according to claim 16, wherein the request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard format, and the operation includes at least one RPC function that is performed based on the Common Object Request Broker Architecture (CORBA) architecture.

18. The method according to claim 16, wherein the network element address includes: (i) an identifier of a cable ground station, (ii) an element type, (iii) an element identifier (ID), and / or (iv) a subcomponent ID.

19. The method according to claim 16, wherein the topology table includes a plurality of network element addresses, each corresponding to a different network element in the optical communication system.

20. Selecting the precompiled IDL adapter associated with the aforementioned network element address means: The method according to claim 16, comprising performing a lookup within the library of the plurality of precompiled IDL adapters, wherein the library of the plurality of precompiled IDL adapters includes a plurality of associations between the plurality of network elements in the topology table and the plurality of precompiled IDL adapters in the library of the plurality of precompiled IDL adapters.

Images