---- Related: ~~ [Monitored247/Ant Targets]  |   [Monitored247/Refactor ToDo]  |   ~~\\ ---- 1 Overview Monitored247 is a new project that is replacing the old SiteTest247. 3 SiteTest247 was launched as a POC launched in 2000. # It's inital concept was to allow dynamic website monitoring. Through a web based interface, users could define ## what needed to be monitored in their site including ### Posts ### SSL ### wizard/workflow interaction. # Users could ask to start/stop monitoring at any time # Users could retrieve that status informatin of their site anytime It has a Hub and Spoke architecture. 1.1 Hub The Server (Hub) was a J2EE application running on JBoss, which: # Allowed Administrators and Clients to ## adminstrate what was monitored ## retrieve status ## other information # Held the status of monitoring sites. # Monitoring Jobs, which was farmed out to Spokes. The Server kept track of all sites/jobs that needed monitoring and then load balances these out to Spokes to actually perform the monitoring. 1.1 Spokes Client Java applications distributed on desktops anywhere around the world. These clients: # Periodically polled the Server/Hub for any monitioring job # Accept a monitoring job # Periodically monitor the remote site defined in the job # Periodically update the Server/Hub with the Job/Sites status. 1 Refactoring Project The inital ~~SiteTest247~~ was quite inovative at the time. There were very few competing web based products that had all of the features of SiteTest247. # During 2000, there were no libraries to allow ## HTTPS access for Gets/Posts (project developed its own for these) ## GET/POST functionality. Developed own libraries. # Use of EJB/MDB for asynchronous updates of Job statuses from Spokes. # RMI for communication b/w Hub/Spokes. # Required full J2EE server to run Hub. # Used heavy weight J2EE best practices/blueprint type architecture. The Monitored247 refactoring is Project's goal is to keep the SiteTest247 concept, but making use of a much lighter weight Architecture. It is envisages to do this with newer lighter technologies such as: # Spring (to try and replace J2EE Container's services and allow deployment just within a WebContainer). # Replace data access with Hibernate # Replace Calls to Stateless Session Beans (RMI) with Web Services. (This way Spokes would not be blocked by corporate firewalls which may only permit Port 80 traffic). # Refactor Struts to SpringMVC (or other view techonology down the track) The other goal is to use this as an Architectural blueprint/template for future project as it addresses the various different artefacts (Web Tier, Business Tier, Data Tier, Client Tier) ---- 2006-05-13 14:39:34.0 2006-05-13 11:34:07.0