Drupal Monitor

The idea behind Drupal Monitor (and yes I will be thinking up a better name), is to build a monitoring and management system, and to build a proof of concept application to showcase some of our new frameworks.  The core of the drupal application will be build on our Voom framework, while the backend java engines will be build in our PawnStorm framework (built on top of JGroups).

Drupal Monitor Features Functionality

Availability Monitoring:  This will roughly be the same functionality provided by most online monitoring services.  Checking for uptime, response time, and include some level of diagnostics and troubleshooting.  it would also include the ability to alert users via email, sms, twitter, etc...  It is also likely that an iPhone and/or Android app would be built to complement the system.

Response Time:  You would be allowed to enter URLs to different pages on your site and we will build a trend of response times to those pages. This will allow you to determine if your site's performance varies through the day, or on certain days.  It would also allow you to see the differences between static content and dynamic content.

W3C Compliance Verification:  Let our system crawl your site and verify that each page is W3C complaint.  This can help search engines, robots, and old web browser be able to get the most out of your site.

Site Wide Spell Checker:  Nothing spells unprofessionall like a misspelled site.  Let us help you track down those spelling errors before you clients, customer, or visitors do.

Broken Link Finder:  Just as bad, or worse, then having spelling errors are broken links.  We can help you sniff them out and clean them up.

SEO Optimization:  We provide some tools to help with some of the basics of search engine optimization.  Plus we can help you see how you rate in all the major search engines by telling you your rank based on varies keywords or phrases.

Performance / Site Wide Stress Testing:  Getting ready to send out a major ad campaign, or just interested in the upper limits of your site.  We have tools to help you determine how your site will handle load.  

Drupal Specific Monitoring:  As a bonus we would like to provide monitoring features that are specific to Drupal.  Some of the things we could watch for are modules that have gone out of date, security fixes that should be considered, etc..

 

Why use Java?  

In short I would like to use the right tool for the right job.  Drupal is powerful CMS that has a well thought out templating engine. It includes CCK, a very effective tool for querying, filtering, and displaying data.  Plus Drupal has an out-of-the-box usable security system and menu system.  As a plus there are thousands of already created modules that you can leverage.

On the other hand Java has the ability to build highly concurrent services that are well suited to backend work.  Do you want to ping a thousand servers at one every 2 minutes?  This would be a small exercise in Java, in contrast, I can't imagine how such a thing would be done in Drupal without writing a custom C++ module (and let's not even go there...)  Java is also a great utility language.  There are libraries for almost anything you can think of.  

For the purpose of a monitoring system, building engines to handle ping tests, http response times, crawling and spell check or broken link checking would be relatively easy in java.  Also building a services that was able to to go out to a hosted provider via SSH and do an audit on the installation would be a very manageable task in java.  There is also the fact that it only makes sense to cluster the engines and scheduler, so that they can continue running if one data center goes down, and so that you can get metrics from different geographical data center.  Clustering, partitioning, and distributed computing seems a better fit in the java world.

Why REST (RPC) between Java and PHP?

There are two benefits to this.  First is the ability to separate out Drupal from Java.  There is no reason you have to run them in the same space, so an RPC between them would mean that run could run in an xAMP stack while the other ran in a Java application server.  The other benefit is that they could be on different machines.  The second reason is that it gives you an ability to stop the spread of GPL into your java code.  It may be that you don't want to, or can not, open source all of your code.  If you wanted to use Drupal in this case then having a RPC over the network (localhost even) allows both to be distributed without violation of GPL.