Monday, March 19, 2007

Technical White Paper

Application Architecture using a Native Aspect Oriented Database

Level: Intermediate

March 16, 2007

Version 1.0

Abstract: The architecture of an application is chosen to enable the development of the software that achieve the goals of the business at hand. Many times an architecture is chosen from a pattern or template of common architectures such as MVC or SOA. An architecture is created to achieve specific goals usually controlling complexity. Tools are created to achieve the same goal as well. An Aspect Oriented Database is being created and it will have the goal of simplifying use cases involved with data management. Typically, this is related to the model in an MVC architecture, or the domain model in SOA. Building an application with an AODBMS will motivate alternative choices when designing an architecture for your application.

Architecture impacts with framework usage: many web frameworks provide a controller implementation which simplifies your application development effort. There are many persistence frameworks that simplify the effort of storing an object in a relational database.

MVC is orthogonal to your business concerns. The MVC architecture divides the concerns of your application into three categories. Concerns can be modeled fitting this approach, but there is some divergence from the true concept to make it fit into such a structure. There are typically more than three kinds of concepts that an application needs to deal with The MVC breakdown is an effort at mapping your application's classes into these kinds of types.

AOP allows for the implementation of design patterns are first class language structures

An application is created to satisfy business goals. A business lives within a domain of concepts.

MVC was created as an approach to controlling complexity. The partitioning of concerns into this triad is simple and should be understandable by a large community of developers. As applications become more complex, this complexity must be addressed with various techniques.





Design Patterns


AOP has tradionally been associated with modularizign behavior that is scattered accross a system. So what does AOP have to do with data management? There are many things that an application needs to do with it's data. Discovery of the objects, managemnt of it's state, navigation of relationships, and other things. But there are many patterns found in persistent information that require extra fields of columns in a relationsl database in order to implement the concepts. For example a revision history of an object, such as a warehousing application would add effect start and end times to the row and make a new row for each update. This can be expressed as an aspect of the object under revision. The aspect data is orthogonal to the application data, that is it is seperate from, but united by the need of the feature applied to the object. An aspect oriented database would have native support for this feature (concern).

No comments: