What is the Three Tier Application Architecture ?
Note: The term Business Object Model is named 'Application Model' in the UNIFACE Beta release.
Business Objects
Composite Business Object Structures
UNIFACE Presentation Components
Other Presentation Components
The following figure outlines the UNIFACE three tier architecture.
The data access layer consists of:
Supertype entities (for short: supertypes), are Entities in the Business Object Model that primarily represent physical database structures.
Functional subtypes are subtypes that specialize entity behavior from a business perspective. Functional subtype are the same as UNIFACE 7 subtypes.
Component subtypes are subtypes that tailor an entity for specific use at a particular component type. Component subtypes are derived from supertypes, as well as from functional subtypes. The following component subtypes are supported:
Troughout the document, we will talk about USP subtypes, SSV subtypes, ESV subtypes, ... for short.
Component subtypes replicate the parent relationships, in order to have frame-in-frame on board.
Subtypes inherit triggers from their parent(s). Properties are copied.
We distinguish between business logic for individual business objects and business logic for composite business object structures.
Business Objects
Entity service subtypes (ESV subtypes) resemble the individual business object, i.e.:
- Field validation
- Key validation
- Occurrence validation
- 'afterCreate', 'beforeRemove', 'afterUpdate' behavior
Entity services are components that:
- Supply a runtime container for business objects (i.e. occurrences of the painted ESV subtype).
- Receive requests for executing actions on business objects
- Arrange communication to the DBMS driver
Each entity service contains one painted entity: An ESV subtype. There is one entity service for each ESV subtype.
Generally, the UNIFACE 8 entity service resembles the UNIFACE 7 object service. The entity service has the same component operations as the object service. However, entity services make a split within the implementation of these operations. The UNIFACE 'client to object service' protocol implementation is kept apart from the implementation of the actual business logic. Once the former has found out what should happen, the right operation is activated on the business object. Since this is an occurrence of the painted ESV subtype, business object behavior is inherited from the Business Object Model.
The main advantage of using an entity service is: For each business object, there is only one component containing its business logic. Thus, upon making change to single business obect behavior, you only have to re-compile and re-deploy the related entity service.
UNIFACE 7 object services are migrated into Entity Services and are upwards compatible.
Composite Business Object Structures
Session service components define composed, hierarchical record sets by painting frame-in-frame SSV subtypes. The purpose of a session service is:
- To define a hierarchical data structure
- To concentrate all business task specific behavior at this structure
- To expose the actual data as stateless, disconnected XML record sets to any client component
- To manage referential integrity across (heterogeneous) databases
You can choose if data access and business object behavior is to be delegated to an entity service. The default is: 'not - To Database' [UNIFACE beta: the default is 'yes - To Entity Service']. The default can be customized. Communication to an entity service is statefull and is accomplished by interchanging UNIFACE entity and occurrence parameters (UNIFACE 7 object service technology).
Hierarchical data structures are defined by painting a number of entities (and fields) frame-inside-frame. Typically, SSV subtypes are used for this purpose. Note that this structure may also be used for managing referential integrity (see below).
Business task specific behavior is implemented by a number of component operations and model defined SSV subtype operations.
Client to session service communication is stateless. Data is interchanged as disconnected XML record sets. These are described by Document Type Definitions (DTDs). If a client posesses slight differences in its internal structure when compared to the DTD, then it is assumed the client is responsible for mapping the session service data to its own internal structure.
Referential integrity is managed by the frame-in-frame construction. This only takes effect when relationships are defined such, that the DBMS does not manage referential integrity. If a session service delegates business object behavior to an entity service, then delete instructions are all fired explicitly (i.e. no DBMS wild card deletes for the inner most entity are then supported). [UNIFACE beta: deletes for inner most are not delegated to entity service, nor processed on the session service].
UNIFACE Presentation Components
Server pages, forms and reports are the UNIFACE presentation components. They typically contain USP, FRM and RPT subtypes. If you opt for a three tier solution, then Data Access for these subtypes is typically defined as 'Not In Database'. Rather, a stateless communication protocol needs to be set-up with a session service. See the document 'Details On How To Develop a Three Tier Application' for more details.
Other Presentation Components
Apart from the UNIFACE presentation components, other presentation components can be implemented on top of a session service, whilst the business logic from the session service is re-used. For example:
- JAVA server pages (call-in into UNIFACE via CORBA)
- Active server pages (call-in into UNIFACE via DCOM [UNIFACE beta: Not yet available])