Skip Headers
Oracle® Retail Allocation Operations Guide
Release 14.1
E57847-01
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

2 Technical Architecture

This chapter describes the overall software architecture for Oracle Retail Allocation. The chapter provides a high-level discussion of the general structure of the system, including the various layers of Java code.

Overview

Retail Applications are based on the Oracle Application Development Framework (ADF). The following diagram shows the key components that make up the architecture of Retail applications.

Figure 2-1 Oracle Retail Allocation's n-tier Architecture


Oracle Application Development Framework (ADF)

Oracle Application Development Framework (ADF) supports organizations in building cutting-edge rich enterprise business applications that are able to be customized and personalized in all dimensions. Customizations are global changes, visible to all users that are performed by an administrator. Personalizations are user-made changes that are only visible to the person making the change.

ADF is based on the Java Enterprise Edition platform.

Model-View-Controller (MVC) Architectural Pattern

Applications built using ADF follow a Model-View-Controller (MVC) architectural pattern. The goal of the MVC pattern is to clearly separate the application's functionality into a set of cooperating components.

ADF provides a set of components that realize the goals of each part of MVC pattern.

  • Model is realized by the ADF Bindings Layer.

  • Controller is realized by the ADF Controller Layer.

  • View is realized by the ADF Faces Layer.

  • ADF Business components and other back-end components that exist below the Model layer are called Business Services.

ADF Security

The ADF security layer provides the following:

  • Provides standards based (Oracle Platform Security Services (OPSS)) security framework with default roles and permissions.

  • Has tools to generate file-based identity store (for both Oracle Internet Directory (OID) and Active Directory (AD)) based on the framework.

  • Has tools to migrate file-based security store in to database for QA and production environments.

  • Has reference implementation for clients to manage the security based on their business needs.

  • Provides OPSS-based batch security framework (RAF).

  • Provides tools/documentation to implement centralized logout in SSO (Oracle Access Management (OAM)) environments.

ADF View (ADFv)

The View layer provides the user interface to the application. The view layer uses HTML, rich Java components or XML and its variations to render the user interface. JSF based tag libraries are used to display the User Interface (UI).

ADF Controller (ADFc)

This is the steering part of the ADF. It determines the flow and control transfer. The Controller layer controls the application's flow. Web based applications are composed of multiple Web pages with dynamic content. The controller layer manages the flow between these pages. Different models can be used when building this later. The most prominent architecture for Java-based Web applications relies on a servlet that acts as the controller. The Apache Jakarta Struts controller, an open source framework controller, is the de facto standard for Java-based Web systems. Oracle ADF uses the struts controller to manage the flow of Web applications.

ADF Business Components (ADFbc)

The business service layer manages the interaction with a data persistence layer. It provides services as data persistence, object/relational mapping, transaction management and business logic execution.

Business Components easily map the database object and extend it with business logic, validation and so on.

The idea behind Business Components is to abstract the data layer from the view layer. This is a key concept in the MVC pattern. Business Components expose the interface to the view layer by using an application module which contains View Object. Those view objects contain a specific usage of the data layer.

ADF Business Components implements the business service through the following set of cooperating components:

  • Entity object – An entity object represents a row in a database table and simplifies modifying its data by handling all data manipulation language (DML) operations for you. It can encapsulate business logic for the row to ensure that your business rules are consistently enforced. You associate an entity object with others to reflect relationships in the underlying database schema to create a layer of business domain objects to reuse in multiple applications.

  • View object – A view object represents a SQL query. You use the full power of the familiar SQL language to join, filter, sort, and aggregate data into exactly the shape required by the end-user task. This includes the ability to link a view object with others to create master-detail hierarchies of any complexity. When end users modify data in the user interface, view objects collaborate with entity objects to consistently validate and save the changes.

  • Application module – An application module is the transactional component that UI clients use to work with application data. It defines a data model that you can update and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.

ADF Model (ADFm)

This is the component that acts as the connector between the view and business logic layers.

The Model layer connects the Business Services to the objects that use them in the other layers. Oracle ADF provides a Model layer implementation that sits on top of Business Services, providing a single interface that can be used to access any type of Business Services.

Developers get the same development experience when binding any type of Business Service layer implementation to the view and Controller layers. The Model layer in Oracle ADF served as the basis for JSR 227, A Standard Data binding & Data Access Facility for J2EE.

Oracle Metadata Services (MDS)

The ability of an application to adapt to changes is a necessity that needs to be considered in the application design and that should drive the selection of the development platform and architecture. Flexible business applications must be able to adapt to organizational changes, different end user preferences and changes in the supported business are required.

MDS is the customization and personalization framework integral to Oracle Fusion Middleware and a key differentiator of the Oracle development platform. MDS provides a repository for storing metadata for applications, such as customizations and persisted personalization files and configurations.

Retail applications allow the following through MDS:

  • Personalization of saved searches through MDS.

  • Implicit personalization of few ADF UI attributes.

  • Customization of dasboards through Oracle Composer.

Retail Fusion Platform

The Retail Fusion Platform (commonly referred to as the Platform) is a collection of common reusable software components that serve as the foundation for building Oracle Retail's next generation ADF-based applications. The Platform imposes standards and patterns along with a consistent look and feel for Oracle Retail's ADF applications.

Java Back-end Components

Allocation services in legacy code are maintained to reduce the impact of the Fusion re-architectural changes. These Service classes are later called through ADF Business Component's Application module.

Data Access Patterns

The database interaction between the middle tier and the database is done using the industry standard Java Database Connectivity Protocol (JDBC). JDBC facilitates the communication between a Java application and a relational database.

Database Access Using ADFbc

JDBC is ingrained within Oracle ADF Business Components as the primary mechanism for its interaction between the middle tier and the database. SQL is realized within ADF business components to facilitate create, read, update, and delete (CRUD) actions.

Connection Pooling

When the application 'disconnects' a connection, the connection is saved into a pool instead of being actually disconnected. A standard connection pooling technique, this saved connection, enables Retail applications to reuse the existing connection from a pool. In other words, the application does not have to complete the connection process for each subsequent connection.

Data Storage

The Oracle database realizes the database tier in a Retail application's architecture. It is the application's storage platform, containing the physical data (user and system) used throughout the application. The database tier is only intended to handle the storage and retrieval of information and is not involved in the manipulation or in the delivery of the data. This tier responds to queries; it does not initiate them.

Accessing Merchandising System Data in Real Time

The data that the Retail application utilizes is located in both the application-specific and the merchandising system (RMS, for example) tables. Because Retail applications share the same schema as the merchandising system (RMS, for example), the application is able to interact with the merchandising system's data directly, in real time.