Technique for interfacing between web service and interface description language (IDL) based remote procedure call (RPC) service and optical communication system performing 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 relates generally to communication systems that utilize remote procedure call (RPC) interfaces, and more particularly to a system and method for interfacing between web services and IDL-based RPC services, and an optical communication system using the same. [Background technology]

[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, Representative State Transfer (REST) ​​has become one of the most popular and fastest growing. There is an increasing need for software that provides RESTful APIs to accommodate the development and integration of customized client-end-user interfaces. Most development languages ​​now include frameworks for building RESTful web services.

[0003] However, many existing implementations utilize the Common Object Request Broker Architecture (CORBA), developed during the early days of the Internet. CORBA is a software standard defined by the Object Management Group that many systems employ for cross-platform communication to maximize the benefits of different programming languages ​​and manage distributed network element services (NES). For example, consider C++ development; because native C++ development environments lack native support for graphical user interfaces (GUIs), C++ requires other development languages ​​(e.g., Java) to support GUI development. Similarly, CORBA uses an interface definition language (IDL) to coordinate the interfaces and objects presented to different implementations (e.g., C, C++, Java, Pascal, Python, Ruby), allowing developers to develop cross-platform communication software without having to "reinvent the wheel" and, by extension, saving the costs and time associated with developing such software systems. CORBA provides a well-defined form of cross-platform communication that is accessible at the object level, with much of the underlying client-server communication code hidden from the developer. Similarly, CORBA features a naming service that provides developers with a simple way to register and look up object references using logical names.

[0004] However, CORBA presents difficult solutions due to non-trivial challenges. For example, both clients and servers in a CORBA architecture must use the same IDL at runtime to ensure compatibility. Inconsistencies between the IDLs result in a complete breakdown of communication between the client and server. This makes CORBA implementations relatively fragile, as even minor changes and upgrades to exposed functions / methods require synchronization between the server and all clients, which can be difficult to implement. Furthermore, many existing solutions utilize some degree of proprietary CORBA elements, requiring knowledge not only of CORBA itself but also of the nature of changes to core services. This proprietary knowledge requires extensive training and, unfortunately, often results in the complete redevelopment of legacy CORBA software services from scratch, rather than the reuse of other functional software.

[0005] Reference should be made to the following detailed description which should be read in conjunction with the following drawings, in which like numerals represent like parts and in which: [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a simplified block diagram of the communication architecture for a CORBA client and server. [Figure 2] FIG. 2 is a simplified block diagram of an exemplary embodiment of an optical communication system according to the present disclosure. [Figure 3] FIG. 3 is a simplified block diagram of an exemplary embodiment of a network management system (NMS) suitable for use in the optical communication system of FIG. [Figure 4] FIG. 4 is a simplified block diagram of an exemplary embodiment of a remote procedure call (RPC) architecture for use in the optical communication system of FIG. [Figure 5]FIG. 5 shows an example of a network element address format for use in the RPC architecture of FIG. [Figure 6] FIG. 6 illustrates a simplified block diagram of an Interface Description Language (IDL) inheritance model according to an aspect of the present disclosure. [Figure 7] FIG. 7 illustrates an example of communication for an IDL-based event message according to an embodiment of the present disclosure. [Figure 8A] FIG. 8A summarizes an example method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Figure 8B] FIG. 8B summarizes an example method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Figure 8C] FIG. 8C summarizes an example method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. [Figure 8D] FIG. 8D summarizes an example method for servicing RPC requests within an optical communication system according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0007] As noted above, while CORBA-based implementations are in use in many deployed software applications, the technology remains challenging to develop and maintain compared to currently widely used Web-based technologies. Meanwhile, the problem of creating new software systems that retain the functional components and legacy support of existing CORBA-based systems remains challenging, as so many technical challenges remain in attempting to blend CORBA and modern Web-based implementations.

