Project.net Architecture

March 11, 2007 Roger -- This page is Work in Process.

The first generation Project.net application (v8.2 and earlier) was built before modern application frameworks (such as Spring) were available. There are several areas of the application that should be re factored to modernize the architecture.

There are several issues with the first generation product.

  • the use of XLST transformations of XML in the presentation layer is difficult to code and debug
  • the use of PL/SQL stored procedures in the Database is hard to test and limits database portability.
  • Architectural layers are not properly separated. For example, the domain objects provide their own persistence methods. Data access and persistence should be implemented in Data Access Object (DAO) layer and persistence layer.

Architectural Improvements

Goals

Our high-level, long-term goals for improving project.net architecture are:

  1. Loosely-coupled -- more loosely coupled, higher cohesion components.
  2. Integration -- Allow easy integration, information exchange, mash-ups with other tools, applications, services.
  3. Scale -- Ability to scale project.net for deployment into Google-class ASP infrastructure.
  4. User Experience -- Fun to use, quick to get started, web 2.0 feel, role-based, configurable UI.
  5. Abstraction -- Improve the separation and abstraction of layers using a modern application framework.
  6. Productivity -- Improve developer productivity, product testability, and product robustness.

New Technologies we are Using

The following technologies have been selected for use by developers in the Project.net product. Most of these are already being used in some areas of the application.

  • Spring Framework -- Spring is being introduced throughout the application. When implementing large new features or doing major refactoring, you should use use Spring. Separating DAO objects from the current project.net domain objects using Spring interfaces is one important step.
  • Hibernate -- Hibernate, via Spring interfaces, should be used wherever possible. All object CRUD persistence operations should use Hibernate. We hope to eventually eliminate all stored procedures and JDBC code if possible. When implementing large new features or doing major refactoring, you should use Data Access Objects and Hibernate Persistence via the Spring interfaces.
  • Xfire -- for RESTful web services.
  • Junit -- for unit testing. We need to write unit tests for all classes. New development should always include unit tests.
  • log4j -- for application debug logging.

New Technologies we are Considering

The following technologies are our current favorites, but they are not yet being used or piloted.

  • Tapestry -- for Presentation Layer.
  • Dojo -- for AJAX widgets.
  • JSR 168 -- for Portlets.

Loosely Coupled

The "Project.net Core" is the current v8.2 application. In certain cases, we plan to add new functionality as separate loosely coupled modules as well as extract existing functionality from the Project.net Core into separate loosely coupled modules.

These components might be connected via a publish-subscribe event driven archicture (EDA) or a request-response service oriented architecture (SOA). Modern web applications often combine both these architectures because they are both needed to solve different problems.

True loosely coupled components don't rely on each other. They use well-defined interfaces. These interfaces can be provided by:

  • java interface classes (via Spring)
  • web services (such as REST, SOAP)
  • event bus (such as JMS)

The Project.net Core

  • provides the core features, services, and UI for team members to communicate, collaborate during the daily execution of multiple projects.
  • provides the features and underling services that tend to tightly integrated within the UI.
  • provides the services and engines used by other Project.net Core features when high performance and low latency is critical.