| Oracle® Retail Price Management Oracle® Retail Price Management Operations Guide Release 15.0 E64975-01 |
|
 Previous |
 Next |
| Oracle® Retail Price Management Oracle® Retail Price Management Operations Guide Release 15.0 E64975-01 |
|
Previous |
Next |
This chapter describes the overall software architecture for RPM. The chapter provides a high-level discussion of the general structure of the system, including the various layers of Java code. From the content, integrators can learn both about the pieces of the system and how they interact.
A description of RPM-related Java terms and standards is provided for your reference at the end of this chapter.
RPM's architecture is built upon a layered model. That is, layers of the application communicate with one another through an established hierarchy and are only able to communicate with neighboring layers. Any given layer need not be concerned with the internal functional tasks of any other layer.
Conceptually, RPM's J2EE architecture is built upon 4-layers and implements what is defined as a service-oriented architecture. Such an architecture is essentially a collection of services that pass data, perform business processing, coordinate system activities, and render data into abstract objects. Defined in the abstract, a service is a function that is well-defined, self-contained, and does not depend on the context or state of other services within the system.
The application's layered Java architecture has the following advantages, among others:
The separation of presentation, business logic, and data makes the software cleaner, more maintainable, and easier to modify.
The look and feel of the application can be updated more easily because the GUI is not tightly coupled to the backend.
Java applications have enhanced portability which means the application is not locked into a single platform. Upgrades are easier to implement, and hardware is easier to change.
Logic is implemented using Java objects within a core services layer that is designed around proven architecture concepts.
The following diagram, together with the explanations that follow, offer a high-level conceptual view of RPM's service-oriented architecture. The diagram highlights the separation of layers as well as their responsibilities within the overall architecture. Key areas of the diagram are described in more detail in the sections that follow. 
The application's client layer is comprised both of the GUI and interfaces. The GUI is responsible for presenting data to the user and for receiving data directly from the user through the front end. The GUI was developed using a Java Swing framework, which is a toolkit for creating rich presentation in Java applications. A design library defines look and feel issues.
The Oracle Web Service Layer and batch processing interfaces also behave as clients to the application. They are interface points that interact with the system's application services layer.
For more information about how Web Service Layer integrates with RPM, see Chapter 5, ”RPM and the Oracle Retail Web Service Layer." For more information about batch processing, see Chapter 7, "Java Batch Processes".
Application services are designed to provide specific services and specific data requirements to a particular client. What application services a client calls depends upon its needs and the data formats it has. Application services are concerned with somewhat narrow processes. Not surprisingly, the names of application services often correspond to client-related processes.
The application services layer of RPM's architecture implements the enterprise Java bean (EJB) type called stateless session beans (SSB). An SSB is a type of EJB that provides stateless service to a client. For example, a stateless session bean could be designed for the GUI. The application services reside on the server side of the process boundary (also known as the remote call boundary).
The application-specific services layer provides an interface between a particular client and the adjacent core services layer. To solve a business problem, application services call one or more core services. Application services could also call other application services. For example, one application service has a large granularity and needs another one to perform minor grain transformations.
An important way that application services accept incoming data from a client is via value objects and/or payloads. A value object is a data holder in a highly flat form (similar to a bean). Value objects facilitate improved system performance. For example, from the GUI, the value object data only has to be what is needed by an applicable screen or set of screens. A payload holds the data that satisfies the needs of the applicable interface (Web Services, for example).
The application services layer's primary function is to facilitate the conversion of value objects/payloads to business objects and business objects to value objects/payloads which are required by the adjacent layers. The value objects/payloads accepted from and returned to the application services layer are nothing more than data-centric classes which encapsulate closely related items. Value objects/payloads are used to provide a quick and lightweight method to transfer flat data items. The value objects/payloads passed between the application services layer and the application services layer contain very little, if any, data processing logic and in the context of the RPM are used solely to transfer data.
The application services depend upon both core services and business objects, translating back and forth between input from the client and business objects in the core services layer. The application services call the applicable core service at the applicable time.
This layer consists of a collection of separate and distinct services that encapsulate the RPM application's core business logic. Core services are core in the sense that they work with the business object model, and they contain the business object rules for the application. Unlike application services, core services make no presumptions about how they might be used. In other words, core services contain generic views of business functionality as opposed to a narrow application service process.
Residing very close to the core services, business objects represent business problems. Business objects contain behaviors. For example, they perform validation and guard themselves from being used improperly. To ensure the atomicity, consistency, isolation, and durability (ACID) properties of state transitions, RPM implements some business logic using a state machine (a workflow engine). Each object that has a lifecycle has a state machine, which describes the object's lifecycle.
Sometimes core services drive processes with business objects, but more often, core services are responsible for finding the business objects and sending them back to the persistence layer. The core services layer is thus responsible for managing object persistence by interacting with the data access objects residing in the supporting persistence layer.
To summarize, the core service layer consists of a collection of Java classes that implement an application's business related logic via one or more high-level methods. The core services represent all logical tasks that can be performed on an application's business objects.
RPM uses Hibernate, an object/relational persistence and query service for Java. This object-relational framework provides the ability to map business objects residing in the core services layer to relational tables contained within the data store.
Conceptually, Hibernate encompasses most of the persistence layer. Hibernate interacts with core services by passing/accepting business objects to/from the core services layer. Internally, Hibernate manages the conversion of RPM's business object to relational data elements required by the supporting relational database management system (RDMS).
For information about Hibernate-related logging, see Chapter 2, ”Backend System Administration and Configuration."
The database tier is the application's storage platform, containing the physical data used throughout the application. The system is designed to include two RDMS data sources, RPM and RMS.
The RPM application provides basic authorization and authentication functionality during user logon.
To facilitate the authentication of users, RPM is integrated with a third party directory service application. Core services interact using Light Directory Access Protocol (LDAP), which allows RPM to talk with the third party directory service. The LDAP standard defines a network protocol for accessing information in a directory.
Although RPM is configurable to use any LDAP-compliant directory server, the system is certified to work with Oracle's Oracle Internet Directory (OID). The OID is an LDAPv3 directory that leverages the scalability, high availability and security features of the Oracle Database.
RPM uses LDAP for two purposes:
As the master repository of user information
As a third-party authentication service
In the second case, RPM authenticates users by binding to the LDAP Directory Server as the user who is attempting to log in to RPM. The user's password is never stored in RPM; it is passed along when RPM tries to connect to the Directory Server. If the connection to the directory server succeeds, the user is considered authenticated in RPM. Once a user has been authenticated via LDAP, RPM calls into RSM to retrieve that data the user has permissions to along with what workflows the user is able to access.
If RPM cannot connect to a directory server; the user is not able to log in.
|
Note: RPM never writes data to the LDAP Directory Server. |
For additional information about Oracle Internet Directory (OID), see the following website: http://www.oracle.com/technology/products/oid/index.html
Conflict checking is done in RPM to ensure that rules are followed to avert potential pricing problems. An example of a conflict check includes ensuring that parameters of regular price change, clearance, and/or promotions are not causing the retail value of the item/location to go below zero.
The asynchronous conflict check process in RPM is a mechanism by which applications can execute long-running operations in the background while allowing work to be done simultaneously.
Within the RPM application, asynchronous processing is always utilized in the following functional areas:
Price Changes/Clearances
Promotions
Worksheet
The asynchronous conflict check process is performed as follows.
The client requests the application server to perform a process on a business object or set of business objects.
The server's application service layer extracts information about the request (type of business object, identifying ID, and requested action).
A JMS message is published to the queue that contains specific information about the task.
A record is inserted into the TASK table. The task-specific information about the task is persisted as a Blob in the table. This task-specific information is a Java object that, when read from the database, is capable of calling an RPM application service to perform asynchronous processing and generate an alert when the processing is completed.
As soon as a message arrives in the queue, the container triggers execution of the RPMTaskMDB. RPMTaskMDB is a message-driven been used to facilitate RPM's asynchronous processing capability. Message Driven Beans act as listeners to specified queues for messages.
The task passes information to the application service layer.
The application service layer performs a state transition on the requested business object (for example, approving a particular price change) based on the information passed by the task.
The results of this transition (for example, success or failure messages, conflict details) are recorded in the RPM_CONFLICT_CHECK_RESULT table.
The application service inserts a record into the ALERT table.
The client periodically polls the Alerts application service which looks for new alerts in the ALERTS table.
RPM caches objects within the server in order to reduce repeated creation and loading of frequently accessed information from the database. This strategy helps in reducing database access latency and bottlenecks. The object caches are accessible across requests and users and are configured to be refreshed at configurable time intervals.
RPM caches certain types of business objects and database query results. The business objects that RPM caches are those that are frequently accessed but infrequently changed. RPM sets a cache for each of the following business objects:
System Date (VDATE)
System Options
System Defaults
Divisions
Groups
Departments
Districts
Stores
Warehouses
Suppliers
Partners
Dynamic Codes
Units Of Measure
Zone Groups
Zones
Differentiators
Differentiator Types
Reference Items
Class Hierarchies
Subclasses
Deal Status Codes
Deal Type Codes
RPM also caches results from non-parameterized database queries. Non-parameterized database queries usually happen when RPM needs data that are not of specific criteria. An example would be to retrieve all clearance information for the Clearance Workflow. In contrast, parameterized database queries retrieve data that fall under a specific criteria such as retrieving all clearances affecting a given location.
RPM uses an open-source product called EHCache as a caching framework. EHCache features both memory and disk cache storage options and flexible configuration. Further information about this framework can be found at http://ehcache.sourceforge.net/.
With the exception of the Virtual System Date, the cache for business objects and database query results are configured as follows:
RPM can store in the memory cache up to 10,000 instances within a business object cache and 10,000 database query result sets. If there are more than 10,000 elements to be stored, the overflow is stored onto disk.
A cache is refreshed if they have not been accessed for 3600 seconds.
The Virtual System Date (VDATE) differs in configuration in such a way that there is only one instance of a VDATE within its cache and there is no expiration of that instance.
RPM is deployed using the J2EE-related technologies, coding standards, and design patterns defined in this section.
ACID
ACID represents the four properties of every transaction:
Atomicity: Either all of the operations bundled in the transaction are performed successfully or none of them are performed.
Consistency: The transaction must leave any and all data stores that are affected by the transaction in a consistent state.
Isolation: From the application's perspective, the current transaction is independent, in terms of application logic, from all other transactions running concurrently.
Durability: The transaction's operations against a data store must persist.
Data access object (DAO)
This design pattern isolates data access and persistence logic. The rest of the component can thus ignore the persistence details (the database type or version, for example).
Java Development Kit (JDK)
Standard Java development tools from Sun Microsystems.
Enterprise Java Beans (EJB)
EJB technology is from Sun. See http://java.sun.com/products/ejb/">>http://java.sun.com/products/ejb/. EJB refers to a specification for a server-side component model. RPM uses stateless, session EJBs, which are stateless and clusterable, and which offer a remotely accessible entry point to an application server.
Enterprise Java Beans (EJB) container
An EJB container is the physical context in which EJBs exist. A container is a physical entity responsible for managing transactions, connection pooling, clustering, and so on. This container manages the execution of enterprise beans for J2EE applications.
J2EE server
The runtime portion of a J2EE product. A J2EE server provides EJB and Web containers.
The Java 2 Enterprise Edition (J2EE)
The Java standard infrastructure for developing and deploying multi-tier applications. Implementations of J2EE provide enterprise-level infrastructure tools that enable such important features as database access, client-server connectivity, distributed transaction management, and security.
Naming Conventions in Java
Packages: The prefix of a unique package name is always written in all-lowercase letters.
Classes: These descriptive names are unabbreviated nouns that have both lower and upper case letters. The first letter of each internal word is capitalized.
Interfaces: These descriptive names are unabbreviated nouns that have both lower and upper case letters. The first letter of each internal word is capitalized.
Methods: Methods begin with a lower case verb. The first letter of each internal word is capitalized.
Persistence
The protocol for transferring the state of an entity bean between variables and an underlying database.
Remote interface
The client side interface to a service. This interface defines the server-side methods available in the client tier.
The major components of conflict checking in RPM are performed by PL/SQL and are executed on the database server instead of the application server. As such, performance concerns around conflict checking functionality can be more efficiently addressed. To accommodate conflict checking, a number of PL/SQL package files must be installed on the database.
