Your team is charged with building a prototype of Fire Emergency Response System (FERS). FERS is intended to be used by several organizations (agents) to automatically detect, respond, and manage fire
... [More]
emergency situations. Given that the system is going to cross the boundaries of several organizations, the architects would like to design and develop the system according to the principles of Service Oriented Architecture (SOA) and use the web services technology for its implementation. FERS consists of three types of organization: school, hospital, firefighting station. The role of each of these organizations is described in more detail below.
A school is equipped with two types of sensors: smoke detectors and fire sprinklers. There may be many smoke detectors and fire sprinklers throughout a school. Each of these sensors are made available to the rest of the software system via a discoverable web service. A sensor's web service provides operations for getting access to the stream of sensor readings and the generated alarms (if any). A sensor's web service may also provide control operations. For instance, a fire sprinkler provides a control operation that allows a remote client in the system to turn it on/off. A school also provides a school profile service, which provides useful information, such as the name of the school, location, number of student, hours of operation, and so on.
A firefighting station has a fire monitoring service that keeps track of all the sensors in the school. A firefighting station also has several firefighting engines, each of which is made available to the rest of the system via a separate web service. Once smoke is detected by the fire monitoring service, it uses an engine dispatch service to dispatch the closest firefighting engines to the scene. In order to determine the number of required firefighting engines that need to be dispatched, the engine dispatch service may use a heuristic (developed by your team) based on the information (e.g., number of students, size of the school, hours of operation) that is available from the school's profile service and the number of smoke sensors that have detected smoke. A firefighting engine should constantly communicate its status and progress to the station's engine dispatch service.
If only a single smoke detector sensor has detected smoke, the firefighting engine that gets to the scene needs to detect whether the alarm is real or not (i.e., whether there is an actual fire or not). If there is an actual fire, the firefighting engine turns on the closest fire sprinkler. This will be detected by the fire monitoring service, which as you may recall is constantly monitoring the sensors. Therefore, it automatically sends an SOS message to the hospital's medical emergency monitoring service (discussed further below). If there is no fire, the firefighting engine needs to reset the smoke detector.
If at any point in time more than one smoke detector sensors detect smoke in the same school, the fire monitoring service can safely assume that there is a real fire at the scene (i.e., it is not a sensor malfunction). Therefore, it automatically orders the closest fire sprinklers to turn on, and sends an SOS message to the hospital's medical emergency monitoring service.
Once an SOS message is received by the hospital's medical emergency monitoring service, it uses the hospital's ambulance dispatch service to send the closest ambulances to the scene. Similar to a firefighting engine, each ambulance is made available to the rest of the system via a separate web service. The ambulance should also constantly communicate its status and progress to the hospital's ambulance dispatch service. The ambulance dispatch service uses a heuristic (developed by your team) based on the number of smoke detectors that have detected smoke as well as the information made available by the school's profile web service to determine the number of ambulances that should be dispatched.
As soon as a firefighting engine has extinguished the fire associated with a smoke detector, it needs to reset the smoke detectors (the assumption is that smoke detectors never burn). As soon as the fire monitoring service on the firefighting station detects that all the smoke detectors have been reset, it orders the firefighting stations to return to their base and turns off the fire sprinklers. It also send a normalcy message to the hospital's medical emergency monitoring service, which then orders its ambulances to return to their base. Note that "base" for a firefighting engine or an ambulance corresponds to the initial location of the vehicle, and may be different from the location of hospital or firefighting station.
Extra credit
Develop a Business Process Execution Language (BPEL) model that initiates and coordinates the interaction among the web services. Execute and test the BPEL using an open source BPEL engine.
The above project description forms the minimal subset of functionality that the teams should develop. However, the project is rather open-ended. In other words, the teams are encouraged to fill in the gaps and customize FERS by adding new services and interesting capabilities, as long as they do not conflict with the principles of SOA and the minimal subset of functionality discussed above.
Development and Deployment
Your prototype should support at least one school, hospital, firefighting station, and four ambulances, firefighting engines, and six sensors. You should demonstrate your application running over either multiple machines or via multiple independent processes.
Information about the location of UDDI can be encoded in a configuration file, which may have a single copy, or be replicated as needed. Upon being started, each organization needs to register its web services with the UDDI. Other services and clients will use UDDI to find the appropriate web services.
You are required to use the following platforms for the implementation of your project: Programming language - Java Web Service Platform - Apache Axis 2 UDDI -- Apache JUDDI
Other platforms will be considered only if (1) they are open source/license, and (2) your team can justify using another platform. You will need to get the instructor's approval before developing your system on top of a different platform.
Hints and assumptions
- You will need to simulate the existence of sensors in software. You can use a separate Java thread for each sensor.
- You can assume a two dimensional world. Each entity needs to know its (x,y) coordinates and be able to provide others with them. The coordinates will be used to determine the distance between entities.
- You will need to simulate the existence of time. One way is to create a logical clock thread on each agent and have it time-step. You will need to synchronize the clocks at the beginning. For instance, you will need the clock to be able to simulate the following:
- The time it takes for a vehicle to move and get to its destination (you can assume each vehicle moves at a constant rate) - The time required for extinguishing fire (you can assume a constant number)
- You can assume the ambulance crew is able to treat the patients at the emergency scene, and does not need to transport any of the patients back to the hospital.
Evaluation
In order to evaluate and also to demo your project, you will have to develop some kind of a user interface, preferably graphical, that clearly demonstrates the execution of the system as it progresses. The user interface should provide the ability to initiate the start of a scenario by triggering the detection of smoke by one or more sensors. Your system should also provide a mechanism to make the decision on behalf of the firefighting engine's crew, i.e., whether there is an actual fire or not. This would either be interactive (e.g., a graphical interface that asks the user) or static (e.g., read a config file). Keep in mind that while this is not a user-interface class, often having a nice graphical interface could make your demo a lot more interesting.
Your team is responsible for developing experiments that clearly demonstrate the FERN functionality. The design of an experiment should include a description of the deployment. For example, you could say that for an experiment you will deploy so many schools, sensors, ambulances, and so on; identify their respective locations on a 2 dimensional map of the scenario; discuss the smoke detector sensors that will be triggered to report smoke; and what would you expect to be the outcome based on the heuristics that are being employed.
Logistics
Students will work in teams of 4. Students are encouraged to form teams on their own. The students that are not part of a team will be randomly assigned by the instructor.
Personal laptops may be used for development and demonstration, as well as GMU student servers. The prototype must be demonstrated in the regular classroom, either using the GMU network infrastructure, or a private network assembled by the team. Teams are responsible for all the planning and setup required to demonstrate the prototype.
Deliverables
Mid-term project report
A document (max 10 pages) that includes (1) prototype design diagrams -- clearly showing the services that will be developed, including their operations, as well as the interactions among the services in order to achieve the system's objectives, (2) the experiments that will be performed to test the system, and (3) planning of the implementation and evaluation. 2. Each team will provide a short presentation during class. The presentation is a crucial aspect of the report and should mainly focus on the design and ideally a demo of a subset of the functionality already developed.
Final project report
A revised version of the mid-term document (max 10 pages). 2. Each team will provide a detailed demo of the completed system during class. The demo is a crucial aspect of the final report and should clearly demonstrate that the system works by running it on several experiments designed by the team. 3. Code of the developed system. The code should be delivered in a format that can be easily tested by the GTA. The code should be accompanied with a detailed instruction that would allow anyone to compile and execute it. You will be graded on the quality of the developed code. You are strongly encouraged to apply the principles of software engineering, e.g., use descriptive variable names, provide adequate comments, generate JavaDocs, and so on. [Less]
swe
