The general idea is to add a new application to the system. A new application is comprised of three components:

• A servlet which responds to a particular URL
  
• A servlet "handler" which handles get and post servlet events
  
• A model class which manipulates any data necessary for the servlet's function
  
  The core ideas are these:
• Each servlet responds to a given URL
  
• Each servlet is responsible for booting its handler
  
• Each servlet handler responds to GET and POST verbs (actions). In this system, we define verbs in interface definitions such as ITopicMapMicroformat.java; verbs are also associated with fields, each of which defines a particular data item. Fields are defined along with verbs. The system provides many common verbs and fields which can be reused.
  
• Each servlet handler is responsible for booting its model
  
• Each model is given a copy of ServletEnvironment which provides numerous services which can be shared
  
• Each model can define its own services, such as custom databases, custom data analysis systems, and so forth.
  

BacksideServletKS, in its main.java class, will boot a collection of core applications. It will then boot any servlet defined in the file /config/config-props.xml as described next.

<list name="Servlets">
<parameter name="urlfragment" value="servlet.classpath" />
</list>

Each servlet is addressed by a particular URL, such as http://server.com/_servlet_/... where servlet might be, say "admin" for the admin servlet, or "tm" for the topic map servlet. That is the name in the parameter. The value in the parameter is the class path to the servlet class itself. Consider this example:

org.topicquests.backside.servlet.apps.myapp.MyAppServlet

That would be the full classpath to a servlet class which gets booted by the system.

Servlets are basically clones of each other. It is possible to clone and mutate, say, TopicMapServlet into the org.topicquests.backside.servlet.apps.myapp path. It must then be modified to call the handler.

A handler must extend the BaseHandler class. Study TopicMapHandler to see how this is done. Each handler has the task of responding to any verbs created for the application. The handler must also boot its model. Study TopicMap model to see how this is performed.