9 Frameworks

The Oracle Retail architecture uses a combination of technologies that make it flexible and extensible, and allow it to communicate with other hardware and software systems. The frameworks that drive the application are implemented by the Java programming language, distributed objects, and XML scripting. The User Interface, Business Object, Manager/Technician, Data Persistence, and Navigation frameworks interact to provide a powerful, flexible application framework.

Frameworks

This section describes each framework.

Manager/Technician

The Manager/Technician framework is the component of Oracle Retail Platform that implements the distribution of data across a network. A Manager provides an API for the application and communicates with its Technician, which implements the interface to the external resource. The Manager is always on the same tier, or machine, as the application, while the Technician is usually on the same tier as the external resource.

Figure 9-1 shows an example of the Manager/Technician framework distributed on two different tiers.

Figure 9-1 Manager/Technician Framework

User Interface

The UI framework includes all the classes and interfaces in Oracle Retail Platform to support the rapid development of UI screens. In the application code, the developer creates a model that is handled by the UI Manager in the application code. The UI Manager communicates with the UI Technician, which accesses the UI Subsystem.

Figure 9-2 illustrates components of the UI framework.

Figure 9-2 UI Framework

Table 9-1 describes the components of the UI framework.

Table 9-1 UI Framework Components

Component	Description
Resource Files	Resource files are text bundles that provide the labels for a screen. They are implemented as properties files. Text bundles are used for localizing the application.
Bean	Beans are reusable Java program building blocks that can be combined with other components to form an application. They typically provide the screen components and data for the workpanel area of the screen.
Specs	Specifications define the components of a screen. Display specifications define the width, height, and title of a window. Template specifications divide displays into areas. Bean specifications define classes and configurators and additional screen elements for a component. Default screen specifications map beans to the commonly used areas and define listeners to the beans. Overlay screen specifications define additional mappings of beans and listeners to default screens.
Specification Loader	Loaders find external specifications and interpret them. The loader instantiates screen specifications such as overlays, templates, and displays, and places the objects into a spec catalog.
Catalog	A Catalog provides the bean specifications by name. The UI Technician requests the catalog from the loader to simplify configurations.
Configurator	The UI framework interfaces with beans through bean configurator classes, which control interactions with beans. A configurator is instantiated for each bean specification. They apply properties from the specifications to the bean, configure a bean when initialized, reset the text on a bean when the locale changes, set the bean component data from a model, update a model from the bean component data, and set the filename of the resource bundle.
Model	The business logic communicates with beans through screen models. Each bean configurator contains a screen model, and the configurator must determine if any action is to be taken on the model. Classes exist for each model.
UI Manager	The UI Manager provides the API for application code to access and manipulate user interface components. The UI Manager uses different methods to call the UI Technician.
UI Technician	The UI Technician controls the main application window or display. The UI Technician receives calls from Point-of-Service tours, locates the appropriate screen, and handles the setup of the screens through the UI Subsystem.
UI Subsystem	The UI Subsystem provides UI components for displaying and editing Point-of-Service screens. The UI subsystem enables application logic to be completely isolated from the UI components. This component is specific to the technology used, such as Swing or JSP.
Adapters	Adapters are used to provide a specialized response to bean events. Adapters can handle the events, or the event can cause the adapter to manipulate a target bean. Adapters implement listener interfaces to handle events on the UI. Adapters come from the Swing API of controls and support JavaPOS-compliant devices.
Listeners	Listeners provide a mechanism for reacting to user interface events. Listeners come from the Swing API of controls and support JavaPOS-compliant devices.

Business Object

The Commerce Services layer of the architecture contains the Business Object framework that implements the instantiation of business objects. The Business Object framework is used to create new business objects for use by Point-of-Service. The business objects contain data and logic that determine the path or option used by an application.

Figure 9-3 Business Object Framework

Table 9-2 describes the components in the Business Object framework.

Table 9-2 Business Object Framework Components

Component	Description
DomainGateway	The DomainGateway class provides a common access point for all business object classes.
Domain Object Factory	The Domain Object Factory returns instances of business object classes. The application requests a Factory from the DomainGateway.
Business Object	Business objects define the attributes for application data. New instances are created using the Domain Object Factory.

Data Persistence

