Welcome to the GovernERP Project

Design Considerations

Infrastructure Issues and Discussion

On the large scale, GovernERP is a collection of application servers distributed across a wide area network that interface with each other through messaging, specifically the Java Message Service, JMS. This is a messaging based service oriented architecture. For the so called �final mile� of GovernERP, the gap between the user and their application server, we still have a service oriented architecture but the protocol is REST ("RESTful" on Wikipedia) over HTTP using the JSR311 standard.

By exposing GovernERP's user functionality as REST-ful services we are free to implement the user interface in may different ways. We could make a standalone desktop application in Java, visual basic or maybe even Adobe AIR (Adobe AIR on Wikipedia). We could make a web browser based application with DHTML (DHTML on Wikipedia) or Adobe Flex (Flex on Wikipedia). Users may access the GovernERP REST services themselves by making their own mashups (Mashup on Wikipedia). For our first user interface we will be using Dojo (Dojo on Wikipedia) to make a DHTML application.

One of the main design goals for GovernERP is to keep all the processing as asynchronous as possible. This keeps the system loosely coupled ("loosely coupled" on Wikipedia). There are two challenges that this presents for our user interfaces.

First, because REST-ful services that create, modify or delete information must run asynchronously we need some kind of notification when they complete.

Second, as part of the user experience with GovernERP we want to allow users to register interest in resources such that the user is notified when they change. For example if user A has a list of work orders displayed in a window and user B changes the due date on one of those work orders. Then user A's list should automatically update to show the new due date.

We are looking at several options to solving the notification problem. So far all the solutions we have looked at fall into two categories, Comet and Stomp. The Comet approach has the advantage of no client side plug-ins but requires that the Java Servlet container supports continuations and is more complex to connect to JMS. The Stomp approach has the advantages of ease of connection to JMS and guaranteed delivery but it does require that it be implemented in Java as an Applet or in ActionScript, ActionScript on Wikipedia, as a Flash SWF, SWF on Wikipedia. We are going to start with stomp and a client using a Java Applet.

Standards Compliance, Usability and Other Developer Resources

• Accessibility - WCAG 2.0 -- Compliance Level AAA
• Usability Guidelines