[0008] The existing CORBA development process involves defining an IDL in plain text. The IDL language, similar to other compiled / interpreted languages, includes syntax and formatting to define methods, arguments, and various parameters. The plain text IDL is then compiled to generate an adapter in the desired language, e.g., C++ or Java. The generated adapter is also sometimes referred to as a precompiled IDL adapter that can be instantiated during the runtime (execution) of a given program. As shown in Figure 1, CORBA client and server applications then form a 1:1 relationship between the client and server based on their associated 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 at a time when the Internet was in its infancy and security was not a primary concern. CORBA did not natively enforce security mechanisms, and CORBA interfaces pose substantial security risks. Careless exposure of CORBA interfaces is a potential threat to the entire software system because CORBA has no security checks at the interface level, leaving the server exposed to the Internet and an easy target for attackers.

[0010] Fundamental IDL upgrades and minor changes also pose significant challenges for using CORBA. For example, both the client and server must have consistent IDLs, so any changes require recompiling both the client and server code with the updated IDL for synchronization purposes. This level of synchronization is difficult to achieve because separate teams working on client and server code often have multiple developers who can implement changes at a rate that makes full client / server IDL compatibility virtually impossible. Furthermore, even though software engineers often avoid reusing existing CORBA implementations as a security risk, CORBA's legacy knowledge and rigidity can outweigh the drawbacks of redeveloping the code using modern technologies such as Simple Object Access Protocol (SOAP) and REST. Several approaches for exposing CORBA interfaces via modern web services, e.g., REST and SOAP, have been proposed to enable CORBA reuse. However, these approaches still require a significant amount of development time and experience because communication processes between middleware and CORBA interfaces must be developed.

[0011] Thus, according to embodiments, techniques are disclosed for interfacing an IDL-based RPC architecture, e.g., CORBA, with a Web services approach, such as SOAP and REST. In particular, embodiments of the present disclosure include an RPC architecture including a central manager gateway having a client-facing side that enables client access via Web services protocols, such as SOAP and REST. The central manager gateway further includes a server-facing side that can communicate with multiple network elements, each 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, e.g., a CORBA naming service. Network elements can select a master element while others remain slaves. The central manager gateway can automatically locate the master network element and forward client requests thereto. Similarly, the master network element can translate Web services requests and execute one or more IDL methods to fulfill the requests. The master network element may then convert responses to executed IDL methods into Web service messages and send them back to the originating client, for example, by a central manager gateway acting as a proxy, or directly back to the client depending on the desired configuration. Because REST enforces a stateless architecture, Web services do not support persistence of data messages across REST API calls. The central manager gateway manages and facilitates such persistence, so that the integrity of the CORBA infrastructure / services can be maintained while also supporting REST Web service messages.

[0012] In one specific, non-limiting example of an embodiment of the present disclosure, an IDL framework is disclosed that enables the creation of multiple Java adapters. A first one of the Java adapters includes IDL definitions defined for a CORBA-based C++ system to enable compilation and generic CORBA communication, and a second one of the Java adapters includes definitions that provide runtime services. Runtime services may be provided, for example, by stub definitions that can be overridden or extended by an application programmer to implement logic specific to a given application. A RESTful service may then implement multiple adapters that provide REST services that conform to IDL requirements, e.g., CORBA, and provide application-specific logic to end users in a customized and integrated manner. A graphical user interface (GUI) library based on the IDL may also be created 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 a GUI). In the context of a REST server, adapters may be pre-packaged libraries where the methods defined and implemented can be directly called and packaged together with other features supported by the integrated development environment.

[0013] Thus, the present disclosure offers numerous advantages over existing systems that shoddily expose IDL-based services, or other approaches that inhibit code reuse by redesigning and developing pre-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 rapid development and extensible framework with a high level of customization and code reuse. Furthermore, modern services such as SOAP and REST can be client-directly enabled to provide secure and easily developed client access. Thus, the RPC architecture disclosed herein enhances computer service systems by preserving legacy code applications (e.g., fully compatible with existing CORBA services) and eliminating the requirement for prior knowledge to 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 according to the present disclosure allows for a 1:N relationship between clients and IDL-based services, e.g., CORBA, which goes beyond the limitations that typically impose a 1:1 relationship between clients and servers, as described above with respect to FIG. 1.

