| Oracle® Retail Allocation Operations Guide Release 13.2.9 E72187-01 |
|
 Previous |
 Next |
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.
Oracle Retail Allocation utilizes a Java platform because it offers the optimum solution to the challenges presented by the need for database independence. A Java platform solves, for example, RMS version incompatibility issues.
The n-tier architecture of Oracle Retail Allocation allows for the encapsulation of business logic, shielding the client from the complexity of back-end systems. The following diagram, briefly discussed in Introduction, is explained below in detail according to each of the tiers shown in the diagram.
Java Development Kit (JDK)
Standard Java development toolkit from Sun Microsystems.
Java Server Pages (JSP)
JSPs contain embedded Java and JavaScript within an HTML page. To the user, these pages appear in the Web browser as files with a .jsp extension. JSPs are part of Sun's J2EE specification. They compile into servlets and allow for the separation of the user interface from business logic.
Java Servlet
Java Servlets are used for server side Java development, the Java Servlet is part of Sun's J2EE specification.
JDBC
JDBC is a means for Java-architected applications such as Retail Allocation to execute SQL statements against an SQL-compliant database, such as Oracle. Part of Sun's J2EE specification, most database vendors implement this specification.
Naming conventions in Java
Packages: The prefix of a unique package name is 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 lowercased verb. The first letter of each internal word is capitalized.
The GUI is responsible for presenting data to the user and for receiving data directly from the user through the 'front end'.
The GUI adheres to today's thin-client standard. Whereas a 'fat' client can perform significant data validations and business processing on the client side itself, a thin client performs very little processing. Most of the application processing load is handled by the server.
Oracle Retail Allocation utilizes a thin client because of its advantages. First, there are no special requirements for the client-machine except that it can adequately run a browser. Secondly, client machines require little maintenance. That is, there is no need to install applications on each client machine because the application itself resides on a central server. Clients need only the browser to access the application. Finally, because standard HTTP is used, deployment can occur both inside and outside a firewall.
The GUI is comprised in part of lightweight JSPs. JSP technology is a critical piece of Sun's J2EE-initiative.
JSPs are compiled into servlets. JSPs also provide access to middle tier objects.
JSPs consist of JavaScript and standard HTML. They make calls to tag-libraries and contain minimal Java code. This code is located within standard HTML formatting tags. An extension of Java servlet technology, JSPs allow for the separation of the GUI's page layout from the application's content. The look and feel of the GUI is easy to customize, and dynamic functionality is easy to create.
As noted earlier, because the JSP/HTML GUI is 'lightweight' and uses standard hyper test transfer protocol (HTTP), the application can be deployed both, inside the firewall or outside the firewall.
The screen controller servlet controls mappings (request/response) and the navigational control throughout the Oracle Retail Allocation application.
JavaScript is used to handle some non-business rule validations. For example, JavaScript is responsible for the following:
Date-entry validations
Field-length validations
Alphanumeric validations (for example, a US zip code cannot contain characters, and so on)
JSP tag libraries are called for utility purposes. The use of tag libraries enables reusability. In other words, utility code does not have to be duplicated across all JSPs. For example, a paging tag allows pagination on any JSP page that refers to the paging tag. In addition, any changes that may be required can be made in one place.
Broadly speaking, the 'middle tier' consists of a service layer, a business object tier, and a data access tier. Each is described in this section.
The service layer primarily interacts with the GUI by manipulating the data coming from it, as well as handling transaction processing. While not all business objects are impacted by the presence of the service layer, allocation services such as saves or loads pass through it.
Business objects implement business rules. A common business object infrastructure allows for the components to be utilized again and again within an enterprise. The business objects within Oracle Retail Allocation are represented as business objects, which are, in essence, reusable Java classes.
In terms of Oracle Retail Allocation, business objects represent the logic of functional entities. Because the logic is wrapped into a component of software, it may be instantiated repeatedly. For example, in Oracle Retail Allocation, 'item' is represented as business object. Thus, as business object, any type of 'item' in the merchandising system becomes a reusable component.
Note that there is not necessarily a one-one relationship between a business object and a database table.
Business rule validations are handled by server-based middle-tier business objects.
This portion of the middle tier allows for business logic to be separated (physically and in the software) from the application's presentation and database functions. Thus, the data access tier keeps the business logic and GUI isolated from any database issues.
JDBC Protocol and Drivers
The middle-tier talks with the database via the industry standard Java database connectivity (JDBC) protocol. JDBC facilitates the communication between a Java application and a relational database. In essence, JDBC is a set of application programming interfaces (API) that offer a database-independent means of extracting and/or inserting data to or from Oracle Retail Allocation.
To perform those insertions and extractions, SQL code also resides in this tier facilitating create, read, update, and delete (CRUD) actions.
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 Oracle Retail Allocation to reuse the existing connection from a pool. In other words, the application does not have to undergo the connection process for each subsequent connection.
The database tier is the application's storage platform, containing the physical data (user and system) used throughout the application. This tier is only intended to deal with 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.
The data that Oracle Retail Allocation utilizes is located in both allocation-specific tables and merchandising system (RMS, for example) tables. Because Oracle Retail Allocation shares the same schema as the merchandising system (RMS, for example), Oracle Retail Allocation is able to interact with the merchandising system's data directly, in real time.
The following list is a summary of the advantages that accompany the n-tier architecture.
The N-tier architecture has become an industry standard.
The separation of presentation, business logic, and data makes the software cleaner, more maintainable, and easier to modify.
The hardware and software for each of the tiers can be easily scaled.
The look and feel of the application can be updated more easily because the GUI is not tightly coupled to the back end.
Market-proven and industry-standard technology is utilized (for example, JSPs, JDBC, and so on).
Component-oriented modeling promotes the reuse of code, saving development time.
