Q:

Is this architecture definition OK? Multi-tier (Spring / Multi DB)

Here´s the background, maybe some of the terms are incorrect, as I´m not an expert in this area:

I applied several years ago the
  following architecture, in order for
  getting code reuse and kind-of
  separation of concerns:

Presentation Layer: Using ASP.NET with C#. The web page logic is
  programmed in here, but the business
  logic is defined in a separate layer
Model Definition Layer: Groups all the business entities of the
  system (i.e. Document, User, Folder).
  There are no actions (methods beside
  getters and setters) defined on the
  object. It just represents a record
  from a table (or a join of tables) in
  the database
Business Logic Layer: The clases in here are named "Engines", and they
  have all the business rules
  interaction for each Business entity
  (i.e. DocumentEngine has all the
  methods that represent the business
  rules for handling Documents over the
  system, like Adding, Deleting,
  Updating, etc.). These methods use (as
  parameters) and return Business entities (defined on Model definition) in many cases, in others just use/return primitives.
Data access layer: This layer retrieves the data (using the Data
  Access Service) from database and
  convert it into Business Entities (Creating an instance of an object defined in MDL and set its properties values with the corresponding field values retrieved from DB).
  Like the Business Logic Layer, it uses
  and return the Business entities or primitives
  previously mentioned as a single
  object or a collection of object
  (using Generics)
Data access service: Using the Simple Factory Pattern, creates the
  database connection according to the
  specified parameters, so it can
  retrieve the information from multiple
  DB engines. 

OK then, when I need, for example a list of documents, I open the web page, the business rule is called with the proper parameters (i.e. the Folder Id for this case). Then the data access layer uses the DAS to query the database and converts the record(s) retrieved into Business entities (Defined in the MDL). This business entity (or collection of entities) is returned trough layers to the Presentation Layer.

Now, maybe this is not the best architecture, but it has worked very well to me, so now I´m trying to use the same approach but using Java with Spring MVC as the presentation layer, so I´ll have

Presentation (Spring MVC)
Model definition layer
Business logic layer 
Data access layer
Data access service (Database factory using JDBC)

The business requirements are "create an enterprise lightweight web application, that can be extended easily, connected to multiple DB (Oracle, SQL Server, mySQL) with minimal code changes, I18N supporting, ability of logging user activities, having several presentation modes (Web, Mobile) and looks very nice like Web2.0 applications XD" 
What do you think? Is this a good architecture definition? Should I change something in order to comply with business requirements?
Thanks in advance for your cooperation

A:

In the late 70s, just after the relational database started getting traction, and procedural programming was the thing to do, this would have been a fine architecture, adapted to use the newer web presentation layer. 
In the early eighties the introduction of object orientation showed that separation of data and behavior leads to more coupling and less cohesion. Separation of model definition and business logic is a bad idea. It tends to arise from relational-database driven architectures, which tend to have no place to manage behavior. 
Because of the RDBMS dominance, these architectures arise a lot. That doesn't make them good. The main issues arising are: 

repetition of the same concerns in multiple layers;
bad data quality by separating validation functionality from the data it operates on;
insufficient normalization because of bad join performance.

These issues limit the scalability of this architecture. A Domain-Driven Design performs better in these aspects.
In addition, your architecture doesn't tackle the consequences of mobile presentation adequately. Mobile is more than a smaller screen, it also involves a touch interface and limited connectivity (long delays, little bandwidth and caching, handling no connection).

