Blog Not Needed

This has no real bearing on the actual functioning of diysearch, but since I am a professional software developer, one of the things i love to hate is process flow/architecture diagrams and documentation. Well, since I figure I’m giving this version of this project a real go, I developed a a high-level arechitecture and process flow that illustrates just how the site works and how it was designed (technically speaking).

The technical design for the site follows some pretty standard patterns, mostly the commands pattern or deligate pattern. Implemented in java, this means that each fundamental piece of functionality is defined in a class, that implements an interface that describes what an action is. The action (or command) is specified by the client (the front-end of the website) through a fully qualified package and class name (for those that know java, that should make sense). The servlet (diyServiceProxy) acts just as its name, as a proxy. It handles all of the requests (logging in, searching, browsing, everything) and translates those requests from an XML document into a java object. That object simply contains data (user id, category id, updated profile information etc.) Each request that goes into the service proxy has an associated processor. The processor is a java class that does all of the “heavy lifting” of preparing the actual request to the action class (command). Right now there are two processors: GENERIC and SEARCH.

The Generic processor just handles everything, which means it takes your request, transforms it from an XML document to a java object. Then figures out what command class needs to handle the request and then passes it off to the appropriate command. The “command” or “action” I refer to are defined in a series of classes called Engines. An Engine is just a java class that groups common pieces of functionality together. There is a Users engine, a Links engine, a Categories Engine and so on. Each of these engines specify and describe commands. For example, in the Users engine, there is a command called: COMMAND_AUTHENTICATE. This basically is executed when you (a registered user) sign into the site. Your username and password (which is encrypted) is sent as an XML document to the service proxy. The service proxy loads the GENERIC process, and the processor prepares the request. The processor then loads the appropriate engine (in this case the Users engine), executes the command. The result of the execution is another java object, one that looks a lot like the one for the request, but contains all of your user data (username, id etc.) That’s pretty much it in a nutshell. Yes there are more details I haven’t covered. Stuff like the data abstraction layer (iBATIS) and XML marshalling (castor) and how dynamic class loading works (through java’s reflection mechanism) and the finite details of how and why to use runtime class loading versus hardcoding logic to determin what action to perform, stuff like that.

So, why go through all the trouble of this? Well for a bunch of reasons. 1. Because I’m a pro at this and if you are going to do it, do it right. This architecture is very much “uncoupled.” Meaning I can fix, change or add new functionality without disturbing the system. Think how your firefox plugins work. Same principle here, just much more complicated and more moving pieces. 2. Maintainability. Code that is modularized clearly delineates what is doing what. If there is a problem with users authenticating. I don’t have to search through a huge chunk of code to find where this is happening. I just open up the Users engine, and look at the command definition. Yes, there are nearly 25,000 lines of code in this application, but anyone who is well-versed in application development could get up to speed on the entire code base within a day or so, that just makes things easier.

So, after having said all of that, where are we? Well, development is done! Yes, all of the major pieces of functionality have been completed. There are some odds-and-ends to finish (content to fill in, an FAQ to write) and I need to finish the payment processor for the value-add promo things I’ve added. I know testing was supposed to start this week. Its going to be a week late, and I’ll only have a week to test, but honestly, I think that’s all I’ll need. I’ve been doing so much unit testing as I go I’ve fixed about two dozen real bugs.

Post a Comment | Trackback URI