Server Code Overview
From Mugshot Developer Wiki
Overview of the code implementing the Mugshot server. See also Server Development Setup.
Contents |
Processes Involved
The Mugshot server is made up of 4 processes:
- Database (MySQL right now)
- JBoss (which acts as web and application server)
- A modified Jive Wildfire implementing our custom protocol
- An AIM bot called imbot that does login via AIM (and simpleminded conversations)
Deployment
In production, we normally run things with Apache HTTP Server in front of JBoss, using mod_jk. We also have a custom-patched mod_cache that bypasses the cache for any request containing our login cookie.
For test/debug deployments there's no need to bother with putting Apache in front.
For both production and local test/debug deployments, we use the Super scripts. See Server Development Setup for more details.
How the Processes Relate
The heavy lifting is in EJB3 stateless session beans inside the application server. Start from package com.dumbhippo.server for the interfaces, com.dumbhippo.server.impl for the implementations.
Also inside the JBoss process are the web tier (com.dumbhippo.web) and the EBJ3 entity beans (database-mapped objects) in com.dumbhippo.persistence.
The application server connects to the Jive Wildfire XMPP server in three different ways (this is a bit of a mess to clean up). First, it connects as a special client that logs in as an "admin user" - we broadcast certain notifications this way. Second, the XMPP server can invoke methods on the MessengerGlue interface using Java RMI (remote method invocation). Third, there are some JMS messages involved as well.
The AIM bot talks to the application server exclusively through JMS, so it's a little bit cleaner.
Neither the XMPP server nor the AIM bot keep persistent state on disk, persistent state always goes to the database by way of the stateless session beans.
The application server talks to the database (MySQL) in the usual way, JBoss manages a pool of connections to the database server and the whole thing is abstracted by a Java database driver and EJB3 persistence.
Stateless Session Beans
The core of the Mugshot server has its interfaces in the com.dumbhippo.server package and implementation in com.dumbhippo.server.impl. These are the stateless session beans that implement our "business logic" ("fun logic"?).
Each method on the beans has to be standalone; in stateless session beans, object-orientation goes down the tubes a bit since state isn't preserved across method invocations, i.e. each method's results should depend only on the method arguments and the database, never on fields in the bean. In fact stateless session beans should not have fields unless they're injected by the application server.
Web Tier
The web tier runs in the same process with the stateless session beans, managed by a copy of Tomcat inside JBoss. The code for the web tier can be found in the com.dumbhippo.web package, and the JSP pages can be found in server/web/jsp2.
Our JSP pages are backed by custom objects instantiated by the dh:bean tag. These custom backing beans for JSPs are not supposed to contain significant logic; they invoke the stateless session beans to do the heavy lifting. In other words, the web tier is just a "view" onto the stateless session beans.
We have a special servlet called RewriteServlet that wraps all incoming requests and performs special magic. This is why our URLs are nice and don't have ".jsp" in them; RewriteServlet also sets cache headers, deals with the login cookie, and other odds and ends.
We don't support operation without cookies or without JavaScript; you'll see "jsessionid" pop up in URLs from time to time, this is caused by using the c:url tag we believe and sometime we should clean it up with a custom replacement tag.
A given URL could be implemented in lots of ways. If it's a JSP it will be in server/web/jsp2 or server/web/jsp. If it's an image, CSS, Javascript, etc. it will be in one of those directories under server/web. Static HTML pages can go in server/web/html. URLs can also be implemented by servlets, you can find the URL-to-servlet mapping in server/web/servlet-info.xml.
Ajax
For now we're using Dojo though that may change as we are only using the core utility methods for the most part, not any "widgets."
URLs intended for JavaScript XmlHttpRequest are sometimes in a custom servlet, but usually in the com.dumbhippo.server.HttpMethods interface which is automatically exported to the web by com.dumbhippo.web.HttpMethodsServlet.
The JavaScript file server/web/javascript/dh/server.js contains convenience wrappers for invoking XmlHttpRequest.
XMPP Server
The XMPP server is Jive Wildfire with some small custom patches, and a plugin. It's in trunk/wildfire.
wildfire/src/java/com/dumbhippo/jive/*.java contains code that implements the "user database" of the XMPP server in terms of calls to our application server.
wildfire/src/plugins/hippo contains our plugin which implements a bunch of extra kinds of message for our XMPP Schema.
Our changes to the Jive Wildfire core are small, the pristine upstream sources are on a vendor branch if you want to compare and see what we did.
IM Bot
You can find IM bot in trunk/imbot.
IM bot handles "send me a sign-in link" if you put in an AIM address on the /who-are-you login page. It also verifies AIM addresses if you want to add one to your account.
This is basically a cheesy implementation of the TOC protocol. It was originally based on JAIMBot but is close to completely rewritten.
IM bot uses JMS and supports a cluster of multiple bots, so we fondly consider it an Enterprise AIM Bot.
When testing, for the most part there's no need to start the IM bot.
Super
Super is a set of scripts for starting, stopping, and creating deployments of the above processes.
Hungry
Hungry is a black-box test suite for the server. It can also run performance metrics.