[0014] In the drawings, Figure 2 illustrates an optical communication system 200 in accordance with 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 may be implemented as a subsea optical communication system, with at least some of the elements located below the ocean surface. Additionally, the optical communication system 200 may be implemented as a wavelength division multiplexing (WDM) system capable of transmitting over multiple channel wavelengths. As illustrated, the optical communication system 200 includes an optical transmission path 203 extending between multiple cable land stations, namely, cable land stations 202-1, 202-2, and 202-3.

[0015] As shown, optical communication 200 includes fiber optic cables, shown collectively as 210, that span relatively large geographic distances (e.g., tens, hundreds, or thousands of kilometers). Accordingly, a submarine optical network may comprise multiple "wet" optical components, for example, deployed along the ocean floor or on an offshore platform. However, cable segments are not necessarily limited in this regard, and optical communication system 200 may include at least some length of terrestrial optical fiber segments. While the examples and scenarios disclosed herein refer to cable land stations, i.e., CLSs, the disclosure is not necessarily limited in this regard. For example, the techniques disclosed herein are equally applicable to any station located within an optical communication system, including, for example, network operations centers (NOCs) and remote operating positions (ROPs), to name a few.

[0016] Optical transmission path 203, in turn, includes at least one optical cable 210 comprising one or more optical fiber pairs. 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 filters / components (e.g., which may include circuitry for remote monitoring and control) to transmit and receive channel wavelengths from branch paths, e.g., branch path 214. Each cable land station may include an element management system (EMS) to provide access to the 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 allows remote access for configuration, monitoring, and maintenance purposes. For this purpose, the term network element refers to any component in optical communication system 200, e.g., BU, ROADM, optical repeater, NMS, EMS, LME, PFE, that includes circuitry and / or software that enables remote network-based communications over wired or wireless connections.

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

[0018] As further shown, first cable earth station 202-1 includes NMS 204-1, EMS 206-1, and LME 208-1. NMS 204-1 may be implemented as NMS 304, which will be described in further detail with reference to FIG. 3 . Each NMS may be configured to communicate with N EMS systems, each of which may be configured to communicate with optical components local to a given cable earth station or adjacent repeaters and other elements. LME equipment may be utilized to perform high-loss loopback (HLLB) or other measurements to ensure nominal performance and detect defects, e.g., cable breaks, along optical transmission path 203.

[0019] Optionally, two or more cable land stations may include similar components for redundancy and fault tolerance, as well as for local management of network elements. For example, the second cable land station 202-2 may include an NMS 204-2, an EMS 206-2, and an LME 208-2. As described further below, each of the NMS components 204-1, 204-2 may collectively form a single NMS system 304, whereby a user can log in to either NMS component and have requests serviced, 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, whereby slave NMS systems proxy or forward requests to the master for handling. In the event that the master NMS goes offline, the optical communications system 200 may be configured to automatically switch the slave NMS to the master role.

[0020] FIG. 3 illustrates an example 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 may be implemented in different configurations, including, for example, multiple NMS servers, EMS servers, LMEs, etc., that collectively provide the NMS architecture 304. In this manner, components may be distributed across multiple cable land stations, e.g., CLS 202-1 through CLS 202-3 in FIG. 2, to provide redundancy, fault tolerance, and multiple access points for users of the NMS architecture 200. Thus, the NMS 204 may be collectively implemented as a single NMS server, e.g., NMS 204-1, or may comprise multiple NMS systems, e.g., NMS 204-1 and 204-2, as shown in FIG. 2.

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

[0022] User interface 324 may include 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 another embodiment, the API of the user interface 324 may implement a CORBA architecture. Security manager 320 may be configured to ensure that requests 301 received from a user are permissible based on the user's associated privileges and access rights.

