EnterpriseSMS® Must Be Self-Maintaining Software With Extensive Support CapabilitiesESMS monitors itself continuously and reports problems it encounters. It must automatically recover from any program failure without losing any transactions. This was an early software development standard. This goal is largely achieved as a result of many software standards applied to ESMS. Messages will never be lost because of the way they are processed and because proprietary message handling practices were standardized and used throughout ESMS. Most programs publish their operating status to facilitate administrator and user understanding of the status of their applications. Software applications are always automatically restarted when they fail and the problem is logged for administrators. These examples illustrate the software engineering that is a the foundation of EnterpriseSMS®. Large scale systems must have extensive remote diagnostic capabilities. When systems get large and broadly distributed, it is very expensive and frequently impossible to have distributed technical staff at all convenient locations. An extensive mechanism for remote viewing of the operation of each component is a mandatory part of EnterpriseSMS®. We call this single seat support so that a single technical support person can provide the highest level of support remotely. EnterpriseSMS® software standards specify a set of elements that make advanced remote diagnostics standard. In cases where 3rd party products support detailed diagnostics, these capabilities are usually integrated into the ESMS edge component or application that interfaces with the product. These software standards include means to monitor an application’s behavior in a non-disruptive fashion while they are running anywhere, the means to interact with such applications anywhere if such capabilities make sense for the application, and means to utilize applications as a part of a diagnostic effort such as creating test transactions. In the figure below, from left to right, a transaction moves from one application module, may be split into several transactions, may cross the network, and may be subsequently processed by multiple application modules located anywhere within the communications infrastructure. The technical support specialists may access this transaction at as many locations as needed to analyze the cause of a problem. Knowledgeable use of these tools permits the end-to-end validation of transaction threads in real time without degradation of the system’s performance. This type of capability required a significant effort to meet all of the vision’s requirements. |
||