CSSE4004 1 Semester 1, 2021 Assignment 1 v1.0 Total Weighting: 30% This document is quite long as there are ~6 components of the distributed system to describe. Project plan: Weighting: 5% Due 22 March 2021 16:00 AEST Project Implementation Weighting: 25% Due: 16 Apr 2021 16:00 AEST Code Demonstration This will take place during the practical (and possibly lecture) classes in weeks 8-10. During week 7 you will be assigned a time to do your code demonstration with teaching staff. You must turn up to the allocated session to demonstrate your working implementation. Failure to turn up may result in a mark of 0 for the project implementation stage. During this session the teaching staff will ask you to demonstrate each of the working deliverables and system features (see marking criteria). During this session you may be asked about the design decisions you have made and how your solution works. Please be aware that it is expected that you will be prepared, and will be able to discuss the design and features of your solution. Marks may be impacted if unsatisfactory explanations are given. Students have the options of demonstrating their applications on their own laptops or the lab machines. To maintain academic integrity, the applications used for demonstration must be the same as the one that students have submitted. Checks will be in place to ensure this. Technical Requirements: Eclipse IDE Java 11 Ice-3.7.5, Icestorm-3.7.5 Provided Staring Eclipse Project An eclipse project has been provided on Blackboard so that you can start the assignment. You can download this and import it into Eclipse to get started. This includes starting java files (empty, to be added), jar files, data files (txt files), ZeroC Ice config files (you may need to amend these), an empty ZeroC Ice SLICE file etc. (see the project structure shown in the submission section - this is the same as the provided eclipse project). CSSE4004 2 Table of Contents 1. Introduction 4 System Components 4 ZeroC Ice Distributed Computing Platform 4 2. Deliverables 5 3. Sensors 6 Communication 6 Starting the sensors 6 Reading data from file 6 Format of data files 6 Concurrent Users 7 Shutting down the sensors 7 4. Weather Alarm 8 Communication 8 Starting the weather alarm 8 Reading data from file 8 Format of data files 8 Shutting down the weather alarm 8 5. Location Server (LS) 9 Communication 9 Starting the location server 9 Reading data from file 9 Format of data files 9 Shutting down the location server 9 6. Preference Repository (PM) 10 Starting the Preference Repository 10 Reading data from file 10 Format of data files 10 Preference Evaluation 10 Shutting down the Preference Repository 11 7. Context Manager (CM) 12 Context Manager Overview 12 Starting the Context Manager 12 CSSE4004 3 Evaluating humidity exposure 12 Evaluating Noise Overexposure 12 Evaluating weather alarm 14 Reading data from file/ Storing information about the city 14 Format of data files 14 Making suggestions to users 14 Responding to queries from User Interface 15 Shutting down the Context Manager 15 8. The User Interface (UI) 16 Starting the UI 16 At Startup 16 Main Menu 16 Input validation 17 Option 1: Search for a specific item of interest 17 Option 2: Search for items of interest in current location 17 Option E: Exit 18 Receiving warnings and suggestions 18 General Information 18 9. Logging communication between programs on the consoles 19 Why 19 Requirements 19 10. Design Document 20 11. Marking Criteria 21 Project design details: 21 Code implementation details: 21 12. Submission details 26 Project design document 26 Code Implementation 26 14. Updates to the specification 27 15. Plagiarism 27 CSSE4004 4 1. Introduction In this assignment, you will implement a simple distributed system with several components. The distributed system is a software application called ComfortSense. Although we are programming and running this on a computer, we will imagine for this scenario that ComfortSense is running on a mobile phone. ComfortSense makes use of sensed environment data and weather information, to evaluate potential risk to a user from the current environmental conditions. There are three types of environmental risk; humidity, noise, and weather. Each user has their own profile, where they can set their own limit for humidity (e.g. george has a humidity limit of 80 percent), and record current hearing loss status. When a risk threshold has been met, ComfortSense will make suggestions to the user for activities/places where they can go to escape the risk. Each user is able to record their preferred type of activities/places to go when each risk threshold has been met, within their profile (e.g. when it is too humid george wants to go to a Cinema location). This information is used by ComfortSense to tailor the suggestions to each user based on their preferences. This sensed environmental information is also referred to as “context information”. Applications that adjust to changes in context information are considered to be context-aware and fall under the research field of pervasive computing. The ComfortSense application will make use of the both Remote Method Invocation (RMI) and Publish/Subscribe architecture for communication between its components. System Components The ComfortSense application has the following components: ● Sensors o Humidity level sensor o Noise level sensor o Location sensor ● Weather alarm ● Location Server ● Preference Repository ● Context Manager ● User Interface For this assignment, we are not interfacing with actual physical sensors. Instead, your sensor components will simulate sensor behaviour by reading values from data files, and exporting that sensor data in the appropriate manner for consumption by other system components. ZeroC Ice Distributed Computing Platform You will be introduced to Ice in the lab class tasks. Ice provides two communication paradigms: RMI and notifications (publish/subscribe). You should use both in the assignment and for this you need to evaluate which communication should be of the type RMI and which one is more suitable for publish/subscribe. Publish/subscribe is provided in Ice by IceStorm (www.zeroc.com/icestorm/index.html). IceStorm acts as a mediator between message publishers and message subscribers. CSSE4004 5 2. Deliverables There are two deliverables; a (i) project design document, and (ii) the complete implemented code solution. Students are required to: ● Figure out which communication paradigm (RMI or Publish/Subscribe) to use when communicating between components. o It is also necessary to decide the format (e.g. String, int, char) and parameters of messages which are sent between components. ● Figure out the order in which the components should start, and when. ● Figure out the order in which the components should exit, and when. ● Implement each of the components according to the specification. CSSE4004 6 3. Sensors AllSensors.java The three sensors used by the ComfortSense application are: ● A humidity sensor o produces integer readings in the range 0 to 100 ● A noise sensor o shows the current level of noise in decibels in the range 0 to 130. ● A location sensor o monitors the user’s location. Communication All sensors produce readings every second. You will need to determine what information should be sent by the sensors, and the format this should take. i.e. what variables or strings of information will you send, and what will the format be. You will need to consider that: ● There are multiple users ● Each user has several types of sensor ● Each sensor has a sensor reading Starting the sensors The humidity sensor, the noise sensor and the location sensor are all started in Eclipse together at the same time in one java file, AllSensors.java. AllSensors.java takes one input argument (which must be set in the Run Configuration): [username] where [username] is the name of a user logged into a user Interface, and every user has his/her own sensors. E.g. “george” (no quotes). Reading data from file AllSensors reads in three different predefined files at start-up. The three files contain readings of the three sensors for each person. The name of each predefined file must be named: Humidity.txt e.g. georgeHumidity.txt Noise.txt e.g. georgeNoise.txt Location.txt e.g. georgeLocation.txt Note: Hardcoding these file names in your code will result in a marks deduction. The data files which are loaded should change if the input argument changes. Format of data files Each line of the three predefined files must be in the format: value, number of seconds ‘value’ is the value that should be in the update notification. CSSE4004 7 ‘number of seconds’ is the number of seconds that value should be used. The sensors produce the “value” every second for “number of seconds”. An example content for the predefined file of the humidity sensor for alice (i.e., aliceHumidity.txt) is as follows: 29,5 30,3 34,7 31,3 This can be interpreted that the humidity sensor will report a humidity of 29% for the first 5 readings (seconds), then 30% for the next 3 seconds, then 34% for the next 7 seconds, then 31% for 3 seconds. Once the end of the file is reached, the sensor will return to the beginning i.e. after sending 31 for 3 seconds, the humidity sensor will send 29 for 5 seconds and so on until the application exits. Concurrent Users The application needs to be able to handle more than one user concurrently. Therefore, you will need to start one instance of the AllSensors program for each user which is present in your program (the example users here are alice and george). You will do this using different Run Configurations, one for each of the users (e.g. AllSensorsalice and AllSensorsgeorge). Shutting down the sensors The sensors shut down (and stop sending information) when the user exits the User Interface. The sensors should not stop sending information for any other reason. CSSE4004 8 4. Weather Alarm WeatherAlarm.java A weather alarm that returns monitoring of extreme weather. Communication The context manager must receive a message from the weather alarm once every 30 seconds (i.e. all weather events always last 30 seconds). You will need to determine what information should be sent by the weather alarm, and the format this should take. i.e. what variables or strings of information will you send, and what will the format be. You will need to consider that: ● There is only one weather alarm ● The weather alarm could be in one of several defined states Do not send the weather alarm every second, while changing the value every 30 seconds. This approach is incorrect. Starting the weather alarm WeatherAlarm.java takes one input argument (which must be set in the Run Configuration): weatherAlarm.txt Hardcoding this file name in your code will result in a marks deduction. The data file which is loaded should be able to be changed if the input argument changes. Reading data from file The alarm events must be stored in a predefined file called weather_alarm.txt. Format of data files The data file must contain one of the following per line: ● NORMAL ● HEAVYRAIN ● HAILSTORM ● STRONGWIND For example: NORMAL NORMAL HEAVYRAIN NORMAL STRONGWIND This can be interpreted that the weather alarm sensor will report normal weather for the first 30 seconds, then hail storm for the next 30 seconds, then heavy rain for the next 30 seconds. Once the end of the file is reached, the sensor will return to the beginning of the file. Shutting down the weather alarm The weather alarm shuts down (and stops sending information) when the last user exits the User Interface. The weather alarm should not stop sending information for any other reason. CSSE4004 9 5. Location Server (LS) LocationServer.java Communication The Location Server: 1. receives location from the location sensor 2. determines the current indoor/outdoor status of the user 3. sends this context information to the Context Manager ● You need to decide the format of this message. The location server also is responsible for returning a list of all indoor locations to the Context Manager upon request from the Context Manager. ● You need to decide the format of this message. Starting the location server The Location Server is started in Eclipse, and must take the following argument: locationMapping.txt where location_file.txt is the file containing the mapping of the indoor/outdoor status to location coordinates. Hardcoding this file name in your code will result in a marks deduction. The data file which is loaded should be able to be changed if the input argument changes. Reading data from file The location status information must be stored in a predefined file called location_file.txt. Format of data files The mapping of the location coordinates to status is specified using the following structure: Indoor : LocationA, LocationB, Outdoor : LocationC, LocationD, Shutting down the location server The location server shuts down (and stops sending information) when the last user exits the User Interface. The location server should not stop sending information for any other reason. CSSE4004 10 6. Preference Repository (PM) The Preference Repository: ● stores user preferences ● evaluates these preferences when requested by the Context Manager Starting the Preference Repository The Preference Repository is started from Eclipse, accepting the following argument: userPreferenceInformation.txt where: preference_file.txt is the name of the file containing the user preferences. Reading data from file Preferences must be loaded from a preference file (given by the input argument) when the Preference Repository starts up. The preference file contains multiple users. Format of data files For each user in the file, there is: ● exactly one humidity preference ● exactly one Noise Overexposure preference ● exactly one weather alarm preference The preference file is formatted as follows: ● Each entry has the name of the preference owner ● Each field in the entry is terminated with a new line character ● Each entry is separated from other entries by an empty line A weather alarm preference is in the following format: ● when WEATHER suggest [service] An Noise preference is in the following format: ● when NOISE suggest [service] A humidity preference is in the following format: ● when HUMIDITY suggest [service] [service] is the name of a service (e.g., shops) provided by item of interests An example entry in the preference file is: name: alice Hearing Condition Type: 2 pref-1: when HUMIDITY suggest pool pref-2: when NOISE suggest cinema pref-3: when WEATHER suggest cinema Preference Evaluation Preference evaluation is initiated by a request from the Context Manager when either: CSSE4004 11 ● The humidity threshold is reached ● The Noise Overexposure threshold is reached ● A weather alarm is triggered You will need to determine what information should be sent by the Context Manager, and the format this should take. i.e. what variables or strings of information will you send, and what will the format be. You will need to consider: ● Who the user is (e.g. george) ● What threshold has been reached (e.g. humidity) The Preference Repository checks the preferences for the specified user to see if the there is a preference for the humidity threshold, Noise Overexposure threshold, or weather alarm, respectively. The preference information must then be returned to the Context Manager as a result of the request. The Context Manager will then be responsible for suggesting locations that are appropriate. Shutting down the Preference Repository The Preference Repository shuts down when it receives a notification from the Context Manager instructing it to do so. The Preference Repository deregisters its subscription with Ice Storm before exiting. CSSE4004 12 7. Context Manager (CM) Context Manager Overview The Context Manager is arguably the central component of the distributed system, which interacts with many other components in the system. The Context manger: ● gathers information about, humidity level, noise pollution level, user location, and weather from sensors. ● gathers personal information of a user from the Preference Manager. ● calculates a threshold for Noise Overexposure overexposure, and sends a warning together with suggestions of items of interest when the Noise threshold of the user is reached. o The suggestions for Noise are based on user preferences and they must be located indoors. ● evaluates humidity and sends a warning together with suggestions of items of interest when the humidity threshold for a user is reached. o The suggestions are based on user preferences, and the locations may be indoors or outdoors. ● evaluates the weather alarm status, and sends a warning together with suggestions of items of interest o The suggestions for weather alarm are based on user preferences and they must be located indoors. ● responds to queries from the User Interface. Starting the Context Manager The Context Manager is started from Eclipse, accepting the following argument: locationInformation.txt where: locationInformation.txt is the name of the text file containing information about locations in the city. Evaluating humidity exposure The humidity threshold for a particular user is stored in the Preference Repository. The context manager queries the Preference Repository for the humidity threshold when the user first login to the User Interface. When the threshold is reached (i.e., the current humidity is equal to the threshold predefined in the user preference), the Context Manager will send a Humidity Warning to the user and make suggestions for items of interest based on the user’s preferences in any location. NOTE: ● When a humidity threshold is reached, the humidity is not evaluated again until there is a change of humidity. Evaluating Noise Overexposure The noise overexposure gives an indication of the level of noise pollution and the potential danger of exposure to loud noise. The Context Manager uses Noise Pollution Level, personal hearing condition type and duration of Noise Pollution Level exposure to calculate a Noise Overexposure threshold. The following Noise Pollution Level exposure recommendations is used by the Context Manager in the evaluation of a user’s Noise Overexposure threshold. Noise Pollution Level (dB) Description Base time 0 to 70 No direct threat to hearing. 30 seconds 71 to 90 Mild risk of hearing loss. 15 seconds CSSE4004 13 91 to 110 High risk of hearing loss. 10 seconds over 110 Very risk of hearing loss. 5 seconds Table 1. Noise pollution level exposure recommendations Hearing condition types are categorised as follows: Hearing Condition Type 1: Existing hearing issues Definition: People with hearing loss or tinnitus Multiplier: 1 Hearing Condition Type 2: Children and old adults Definition: People who are more predisposed to develop hearing issues, including older adults. Multiplier: 2 Hearing Condition Type 3: Healthy adults Definition: Adults age between 18-45 without medical history relevant to hearing issues Multiplier: 3 The hearing condition type of particular users is stored in the Preference Repository. The Context Manager queries the Preference Repository for the hearing condition type when the user first logs into the User Interface. The Noise Overexposure Threshold of a user is calculated by multiplying a Base Time of the current noise pollution level (according to Table 1) and the user personal reference to noise pollution level (i.e., Noise Threshold = Base Time * Hearing Condition Type). ● A user is considered to be overexposed when the Noise Overexposure Threshold is said to be reached. That is, when the amount of time a user has been located outdoor is greater or equal to the current Noise Overexposure threshold of the user (i.e. Noise Threshold reached = outdoor time ≥ Noise threshold). ● For example, for user with Hearing Condition Type 2 exposed under a Noise Pollution Level of 95, the Noise Overexposure Threshold is 30 (2*15 seconds). The threshold will be reached when the user spent 30 seconds or more in outdoor locations. ● When a user is overexposed (or the Noise Overexposure threshold is reached) the Context Manager will send a Noise Overexposure Warning to the user interface for the particular user, and make suggestions for items of interest base on his/her preferences, providing the items of interest are located indoor. The Context Manager is required to query the Location Server regarding a list of indoor location, so as to make appropriate suggestions to users. NOTE: ● The timer (for counting the outdoor duration of a user) starts counting from zero when: o the user moves from an indoor to an outdoor location, or o there is a change to current Noise Pollution Level (the Noise Overexposure threshold of the user is also re-evaluated). ● The timer continues to count when the user moves from an outdoor to an outdoor location, providing the AQ Index stays constant and the Noise threshold for the user has not been reached. ● The timer stops counting when: 1) the user is located indoor, or 2) the Noise threshold is reached CSSE4004 14 Evaluating weather alarm The weather alarm takes the highest priority in suggesting users to stay outdoor or to move indoor. The alarm events must be stored in a predefined weather_alarm.txt file. The context manager queries the next weather alarm every 30 seconds. When a weather alarm is triggered (i.e., warning of incoming heavy rain or strong wind), the Context Manager will send a Weather Warning event to the user and make suggestions for items of interest base on user’s preferences in any location. In addition, because the weather alarm has the highest priority in suggesting users to stay outdoor/indoor, the Context Manager will only give suggestions which are located indoor until the weather condition has changed to ‘normal’ (i.e. no alarm). This means that when there is active weather condition, the locations returned for humidity threshold warnings must be indoors (suggestions are already always indoor locations for Noise threshold warnings). Reading data from file/ Storing information about the city The Context Manager maintains a knowledge base which it populates using a city information file read at start-up. Format of data files This file contains a number of entries corresponding to items of interest within the city. Each entry has: ● a unique name for an item of interest, indicated with name ● a location coordinate exists in the accepted by the Location Server (such as LocationA, LocationB, LocationC, LocationD). ● a short paragraph of information about the item of interest ● a list of services offered at the item of interest An example of an item of interest entry in the file is: name: Indooroopilly Shopping Centre location: LocationA information: Indooroopilly Shopping Centre is a major regional shopping centre in the western suburb of Indooroopilly, Brisbane, Queensland, Australia. It is the largest shopping centre in the western suburbs of Brisbane, by gross area, and contains the only Myer store in that region. services: cinema, restaurants, pool, shops Making suggestions to users The Context Manager makes suggestions of items of interest when either: ● a weather alarm is triggered ● the Humidity threshold of the user is reached. ● the Noise Overexposure threshold of the user is reached. In order to take into account the user preferences, the Context Manager must indicate to the Preference Manager which threshold has been reached. You will need to determine what information should be sent by the Context Manager to the Preference Manager, and the format this should take. i.e. what variables or strings of information will you send, and what will the format be. You will need to consider: ● Who is the user CSSE4004 15 ● What is the threshold that has been reached. The Preference Repository returns a list of services the Context Manager should suggest to the user. ● The weather alarm has the highest priority. ● If both the Noise Overexposure threshold and humidity threshold are reached at the same time, the Noise Overexposure threshold takes higher precedence. In this case the Context Manager must only request a list of services corresponding to the Noise Overexposure preference. Upon the return of the list of services from the Preference Repository, the Context Manager sends a list of items of interest that provide those services to the User Interface of the ComfortSense Application, but: ● ensures these items of interest are located indoor if the user’s Noise Overexposure threshold is reached. ● ensures these items of interest are located indoor if the user’s humidity threshold is reached and there is a current weather alarm. To determine whether a list of items of interest is located indoor, the Context Manager queries the Location Server regarding the indoor/outdoor mapping of the location of the list of items. This query should be made to the Location Server for every suggestion. Responding to queries from User Interface The Context Manager is required to respond to queries issued by the User Interface. Two queries are supported: ● Search for items of interest in the current location ● Search for information about a specific item of interest Search for item of interest in the current location ● The Context Manager responds with an item of interest in the user’s current location. Search for information about a specific item of interest ● The Context Manager searches for the specified item of interest in its knowledge base and returns the information associated with that item of interest. More detailed information regarding how the queries are generated is specified in the User Interface section. Shutting down the Context Manager The Context Manager shuts down automatically when all User Interfaces have exited. The shutdown process of the Context Manager involves deregistering its subscriptions with Ice Storm and exits. The exit will also trigger shutdown of other components. CSSE4004 16 8. The User Interface (UI) The ComfortSense Application provides an interface through which users can: ● issue queries for information about the city ● receive warnings ● receive suggestions based on predefined preferences when a user’s thresholds are reached Users interact with the ComfortSense Application using a text-based menu: ● User menu choices must be read off standard in (i.e. the keyboard). ● All spec-related ComfortSense Application output is printed to standard out (System.out). ● All non-spec ComfortSense Application output must be printed to standard error (System.in). Starting the UI The ComfortSense UI is started in Eclipse, taking no arguments. The UI does not load data from any data files. Note: Remember that the humidity sensor, the noise sensor and the location sensor are all started in AllSensors.java, not the UI. At Startup The ComfortSense UI asks for the user’s name at startup: Context-aware ComfortSense Application Please enter your user name: If a valid name is entered, show the user’s name, and their threshold preferences for humidity, and noise level. Hello, Your environmental threshold values are: Humidity: Noise: If an invalid name is entered, an error message must appear, and the program must terminate: Error: The provided name was not found in the stored user profiles. Please check the name, restart the user interface, and enter the name again. NOTE: You will set up and start running the AllSensors program for each user, then utilise the ComfortSense UI menu to indicate which user you wish to obtain information about. The AllSensors programs are not started based upon the username entered in the ComfortSense UImenu. This means that although multiple versions of the AllSensors program are running at any given time (one for each user), you will only be able to use the menu to see information for one user. To be able to see information from the other user, you will need to start another instance of ComfortSense UI. ● You should be able to concurrently start multiple separate instances of the ComfortSense UI program, then enter different usernames into the multiple console windows in Eclipse. This will allow you to engage with each of the AllSensors programs that are running, one in each console window. Main Menu A main menu will appear as: CSSE4004 17 --Please select an option--: 1. Search for information on a specific item of interest 2. Search for items of interest in current location E. Exit Each time the main menu is shown, the user must be able to input a menu option. The user has the option of selecting 1, 2 or E. Input validation If the user inputs an invalid menu option, then the user must be informed with an appropriate error message. The user must then be prompted to re-enter their choice. Option 1: Search for a specific item of interest The user is presented with a prompt requesting the name of an item of interest. Please enter name of item of interest: The user enters the name of an item of interest. A request is then made to the Context Manager querying for information on the item of interest. The information returned by the Context Manager is then displayed on the User Interface screen in the format: Information about E.g. If a user searched for ‘South Bank Parklands’ the following would be printed: Information about South Bank Parklands: The South Bank Parklands area was created as part of the rejuvenation of the industrial water front undertaken for World Expo 1988. The Parklands area contains many shops, a cinema complex, and a large number of restaurants as well as a man-made beach. A river promenade stretches the length of South Bank Parklands. If the item of interest is not recognised (not in the city information file) the ComfortSense Application prints the following: No match found for item of interest. Irrespective of whether the query succeeds or fails, pressing the Enter key should return the user to the Main Menu. Option 2: Search for items of interest in current location A request is made to the Context Manager querying for the names of items of interest in the user’s current location. For example, the current location of the user is A. Location A has two items of interest (South Bank Parklands and The IMAX cinema). The Context Manager will respond with a list of names of items of interest in the user’s current location (printed one per line) as below: The following items of interest are in your location: South Bank Parklands The IMAX cinema CSSE4004 18 If there are no items of interest in the user’s current location, the following message is printed to the screen: There are no items of interest in your current location. Irrespective of whether the query succeeds or fails, pressing the Enter key returns to the Main Menu. Option E: Exit A message is sent to the Context Manager informing it that the ComfortSense Application is exiting. ● The other system components must only stop if the last ComfortSense UIinstance is exited. If one ComfortSense UIinstance is still running, the other system components must keep running. The ComfortSense Application then deregisters with IceStorm and exits. Receiving warnings and suggestions If a weather alarm is triggered, the user’s noise threshold is reached, or the user’s humidity threshold is reached, the ComfortSense UI will issue a warning of the following format: -------------- -------------- Warning, detected, the current is (user limit is ). Current location: Suggestion - please go to an indoor cinema> at one of these locations: , interest name 2>. e.g. -------------- ------------- Warning, HUMIDITY is now 80% (user limit is 75%). Current location: Brisbane City Current weather alarm status: NO ALARM Suggestion - please go to an INDOOR CINEMA at one of these locations: Garden City, South Brisbane General Information Suggestions are printed out as soon as they are received. It may happen that a suggestion is printed to the screen while a user is typing information for one of the other menu options. This is acceptable behaviour for the ComfortSense UI(it is a limitation). CSSE4004 19 9. Logging communication between programs on the consoles Why The purpose of this is to show the communication that is occurring in real-time between the various components in the overall system. This will also assist teaching staff with marking. Providing this log on each console may also help with debugging. Requirements Each of the following programs must print a log message to the console when data is sent or received from another program (e.g. via RMI or Publish-Subscribe). ● AllSensors ● ContextManager ● LocationServer ● PreferenceRepository ● WeatherAlarm Note: You do not need to do this for ComfortSense UI. This is already managed through the UI features. The format of RMI messages must be:
