- A true SOA PSIM deployment should traverse services in its architecture via messaging queues.
- Each service in an SOA should be kept as light as possible, minimizing resource overhead against performance.
A PSIM event pipeline is only as good as the weakest link in the chain, so it is essential to apply the same innovation and attention to detail in the links among its services.
A true SOA PSIM deployment should traverse services in its architecture via messaging queues. These queues ensure that the first message delivered to a service is the first message processed. Most software developers simply select a queuing technology and apply it throughout their solution. Not all messaging technologies are created equal, though.
Some are geared for speed, some for reliability, and some for flexibility. A well-architected SOA solution should utilize the most appropriate technology at each communication boundary, making best use of each to allow the solution to process events smarter, faster and unobstructed. It is essential that each queue is wrapped with intelligence to ensure that every event is processed, analyzed and logged as necessary to provide the best security response in real time. These wrapped, intelligent queues rely on the messaging system that underlines its SOA implementation, thus ensuring every event/ message ends up in the right place at the right time.
Even bad messages are collected, stored and logged, within “poisoned” message queues, allowing for the analysis and reporting of bad messages within a system. In any system that does not provide this functionality, operations would be brought to a standstill as services failed to cope with the corrupted messages. This also brings about an increase in security, as any messages that do not conform precisely to the expected structure and content are isolated and stored, therefore unable to have any performance effect on the overall PSIM solution.
TCO reduction benefits both integrators and end users. The key benefit here is that each service can be deployed on hardware tailored to suit its needs. This significantly reduces the cost of hardware as overspecified, underutilized hardware becomes a thing of the past. Excess capacity can optionally be utilized by instances of other services, to realize the full ROI on hardware and infrastructure.
Each service in an SOA should be kept as light as possible, minimizing resource overhead against performance. A good PSIM vendor should be constantly refining the performance and resource consumption of its event- and alarm-handling services in order to reduce the footprint on expensive, underlying hardware infrastructure.
SOA offers small security operations the ability to minimize infrastructure requirements by deploying multiple services on the same hardware. Depending on customer requirements, this can be deployed on as little as a single server. As the requirements grow, SOA allows the infrastructure to grow proportionally with it, moving out services to their own dedicated hardware, as demand on the system dictates. This separate hardware needs only to satisfy the specification requirements for the specific service being loaded onto it, rather than requiring multiple expensive core servers for each growth cycle, as is so typical with most non-SOA PSIM deployments.
MEDIUM TO ENTERPRISE
In larger deployments where capacity goes beyond individual units, the cost of scaling is significantly reduced with SOA. Where some deployments require additional core servers to extend capacity, SOA only requires additional service nodes where additional provision is required.
Additional nodes are tailored to requirement, investing only in the necessary hardware to provide the capacity needed. In security, planning is always for a major event, not the day-to-day operation of a system, and this is where SOA shines in the large deployment scenario. Multiple services can be deployed within each hardware region and dynamically activated, increasing capacity in functional areas of the software to suit demand as it occurs.
Simply developing software as separate modules and publishing them as services does not necessarily mean that the developer's architecture is truly service-oriented. In a true SOA product, services are independent, capable of operation without dependency. Services are scalable; additional services can be added to a system, providing immediate increase in capacity, processing power and/or redundancy.
Without a SOA, a PSIM system will not provide sufficient capacity at each stage of the PSIM event pipeline, which in turn causes huge spikes in demand for processing capacity. The system will most likely become unstable during times of high stress, ironically just when there is the greatest need for a PSIM solution.