A specific Manager/Technician pair is the Data Manager and Data Technician used for data persistence. Figure 9-4 illustrates how data gets saved to a persistent resource.

Figure 9-4 Data Persistence Framework

Table 9-3 describes the components in the Data Persistence framework.

Table 9-3 Data Persistence Framework Components

Component	Description
Data Manager	The Data Manager defines the application entry point into the Data Persistence Framework. Its primary responsibility is to contact the Data Technician and transport any requests to the Data Technician.
Data Manager Configuration Script	The Data Manager processes data actions from the application based on the configuration information set in the Data Manager Configuration Script. The Configuration Script defines transactions available to the application.
Data Technician	The Data Technician provides the interface to the database or flat file. This class is part of the Oracle Retail Platform framework. It provides entry points for application transactions sent by the Data Manager and caches the set of supported data store operations. It also contains a pool of physical data connections used by the supported data operations.
Data Technician Configuration Script	The Data Technician Configuration Script specifies the types of connections to be pooled, the set of operations available to the application, and the mapping of an application data action to a specific data operation.
Transaction Queue	The Transaction Queue holds data transactions and offers asynchronous data persistence and offline processing for Point-of-Service. When the database is offline, the data is held in the queue and posted to the database when it comes back online. When the application is online, the Data Manager gets the information from the Transaction Queue to send to the database.

Tour

The Tour framework establishes the workflow for the application. It models application behavior as states, events and transitions. The Oracle Retail Platform engine is modeled on finite state machine behavior. A finite state machine has a limited number of possible states. A state machine stores the status of something at a given time and, based on input, changes the status or causes an action or output to occur. The Tour framework provides a formal method for defining these nested state machines as a traceable way to handle flow through an application.

Tourmap

One problem of tour scripts is that they can be difficult to customize for a particular retailer's installation. The tourmap feature allows customizations to be made more easily on existing tour scripts. Tour components and tour scripts can be referenced by logical names in the tour script and mapped to physical names in a tourmap file, making it easier to use the product tour and just change the pieces that need to be changed for a customer implementation. In addition, with tourmaps, components and scripts can be overridden based on a country, so files specific to a locale are implemented when appropriate.

The tourmap does not allow you to modify the structure of the tour, specifically the following:

Does not allow you to add or remove sites
Does not allow you to add or remove roads and aisles
Does not allow you to specify a tour spanning multiple files (for example, ”tour inheritance”)

Of particular note is the last bullet: the tourmap does not allow you to assemble fragments of xml into one cohesive tour script. After the application is loaded, there is only be one tour script that maps to any logical name.

The functionality of tourmapping is implemented using one or more tourmap files. Multiple tourmap files can be specified using the config\tourmap.files properties. tourmap.files is a comma delimited list of tourmap files. As each file is loaded, the application checks the country property of the tourmap file. The order of files is significant because later files override any values specified in previous files. A file that overrides a similarly-named file is called an overlay.

Each tourmap file begins with a root element, tourmap, which has an optional country attribute. The tourmap elements contains multiple tour elements, each one of which describes a tour's logical name, its physical file, and any overlays to apply. For instance, a simple tourmap might look like the following:

Example 9-1 Sample Tourmap

<?xml version="1.0" encoding="UTF-8"?>
<tourmap
   country="CA"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="com/extendyourstore/foundation/tour/dtd/tourmap.xsd">
    <tour name="testService">
       <file>classpath://com/extendyourstore/foundation/tour/engine/tourmap.testservice.xml</file>
       <SITE
          name="siteWithoutAction"
          useaction="oracle.retail.stores.foundation.tour.engine.actions.overlay.OverlaySiteAction"/>
       <SITEACTION
          class="SampleSiteAction"
        replacewith="oracle.retail.stores.foundation.tour.engine.actions.overlay.OverlaySiteAction"/>
          
    </tour>
</tourmap>

In this instance, the tour with the logical name testService references the file com\extendyourstore\foundation\tour\engine\tourmap.testservice.xml. Additionally, the values for SITE and SITEACTION are replaced.

Note:

Because of the country in the tourmap element, this only happens when the default locale of the application is a Canadian locale.

Tourmaps are used not only to override XML attributes, but they are used also when the workflow needs to be changed.