Design for financial institutes


EJB design: Design for financial institutes

  1. Design for financial institutes (2 messages)

    Hi all

    I am participated in a project that develops a system for financial institutes. As I
    am not a experienced developer and I would like to hear the advice from other
    more experienced developers in that field.

    The requirements of the system include:

    - all actions taken by the user must be auditable
    - all actions taken by the users must be reversible (undo)

    One of the team member suggested using XML messages to invoke methods,
    which means the XML documents contains the program name, function name and
    parameters of the function and the XML documents will be written to the
    database therefore, actions will be auditable and reversible. He claimed
    that it is even more flexible because extra parameters can be placed in the
    XML document and reciever only processes the parameters it knows. However,
    I really have doubt about it because it makes the function call not type-safe
    and is writing the XML documents in the database a good way to achieve
    auditability and reversibility.

    I believe most applications for financial institutes would have the above
    requirements and I would like to know how other people achieve it.

    Thanks for any suggestion!


  2. Design for financial institutes[ Go to top ]

    Well, one approach would be to keep historical data for all the information in your database. A typical way to do this is to have historical tables, and copy each existing record to the historical table for every update (along with user/timestamp info). You can do this with your application logic or with a database trigger. You can use some special markers for exceptional operations (like deletes and inserts).

    This gives you your auditing. For an undo operation, simply copy the most recent record out of the history table, and update the "real" table with that data.

    Note that this only tracks operations on your data. This may be enough, though. If you are exceptionally paranoid, you may want to audit select operations, but these won't need an undo feature.
  3. Design for financial institutes[ Go to top ]

    Hi Edmond,

    I would recommend that you look into the command pattern. All data is transferred to the server in a command object. The command is executed in the server and all updates are performed. The command should in this case also have an undo method that is responsible for reversing the action performed. Instead of using XML which requires serialization/deserialization on both tiers the command object encapsulates all data. To keep an audit of the event each command class has an audit method which stores all relevant data to the database.

    Hope this helped you.


    Erik Kayser