OpsAdminImplementation

In this section we state implementation and design decisions.

Rough architecture

A rough architecture of OpsAdmin has these layers:

• the domain objects (project, task, user, calendar, timesheet). We'll use plain java objects (POJO's) for this. Ivana has been thinking what each of these classes will have.
• the user interface, which use the domain objects to show them and edit them. We'll be using Wicket for this.
• the data access layer. We'll access ldap directly, probably using Spring LDAP or the standard java api for ldap.

OPS Web Services vs direct access

The data update (adding and modifying projects, tasks, etc.) has to be done somewhere. One option is to do it directly in our OpsAdmin application. The problem with this approach is that there is no unique point of access and then if we create another front end for the same or similar purpose we will have to implement the same business rules again.

So another option that is coherent with the rest of OPS is to create the necessary Web Services in OPS server that effectively updates the data and make any necessary validations and apply business rules.

So:

• OPS Web Services
  • + implement once the 'dirty' access to data
  • + unique point of access, ensures application of business rules always takes place (if there are any :))
  • + interesting example of separation of interface and business layers
  • - takes more time
• direct access through OpsAdmin
  • all the opposite :P

I (Flavia) think that it's best to implement the Web Services, specially because a big part of our goal is to show examples of clean design, and it's also an opportunity to use web services.

In a fist stage we will implement the application with direct access to LDAP, then refactor and move our ldap-access code to corresponding web service methods, and call them.

-- FlaviaPaganelli - 05 Mar 2007

Maven vs Ant

The new OPS should use maven instead of ant, because everything else we do now uses maven. -- IvanaCace - 08 Mar 2007