Background:
The United States Department of Agriculture’s Food Safety and Inspective Service (FSIS) ensures the safety of food all across the United States by inspecting plants, taking and analyzing laboratory samples, and implementing many other safeguards that regulate the industry. Food Safety regulations and policies often change to keep up with new health needs. The public food safety system is designed to predict risk to help the agency improve predictability, and therefore reduce the spread, of disease.
Challenge:
In order for the agency to be swift and responsive in their reaction to possible safety violations, the FSIS needed a system that reacts to the field in a way to prevent diseases or epidemics as early as possible in order to best protect the health of our citizens.
Solution:
CoreBix, as a subcontractor to CACI, designed and built a system that implements event driven architecture. The event driven architecture allows USDA scientists to build predictive models that are triggered by events in the enterprise. This architecture will allow the analysts to design rules that subscribe to events that will trigger configurable responses. If policies or regulations change, the response will be adjusted as necessary, without requiring any code release from the IT department. An example of this would be a salmonella outbreak. If a particular region of the United States reports more than a certain amount of salmonella reports in a given time period, an alert will automatically be triggered and sent to the proper authorities. This system makes the FSIS approach to dealing with possible food safety issues predictive as opposed to reactive, allowing for faster and more effective responses to potential threats to our country’s well-being.
Microsoft Tools Used:
- Visual Studio 2008
- Enterprise Library 4.1
- Windows Communication Foundation
- .Net 3.5
Design:
EDA Allows Services to get notified based on subscription. All services can fire events; they publish their public events through an API provided by the FSIS Communications Framework. A process or a rule can be created, by discovering all published Events and then subscribing to them. When an event is fired the services that are subscribed to an event are notified and a call back function is executed. In the case of a business rules engine, the rule is executed and an action is taken if the condition is met.
Event Processing
Decoupling Events from Processing, from Response, from Execution.
FSIS Architecture
The main advantage of using Events is for an application to notify without the previous knowledge of the target; therefore deferring the decision to run time to decide which service is interested in the notification.
Only services can fire events. Events that can dynamically subscribe to Events can listen to Events; not all Services need to listen. Business rules engine is a good example of a service that can listen to
.
Software Topology
All Services can Fire Events. Some Services that dynamically can subscribe to an event can also listen to Events. To Listen to Events, a service should inherit from EnterpriseNode in addition of the Service own realization. Enterprise Node implements INotification and provides a common sink for all listening services.