[0023] The NMS 204 may include a system resource database 312 stored in memory 307. The system resource database 312 may be distributed across multiple components, including, for example, multiple NMSs and EMSs; the embodiment shown in FIG. 3 is not intended to be limiting. For example, each cable land station may include an EMS that stores data indicative of 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 branching units. The NMS 203 may then utilize the EMS data from each of the cable land stations to collectively and logically form a system resource table 312, although the data may be physically distributed across different cable land stations. 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] FIG. 4 illustrates 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, 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 smartphone having a controller / processor, memory, a user interface, etc. The central manager gateway 401 may also be referred to as an RPC gateway 401. Note that the central manager gateway 401 may be instantiated by one of the network elements 406-1 or by a different server computer in 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 services 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. Thus, the web services 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, 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, each of network elements 406-1 through 406-N may include circuitry and / or software that executes an instance of RPC manager 405. Those network elements that instantiate RPC manager 405 may also be referred to as network element managers. Each of network elements 406-1 through 406-N may be implemented as an NMS server, such as NMS server 304 described above with reference to FIG. 3. However, each network element 406-1 through 406-N may also be implemented as other types of systems, including rack-mounted computer servers. In any event, each network element 406-1 through 406-N may include instructions that, when executed by an associated processor / controller, cause a local instance of an RPC manager process to run. Network elements may communicate with each other to elect a "master" element, for example, via voting or by simply having any network element come online first. As shown in Figure 4, network element 406-1 is the master element and therefore hosts RPC manager 405, which is accessible to clients 407 by central manager gateway 401.

[0026] Each instance of RPC manager 405 may include multiple components, including protocol-independent interface 409 and request broker 411. Protocol-independent interface 409 may include N parser modules to service requests via REST or other desired protocols. The parser modules may parse requests to determine if the request is valid (e.g., not malformed), whether the request is allowed (e.g., by using security manager 320), and what the request entails. Request broker 411 may include a generic central manager IDL parser, which is described in more detail below with reference to FIG. 6. For example, the IDL parser may utilize precompiled IDL, also known as an adapter, that is output from CORBA IDL. In this example, request broker 411 may provide CORBA naming service 414. CORBA naming service 414 allows other CORBA server applications to publish object references using logical names. Thus, client 407 can request an operation 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 FIG. 5, network element B 406-2 and network element C 406-3 may be uniquely identified within optical communication system 200 based on network element address 501. Network element address 501 may include a string that conforms to a scheme that allows each cable land station to have multiple associated network elements. However, other naming schemes may be utilized, and the example shown in FIG. 5 is not intended to be limiting. Each network element address may include a predetermined series of entity type / entity ID pairs that convey the hierarchy of network elements and subcomponents within the cable land 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] 5, network element address 501 may identify at least one or more of cable earth station identifier 502, fiber pair identifier 503, element type ID 504, and element ID 505. Moreover, the network element address may include a subcomponent ID, such as subcomponent ID 506. Thus, each network element may be assigned a network element address that may be registered with naming service 414. Note that while a master network element, e.g., network element A 406-1 shown in FIG. 4, is performing a name lookup for the purpose of servicing a request, other network elements, e.g., network elements A 406-2 through A 406-N, may 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 registration messages from other network elements in the optical communication system 200. The registration data can be stored in a topology table 412 for use by a naming service 414. The registration data can 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 can be stored in an 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, with each component represented as an entity with attributes and child entities representing the subcomponents. Each entity can then 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 a generic IDL getTopology() method to retrieve a topology snapshot. Topology change events, e.g., CORBA events, can be sent when attribute values ​​change from each network element / entity, allowing each RPC manager 405 to maintain a synchronized topology data model (see FIG. 7).

[0030] In operation, client 407 sends a request message 408. The request message 408 may be formatted in a web services protocol, such as SOAP or REST. Thus, the request message 408 may be precisely written to have a self-describing format in which the information schema can be derived from the message itself. For example, JSON is self-describing in this format, allowing for relatively easy parsing and message adaptability. In contrast, IDL-based methods, such as CORBA, require the IDL to understand the message format. The request message 408 may identify at least one network element and an operation to perform. The network element may be identified by a network element address, such as network element address 501 shown in FIG. 5. The operation may include a GET operation to obtain requested attributes / data for the desired network element, such as configuration parameters, log data, uptime, status, etc. The operation may further include a SET operation to change the specified attributes / data.

[0031] The central manager gateway 401 may receive the request message 408. The central manager gateway 401 may then determine the current master network element to process the request. For example, as shown in Figure 4, network element A 406-1 is acting as the master network element. Therefore, the central manager gateway 401 locates network element A 406-1 and forwards the request message 408 to it. Network element A 406-1 then receives and processes the request message 408.

