Proxy
Revised: July 2010, OL-23043-01
The Proxy software is an extension in the CORBA Software Developer's kit (SDK) package that allows several new features to be integrated into the client application. The Proxy software is also designed to work exclusively with the new and revised SSL or secure CORBA interface to the BTS 10200.
The feature capabilities are:
•Abstraction of redundant management interfaces on a single BTS 10200 Element Management System (EMS) node. Each EMS has two physical network interface cards (NICs) available for provisioning, and the CORBA/SSL package utilizes both of these interfaces by binding object instances separately to each interface. The Proxy probes each of these interfaces and determines which interface is functioning or if both interfaces are functioning. The first interface to return the requested BTS 10200 object is declared the primary interface and is used exclusively for transactions, The CORBA protocol IIOP/SSLIOP requires a consistent conversation over a single interface so "load sharing" on these interfaces in a given connection is not possible.
•Abstract the redundancy of the EMS from the client application. Many client applications do not fully account for the duplex nature of the BTS 10200 and as a result must exercise some complex reinitialization if the EMS requires a manual switchover or failover. This is time intensive and likely to produce errors. The Proxy allows the abstraction such that the objects returned from the interface fail and a new access of the Proxy returns the corrected (newly ACTIVE) EMS objects. CORBA in the BTS 10200 Release 6.0.x unbinds its objects from the NameService and terminates current login sessions in the event of a failover. As a result, the Proxy continues to probe the NameService for changes on both the ACTIVE and STANDBY EMS nodes to sense a failover. Application clients detect this using a PERMISSION_DENIED error from CORBA or related CORBA COMM error. This release of the BTS 10200 does not contain a Notification Service, so there is no asynchronization notification.
•Ability to abstract multiple BTS 10200 instances or "complexes" as well. Each complex must have a unique identifier such as a CLLI code, sensor-id, or the original CORBA site-id to determine which BTS 10200 is being referenced. This ID is used in the Proxy logic as a unique key or locator to find the object and connection information for a particular BTS 10200. This allows a single instance of the Proxy to manage access to multiple BTS 10200s (currently to several hundred). This does not preclude the use of other instances of the Proxy being used in the same network and even other instances of the Proxy talking to the same set of BTS 10200 complexes. There is no requirement in the Proxy for mutual exclusion.
•Fully use of both management interfaces on the EMS for redundancy. If no virtual IP is deployed, the NameService and the CORBA application utilize both management interfaces on each EMS.