alc list

Checklist: Application Layer Checklist   tags: layer This is the master check-list for the application layer; all mandatory items must be implemented to ensure compliance with the R2 development standards. Contents Check Items  Related Topics and Pages Expand All Sections     Collapse All Sections Check Items   Expand All Check Items  Collapse All Check Items   [MANDATORY] Only application specific (non-business) functionality is located within the application layer.     [MANDATORY] All logic requirements are decomposed into a number of loosely-coupled, highly-cohesive application services.     [MANDATORY] All services within this layer expose a public API which can be called by the presentation layer components or other application services.     [MANDATORY] All service interaction is through well-defined public APIs, and never directly with any service implementation.     [MANDATORY] Services and APIs within this layer are not called from the service, integration or data access layers.     [MANDATORY] Caches, where required, are implemented using the Cache Decorator Pattern.     [MANDATORY] Service implementations within the application layer do not have any dependencies on the presentation layer(s).   Note that callback mechanisms may be employed, but the exposed callback API is actually provided by the caller and implemented by the callee.  This ensures that the presentation layer isn't being called directly, and the dependency tree doesn't contain circular references. Related Topics and Pages   Concepts Application Layer Reusable Assets Multi-layer Application Architecture Supporting Materials Checklist Adoption Levels

Data Access Layer (DAL) Checklist

This is the master check-list for the data access layer; all mandatory items must be implemented to ensure compliance with the R2 development standards.

  [MANDATORY] Only data access services are exposed by the data access layer; only data access requirements is handled by the layer.  

  [MANDATORY] All data access reuqirements are decomposed into a number of loosely-coupled, highly-cohesive DAOs based on the modelled data sources.  

  [MANDATORY] All DAOs expose a data access API which is only called by business services in the service layer.  

  [MANDATORY] All interaction with this layer is through public data access APIs, and not directly with any DAO implementation.  

  [MANDATORY] DAOs never call application or business services in the layers above, nor does it interact with the integration and presentation layers.  

  [MANDATORY] Caches, where required, are implemented using the Cache Decorator Pattern.  

 Integration Layer Checklist

 This is the master check-list for the integration layer; all mandatory items must be implemented to ensure compliance with the R2 development standards.
 

[MANDATORY] The integration layer doesn't provide any application or business services; it implements business service APIs only to provide remote access to those services.  

  [MANDATORY] Integration layer components are never called directly; access is always via a business service API.  

  [MANDATORY] Integration components are dependenct on service layer APIs, and never on other components or services with the service layer.  

  [MANDATORY] Integration components do not have any dependencies on either the presentation, application or data access layers.  

  [MANDATORY] Use of the integration layer must be invisible to the client of the APIs beign adapted by the integration layer.  

  [MANDATORY] The integration layer is a technical implementation layer, which does not provide any form of application or business logic.  

  [MANDATORY] Caches, where required, are implemented using the Cache Decorator Pattern in either the application or service layers.  

  [MANDATORY] R2ds (ES) Host Adapter is used for all integration layer implementations.  

 Presentation Layer Checklist

 [MANDATORY] The presentation layer does not contain any data processing or business logic.  

  [MANDATORY] The presentation layer does not directly interact with the integration or data access layers.  

  [MANDATORY] The presentation layer interacts with services in the application and service layers only.  

  [MANDATORY] All service interaction is through well-defined public APIs, and never directly with any service implementation.  

  [MANDATORY] The presentation layer doesn't cache any data returned by the application and/or service layers.  

  [MANDATORY] Execution Services Request Processing is used to handle all incoming requests.  

  [MANDATORY] All request processing is undertaken in the context of page-flow.  

  [MANDATORY] All events follow the event naming standards, including those events returned by processors.  

  [MANDATORY] All processors are designed such that they undertake only a single atomic unit of work.  

  [MANDATORY] Processor design uses instance variables to store configuration items only; all processors are stateless and reentrant.  

  [MANDATORY] Processor design uses only persistent and transient work context, irrespective of the use of page-flow.  

  [MANDATORY] With the exception of key data within the persistent work context, the presentation layer never caches or stores any other data.  

  [MANDATORY] The presentation layer's data model(s) never contains invalid data; invalid data provided by the user is caught by the form processing or JHX components.  

  [MANDATORY] All request processing is separated into two phases: action (request processing) phase, and render (response processing) phase.  

This applies irrespective of the channel.

  [MANDATORY] The render event mapping configuration must be used to identify the render phase with the overall request processing lifecycle.  

This applies irrespective of the channel.

  [MANDATORY] Data is supplied to the JSP through one or more form and/or view beans.  

  [MANDATORY] The JSP is written using the ES JHX components.  

Exception: ES 5.x series applications, or 5-series applications which have subsequently been migrated into ES 6-series, are permitted to use raw HTML, with JTSL and the ES form processing tag libraries.

  [MANDATORY] All input data is processed, validated and converted into a single form bean using ES JSF integration components.  

Exception: ES 5.x series applications, or 5-series applications which have subsequently been migrated into ES 6-series, are permitted to use ES Form Processing.

  [MANDATORY] All localization enhancements are supported and implemented providing full localization/bundle support.  

Applications are permitted to provide and implement only a single core langauge (usually English, en_gb or en_us).

  [MANDATORY] Error handling is undertaken in a common manner, using the published guidelines.  

  [Recommended] The presentation layer contains only a single front-controller, with some permitted exceptions.  

The only permitted exceptions are where additional front-controllers are being used to support file upload/download and co-existence strategies with different version of the ES framework.

  [Recommended] The presentation layer's data model(s) resuses object(s) exposed by the application and/or service layers.  

  [Recommended] Cross-field validation is undertaken by a processor that accepts the field-level validated form bean, undertakes cross-field validation and throws the appropriate exceptions.  

  [Permitted] Cross-field validation is undertaken by implementing the Validatable interface on the form bean.  

Acceptable only where ES form processing is being used; only in ES 5.x series applications, and ES 5.x series code which has subsequently been migrated into ES 6.x.

  [Permitted] Data is supplied to the JSP through one or more form and/or view beans, flattened into an ES view map.  

Permitted only where ES form processing is being used in conjunction with the form processing tag library.

Service Layer Checklist

  [MANDATORY] Only business process (as opposed to application specific or data access) functionality is located within the service layer.  

  [MANDATORY] All logic requirements are decomposed into a number of loosely-coupled, highly-cohesive business services.  

  [MANDATORY] All services within this layer expose a public API which can be called by the presentation or application layer components or other business services.  

  [MANDATORY] All service interaction is through well-defined public APIs, and never directly with any service implementation.  

  [MANDATORY] Services and APIs within this layer are not called from the integration or data access layers.  

  [MANDATORY] Caches, where required, are implemented using the Cache Decorator Pattern.  

  [MANDATORY] Service implementations within the service layer do not have any dependencies on the presentation and application layers.  

Note that callback mechanisms may be employed, but the exposed callback API is actually provided by the business service (caller) and implemented by the callee.  This ensures that the presentation or application layer isn't being called directly, and the dependency tree doesn't contain circular references.