[0032] The network element A 406-1, and more specifically, the RPC manager 405, may utilize the protocol-independent interface 409 to parse the request message 408 using, for example, an HTTP parser module to extract the network element address and the desired operation. The network element A 406-1 may perform authentication (e.g., using the security manager 320) to determine whether the requested operation is permitted, either before or after determining that the requested network element exists and further managing any persistence required while maintaining the stateless attributes of the REST interface. The RPC manager 405 may 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 status and uptime, can be serviced without necessarily communicating with a remote network element using CORBA messaging. One such example includes obtaining a list of subcomponents (e.g., LME ports, LME switch locations) under a network element (e.g., LME), and retrieving network element and subcomponent attributes such as operational status, fault LED status, and / or inventory information (including, for example, circuit pack model and physical location).

[0033] In the event that the requested operation cannot be performed using local data, RPC manager 405 can utilize request broker 411 to communicate with the network element associated with the extracted network element address. This communication can include, for example, using an IDL-based messaging scheme to send a message 422 conforming to a CORBA protocol. For example, request broker 411 can have a precompiled IDL instance (or adapter) associated with each of the network elements in the system. Accordingly, request broker 411 can retrieve the precompiled IDL from IDL store 413 to instantiate the client with an IDL compatible with the target network element. As described above, the client's IDL must match the server's IDL in CORBA-based client-server communication. Therefore, IDL store 413 can include a library of precompiled IDL adapters, each corresponding to one or more network elements. Request broker 411 can then convert request message 408 into an equivalent IDL-based message based at least in part on the extracted network element address and the requested operation. Further, request broker 411 may identify one or more remote procedure calls to execute using an IDL that corresponds to the network element associated with the extracted network element address. For example, the requested operation may be to retrieve a particular configuration setting, and the IDL may define a remote procedure call, GET_PARAMETER(), that can be used to fulfill the requested operation. Request broker 411 may then send message 422 to the network element associated with the network element address.

[0034] In one example scenario, request broker 411 may identify two or more remote procedure calls to execute using one or more precompiled IDL adapters to fulfill request message 408. For example, a request may require communicating with two or more network elements, such as a request for log data, status, etc. In another example, a request may require calling two or more different remote procedure calls on a network element. For example, a request for multiple measurements, such as error counts, power levels, and retransmit counts, may require calling multiple remote procedure calls using messaging 422 to fulfill a request received by RPC manager 405 from user 429. Thus, a 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 the two or more network elements.

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

[0036] 6 illustrates an example of an IDL inheritance model 600 according to an aspect of the present disclosure. As illustrated, 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 the RPC manager 406 (FIG. 4) to handle user requests, e.g., REST requests, SOAP requests, and may implement the generic central manager-based IDL to translate the requests into equivalent remote procedure calls, as described above with respect to FIG. 4.

[0037] Similarly, RPC manager base IDL 603 may define interfaces common to each network element, such as remote procedure calls to obtain status information, operational parameters, and diagnostic information. RPC manager A IDL 604 and RPC manager B IDL 605 may further define interfaces specific to one or more types of network elements. For example, RPC manager A IDL 604 may define an interface specific to line monitoring equipment (LME), and RPC manager B IDL 605 may define an interface specific to optical repeater devices. Thus, network elements, e.g., network elements 406-1 through 406-3, may derive IDLs specific to their device types to ensure that the appropriate interface is available to service requests. In another example, RPC manager A IDL 604 and RPC manager B IDL 605 may define "stub" or placeholder functions that can be dynamically configured at runtime to allow users to customize the logic associated with each given placeholder function. Thus, each client / server instance can load two or more precompiled IDL adapters: at least a first IDL adapter that defines, for example, common / default methods and functions for communicating via CORBA, and a second IDL adapter with stub / placeholder functions that allow run-time customization of exposed RPC operations.

[0038] 7 illustrates an example of an event communication flow according to an embodiment of the present disclosure. As illustrated, network element B 406-2 sends an IDL-based event message 702. For example, the IDL-based event message 702 may conform to the CORBA protocol. Network element A 406-1, acting as a master for RPC management purposes, receives the IDL-based event message 702. Network element A 406-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 a network element address and an event type identifier. Network element A 406-1 then sends the Web service message 703 to client 407.

