Integrating Spatial Architecture with the Enterprise
AMS Production Architecture
The core AMS is based on Smallworld Core Spatial (GIS) technology. In planning
for the implementation of this software within Florida Power and Light, a careful
review of existing FP&L expertise and Smallworld technologies was completed. The
project team wanted to find solutions that would allow AMS to take maximum
advantage of existing infrastructure and support groups within the enterprise. This
led to a decision to implement the Smallworld Repository on Oracle as the storage
container for the main GIS datastores. This technology allowed AMS to use the
skills of an existing team or Oracle DBAs inside FP&L to support the application.
This group brought experience in deploying and maintaining Oracle systems within
FP&L including monitoring, backups, and disaster recovery.
The core system includes access to the full GIS for 100 users during phase 1, as well
as access for 400 FP&L staff members using the Smallworld Internet Application
Server (SIAS)—a view-only web application. AMS requirements also dictate that the
system provide a read-only reporting replica in Oracle, downstream interfaces to
legacy FP&L systems, and interfaces to several other Tech21 projects using
integration bus technology from STC. Finally, the AMS must be able to recover to a
full level of service within two hours of a catastrophic site failure.
Figure 2 - Overall AMS Production Architecture Diagram
Database Servers
The architecture diagram above depicts the hardware systems selected to support
database requirements. At the center of this architecture is the primary datastore
server. This system is configured with the AIX operating system and the Oracle
server. This Oracle environment will host both Smallworld GIS datastores using the
Smallworld Repository on Oracle and the AMS reporting replica, which is a
conventional set of Oracle tables. This Oracle server will use standard Oracle
technologies to backup the Smallworld data on a daily basis. It also implements
Oracle Standby server technology to replicate data to the server at the disaster
recovery in real-time. This allows for immediate recovery of the system at the
standby site with almost no loss of data. In electing to use the Oracle server instead
of GE Smallworld's base data storage approach-the Smallworld Master File Server
(SWMFS)-the following factors were evaluated:
- Management tools - Oracle provides a strong suite of tools for backup,replication, and general data administration.
- Existing skill-sets - FP&L has a large staff with extensive skills in Oracle. By selecting this approach, the AMS project could leverage this staff base.
- Complexity - The oracle repository provides an increased level of complexity, as it requires that staff be familiar with both Oracle database management and with management for Smallworld databases
- Corporate Standards - FP&L corporate standards require that enterprisecritical data be stored in Oracle whenever possible. This solution allowed AMS to meet this requirement.
- Performance - Benchmarks indicate that performance is similar for all Smallworld storage approaches. Oracle provides excellent memory management and data caching technologies that accelerate performance. SWMFS provides technologies to implement compression of network traffic, which is not available with Oracle. Initial tests indicate that performance in the FP&L environment is faster using native SMFS storage instead of Oracle, but the use of persistent cache servers in AMS will eliminate most of this impact.
- Fault Tolerance - Through the use of the Oracle solution, the AMS system is able to integrate with FP&Ls existing HACMP clusters within the AIX environment. The project was able to leverage existing knowledge of implementing and maintaining this solution with Oracle servers. However, the Smallworld repository does not currently support automatic recover of the database connection due to network or server interruptions. Support for this functionality is coming in a future GE Smallworld release, so it was deemed a worthwhile risk for the short term.
Interface Severs
One of the critical requirements of the AMS system is the ability to interface with
other applications throughout FP&L. These interfaces include feeds to legacy
systems which are replaced or supplemented by AMS as well as feeds to other
systems which are being introduced as part of the Tech21 initiative. The architecture
for AMS was designed to support the process of moving data to and from these
systems throughout the enterprise. Server and architecture requirements are driven
by AMS requirements to provide data in varying formats and varying levels of
granularity throughout the enterprise. Some systems, such as the Distribution
Management System (DMS), require a full network model from AMS, while others,
such as the data warehouse/decision support system, only need tabular data from
AMS. When reviewing the architecture for each interface, efforts were made to
combine the transport and delivery protocols for each system, which helps to
eliminate both development efforts and hardware investment. The interfaces section
below provides further details on this integration approach.
The network builds required for DMS are generated using the GE Smallworld
NetXchange application. This software is able to analyze complex networks and
output the results in a custom format. In this case, the data is output in an XML
rendering of the Common Information Model (CIM). The process of analyzing the
network can be quite memory intensive and the requirements from DMS dictate that
AMS be able to generate large volumes of network data on a nightly basis. To
support these needs, a group of three systems are assigned to DMS interface
processing. These Windows NT servers are configured to run as high-end clients,
with 1 GB of RAM and a high-end disk subsystem to support this rapid processing.
An equivalent set of systems is deployed at the disaster recovery site to ensure that
interface processing can resume without interruption in the event of a site failure.
General Application and Job Servers
In order to promote user productivity and reduce network traffic, AMS was designed
with a batch approach to data merge, post, validation, and cleanup operations. This
approach allows a user to submit a specific work order for processing and then move
on to the next job without waiting for it to complete. In the case of AMS, this
approach is call "Real-time batch processing". This means that the system attempts
to complete each user request as quickly as possible after it is submitted, and uses the
instant messenger capability within the system to notify the user as soon as an
operation is complete.
The Job server is responsible for completing real-time batch processing for all AMS
users. This server is configured as a high-end client machine, with 512MB of RAM,
an 800MHz CPU, and a RAID 5 based disk subsystem to store local cache files. This
specification provides adequate performance to process work orders as they are
submitted by users and should provide a 5-10 minute turn-around under normal load.
Because work order and validation requests fall off in the evening, the job servers
also provide general application services for AMS. The primary application function
after hours is running the GE Smallworld InSync application that allows a single
view of the GIS database to be replicated to Oracle. The server must review all
changed data in the GIS and publish these changes to Oracle. It also reviews changes
in the Oracle database and returns them to the GIS as part of this process. The
resultant Oracle database, which is hosted on the production database server, is used
for many interfaces and for access to AMS data from generic reporting tools in the
enterprise.
