Assertions are not something most java programmers have dealt with because assertions are not part of the java language. Assertions are used usually at entry and exit points in a function, they make an assertion about the incoming or return value. They must -always- evaluate to true, otherwise the execution of the program halts. You could imagine writing a square root function which only works with positive numbers. You could place an entry assertion which asserts that the number presented to the function must be greater or equal to zero. You could also place the same assertions on the return value since a square root cannot be negative. You can imagine how this aids in debugging; if the exit assertion fails, you know your square root function has a bug. Or if the entry assertion fails, you know the number passed in is bogus. This prevents the program from continuing operation in a known bogus state and helps isolate the problem.

    The EntryAssertionManager (EAM for short) is similar to assertions in other languages, but stretches the definition some. Web programming is the ideal environment for assertions. The webbrowser is an untrusted source of information. If you are writing an online calculator, you may have a field where the user can enter a number. However, the user could really enter in a string, and possibly crash your program. If you've done any web programming before, especially in java, you know you spend a considerable amount of time checking types, null testing, and converting data into it's appropriate format. It would be much easier if you could simply program your code, assuming everything is fine, and have something else take care of converting formats, and confirming the data is not bogus.

    The EAM also stems from the idea that a single broker [or page] is may actually have more then one action. The EAM allows you to define a name for each of the actions which that Broker can perform. For each action you define, you also declare what form elements are required for that action to function , as well as the type of each of those elements. When a web request is sent into the Broker, it runs the request through the EAM, and the EAM determines what action [based on the previous definitions] is actually occurring in this request. By passing the EAM test, you know the form elements you declared are of the correct type, and the required elements are present. This means you do not need to spend any time converting variables to Integers, or testing to see if required variables are present, because the EAM will automatically convert the incoming variables to the type you defined. The EAM gives appropriate feedback to tests which fail, so you can remind the user that they cannot take the square root of a string.

    Declaring what form variables you use and their type ahead of time may seem like a tedious process. It's something which programmers coming from the Perl and CGI world might be particularly not accustomed to.  However it makes code incredibly easier to read, much safer to execute, and easier to maintain. Most web applications trust the browser far too much. The user can easily tamper with hidden variables and add unexpected elements to select boxes. Once you have declared all of the variables for a particular action, anybody can walk up to the code and clearly see what variables are required to function. They can see that a Integer MessageID is required for the delete message button to work. A startdate, endstate and message body are required for the create announcement button to work.

    With the EAM you get the best of both worlds. You get the added debugging facilities of assertions, coupled with the manageability of code. However the extra time you spend configuring the EAM is saved by the convenience functions it provides. Such as variable conversion, and action recognition. The result should be cleaner more manageable code, in approximately the same time.