[0039] 8A-8D collectively provide an example process 800 for servicing requests via an RPC architecture embodying the above aspects and embodiments. Process 800 may be manifested as a plurality of machine-readable instructions that may be executed by controller 305 (FIG. 3) of NMS 304 when acting as an RPC manager or 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 may be in a format conforming to, for example, REST or SOAP. The web service request may include one or more target network element addresses and an identifier of an operation to perform on the target network element. In operation 804, the central manager gateway 401 determines which of the network elements is acting as the master. In the event that there is no master network element, in operation 808, the central manager gateway 401 sends a negative acknowledgement (NAK) message, e.g., an HTTP error code. The NAK message may be sent in the same format as the request received in operation 802, e.g., REST, JSON, etc. Meanwhile, in operation 806, the central manager gateway 401 forwards / sends the web service request to a master RPC manager, e.g., network element A 406-1 as shown in FIG. 4.

[0041] At operation 810, the master RPC manager receives the forwarded web service request. At operation 812, the master RPC manager extracts a 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 shown and described above with respect to FIG. 5. At operation 814, the master RPC manager determines whether a network element associated with the extracted target network element address exists. This may include, for example, querying topology table 412 to determine whether 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, where 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 at 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., can be stored in the topology table 412 or in the memory 307. Thus, attributes / features stored in the local data can be used to service the request. If the local data satisfies the request, the master RPC manager retrieves the 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, adapter) corresponding to the target network element associated with the extracted target network element address. Operation 824 may include the master RPC manager querying / performing a lookup on the IDL store 413 to identify an IDL that enables the RPC manager to communicate with the target 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 precompiled IDL adapters based on known types of target network elements. Alternatively, or in addition, the IDL store 413 may associate each network element with a particular precompiled IDL adapter, for example, in a 1:1 relationship. Thus, the master RPC manager may determine which precompiled IDL adapter to use based on the association between the target network element and its corresponding IDL in the IDL store 413.

[0044] In either 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 identified one or more remote procedure calls against the target network element. In operation 830, the master RPC manager receives a response from the executed remote procedure call and generates a response message based on the response in the same format, e.g., XML / JSON, of the request received from the client in operation 802. In operation 832, the master RPC manager sends the generated response message to the client, for example, by routing the generated response message through 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, comprising: a memory; and a controller: receiving 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 perform on the at least one network element address; extracting the at least one network element address and the identifier of the operation to perform on the at least one network element address; selecting from the memory a precompiled Interface Description Language (IDL) adapter associated with the at least one network element address; selecting at least one remote procedure call (RPC) function to satisfy the user request based on the selected precompiled IDL adapter; executing 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 sending a response message to the remote computing device based on a response from the executed at least one RPC function, wherein the response message has the same format as the user request.

[0046] According to another aspect of the present disclosure, a computer-implemented method for servicing remote procedure call requests is disclosed. The computer-implemented method includes operations 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 perform on the at least one network element address; extracting, by the controller, the at least one network element address and the identifier of the operation to perform on the at least one network element address; selecting, by the controller, a precompiled Interface Description Language (IDL) adapter associated with the at least one network element address from a memory; selecting, by the controller, at least one remote procedure call (RPC) function to satisfy the user request based on the selected precompiled IDL adapter; 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 sending, by the controller, 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] According to yet another aspect of the present disclosure, an optical communication system is disclosed, the optical communication system including an optical communication path extending between a plurality of cable land stations, each of the plurality of cable land stations being associated with one or more network elements 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 a self-describing message including an identifier of an operation and an identifier of at least one network element that performs the operation, identifies a network element that acts as a master network element, and sends a first message to the identified master network element, the first message causing the master network element to select a precompiled Interface Description Language (IDL) adapter corresponding to the network element associated with the at least one network element identifier, and causes 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, processor, and / or other programmable device. To that end, 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, NMS 304 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 a floppy disk, an optical disk, any type of disk including compact disk read-only memory (CD-ROM), compact disk re-writeable (CD-RW), and magneto-optical disk, a read-only memory (ROM), a RAM such as dynamic and static random access memory (RAM), a semiconductor device such as an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic or optical card, or any type of medium suitable for storing electronic instructions.

[0050] Those skilled in the art will understand that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the present disclosure. Similarly, any block diagram, flowchart, flow diagram, state diagram, pseudocode, or the like, substantially as depicted in a computer-readable medium, will be understood to represent various operations that may be performed by such a computer or processor, whether or not such a computer or processor is explicitly shown. Software modules, or merely modules that are implied to be software, may be illustrated herein as any combination of flowchart elements or process steps and / or other elements that illustrate the performance of the descriptions herein. Such modules may be implemented by hardware where explicitly or implicitly shown.

[0051] The functionality of the various elements shown in the figures, including any functional blocks labeled "processor," may be provided through the use of dedicated hardware and hardware capable of executing software in association with appropriate software. Functions may be provided by a single dedicated processor, by 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 construed as referring exclusively to hardware capable of executing software, 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) 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" may be construed to include the exact relationships, circumstances, arrangements, orientations, and / or other characteristics, and variations thereof, as would be understood by one of ordinary skill in the art, to the extent that such variations do not materially affect the disclosed methods and systems. Throughout this disclosure, the use of the articles "a" and / or "an" and / or "the" to modify a noun is used for convenience and may be understood to include one or more of the modified noun, unless otherwise specified. The terms "comprise," "include," and "have" are intended to be inclusive and mean that there may be additional elements other than the listed elements.

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

[0054] The foregoing description of 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 form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims appended hereto. [Other possible items] [Item 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, wherein the request message includes 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 adapter; converting 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. [Item 2] the request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard; Item 1. The device according to item 1. [Item 3] The at least one RPC function is implemented based on the Common Object Request Broker Architecture (CORBA) architecture. Item 2. The device according to item 2. [Item 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; Item 1. The device according to item 1. [Item 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; Item 1. The device according to item 1. [Item 6] each of the plurality of precompiled IDL adapters in the library of precompiled IDL adapters is associated with one or more network elements in an optical communications system; Item 1. The device according to item 1. [Item 7] When the one or more processors select the precompiled IDL adapter associated with the network element address from the library of the plurality of precompiled IDL adapters stored in the memory, they: performing a lookup on an IDL adapter table, wherein the IDL adapter table includes a plurality of associations between a plurality of network elements and a plurality of precompiled IDL adapters; Item 1. The device according to item 1. [Item 8] For at least one processor: receiving a request message from a remote computing device, wherein the request message includes 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 into 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 computer readable program code executable by the at least one processor to cause the at least one processor to execute the [Item 9] the request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard; Item 9. The computer readable program code of item 8. [Item 10] The at least one RPC function is implemented based on the Common Object Request Broker Architecture (CORBA) architecture. Item 9. The computer readable program code of item 8. [Item 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; Item 9. The computer readable program code of item 8. [Item 12] and causing the at least one processor to further 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 the optical communication system. Item 9. The computer readable program code of item 8. [Item 13] each of the plurality of precompiled IDL adapters in the library of precompiled IDL adapters is associated with one or more network elements in an optical communications system; Item 9. The computer readable program code of item 8. [Item 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: performing a lookup on an IDL adapter table, the IDL adapter table including a plurality of associations between a plurality of network elements and a plurality of precompiled IDL adapters; Item 9. The computer readable program code of item 8. [Item 15] A non-transitory computer-readable storage medium storing the computer-readable program code according to any one of items 8 to 14. [Item 16] 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 into 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 [Item 17] the request message conforms to the Simple Object Access Protocol (SOAP) standard or the Representative State Transfer (REST) ​​standard; Item 17. The method according to item 16. [Item 18] The at least one RPC function is implemented based on the Common Object Request Broker Architecture (CORBA) architecture. Item 17. The method according to item 16. [Item 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; Item 17. The method according to item 16. [Item 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; Item 17. The method according to item 16. [Item 21] The step of causing one or more processors to select from the memory the precompiled IDL adapter associated with the network element address comprises: performing a lookup on an IDL adapter table, the IDL adapter table including a plurality of associations between a plurality of network elements and a plurality of precompiled IDL adapters; Item 17. The method according to item 16.

Claims

1. 1. An optical communication system comprising: an optical communication path extending between a plurality of cable land stations, each of the plurality of cable land stations associated with one or more network elements of a plurality of network elements disposed along the optical communication path; a memory operable to store a library of a plurality of precompiled Interface Description Language (IDL) adapters and a topology table for the plurality of network elements; and a remote procedure call (RPC) gateway server operable to communicate with a remote computing device; Equipped with The RPC gateway server further: parsing a request message received from the remote computing device based on a format of the request message to extract a network element address associated with a network element of the plurality of network elements in the optical communication system and an operation of the request message to be performed; querying the topology table to determine whether the extracted network element address is known; determining whether the operation of the request message can be performed using local data stored in the topology table based on the network element address being known; in response to determining that the operation cannot be performed using the local data, selecting a precompiled IDL adapter associated with the network element address from the library of the plurality of precompiled IDL adapters stored in the memory; converting the request message into an IDL-based message via the selected precompiled IDL adapter; sending the IDL-based message to the network element associated with the extracted network element address to enable the action to be performed; and sending a response message to the remote computing device based on a response from the execution of the operation, the response message being in the same format as the request message; It is operable as Optical communication system.

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

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

4. 4. The optical communication system of claim 3, wherein the operations include at least one RPC function performed in accordance with a Common Object Request Broker Architecture (CORBA) architecture.

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

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

7. 2. The optical communication system of claim 1, wherein each of the plurality of precompiled IDL adapters in the library 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 the plurality of precompiled IDL adapters stored in the memory:

2. The optical communications system of claim 1, operable to perform a lookup in the library of the plurality of precompiled IDL adapters, the library of the plurality of precompiled IDL adapters including 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. When executed by at least one processor, the at least one processor: parsing a request message received from a remote computing device based on a format of the request message to extract a network element address associated with a network element of a plurality of network elements in an optical communication system and an operation of the request message to be performed; querying a topology table to determine whether the extracted network element address is known; determining whether the operation in the request message can be performed using local data stored in the topology table based on the network element address being known; responsive to determining that the operation cannot be performed using the local data, 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 memory; converting the request message to an IDL-based message via the selected precompiled IDL adapter; sending the IDL-based message to the network element associated with the extracted network element address to enable the operation to be performed; and sending a response message to the remote computing device based on a response from the execution of the operation, the response message being in the same format as the request message; Execute Computer readable program code.

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

11. 10. The computer readable program code of claim 9, wherein the operations include at least one RPC function performed in accordance with a Common Object Request Broker Architecture (CORBA) architecture.

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

13. 10. The computer readable program code of claim 9, which, when executed by the at least one processor, further causes the at least one processor to perform a procedure for accessing the topology table, the topology table including a plurality of network element addresses each corresponding to a different network element in the optical communication system.

14. 10. The computer readable program code of 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 communications system.

15. The step of selecting the precompiled IDL adapter further comprises:

10. The computer readable program code of claim 9, further comprising: performing a lookup in the library of the plurality of precompiled IDL adapters, the library of the plurality of precompiled IDL adapters including 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. 1. A computer-implemented method comprising: parsing a request message received from a remote computing device based on a format of the request message to extract a network element address associated with a network element of a plurality of network elements in an optical communication system and an operation of the request message to be performed; querying a topology table to determine whether the extracted network element address is known; determining whether the operation of the request message can be performed using local data stored in the topology table based on the network element address being known; responsive to determining that the operation cannot be performed using the local data, selecting a precompiled Interface Description Language (IDL) adaptor associated with the network element address from a library of a plurality of precompiled IDL adaptors stored in a memory; converting the request message into an IDL-based message via the selected precompiled IDL adapter; sending the IDL-based message to the network element associated with the extracted network element address to enable the operation to be performed; and sending a response message to the remote computing device based on a response from the execution of the operation, the response message being in the same format as the request message; A method for providing

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

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

19. 17. The method of 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 network element address includes:

17. The method of claim 16, comprising performing a lookup in the library of the plurality of precompiled IDL adapters, the library of the plurality of precompiled IDL adapters comprising 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