The document comes up with the following technical specifications for the appLOAD suite

• Hardware and Software requirements
• Platform Certifications
  • Operating System
  • Application Servers
• System Architecture
• Technical Architecture

Software Requirements

The following are the software pre-requisites for the appLOAD suite.

• J2SE 5 – Java 2 Standard Edition 5 (JDK 1.5.x)
• Oracle 10 g Enterprise Edition
• J2EE Application Server

Hardware Requirements

Server Capacity varies with the quantum of data and transactions. An approximate server configuration would need the following

• Should be a server hardware
• Processor – Dual-Core Intel Core2 Duo processor (2 GHz and 2 MB Cache or higher)
• Memory – 8 GB memory or Higher
• Drives – Hard Disk Drive (HDD) 160 GB

Operating Systems

appLOAD suite can run on the following operating systems

• Oracle Linux 5.5
• Microsoft Windows Server Editions (XP / 2003 / 2008 / VISTA)
• Redhat Linux Enterprise Edition (4.x / 5.x) server
  • Certified by redHat  and runs well with the RHEL server versions as well.

Application Servers

appLOAD suite can run on the following J2EE Application/Web servers

• Oracle Application server 10.1.3.x
• JBoss Enterprise Web Server 4.x and 5.x
• Apache Tomcat 5.5 and 6.0
• Support WebLogic 11.1

Specifics of the Architecture

The Model-View-Controller (MVC) pattern, originally developed to support the Smalltalk language, supports a logical separation between presentation (view), application (controller) and the data (model) layers of the system.
As developers have grown familiar with the J2EE architecture, it has become increasingly apparent that access to the data, or persistent storage layer, through enterprise beans often incurs an unnecessary overhead. This overhead is a result of the transactional support provided through these components. In general, read-only access to data is much more common than transactional (create, update, delete) access.
As a result, non-transactional methods for access to the persistent data layer have been developed. These methods continue to provide the abstraction between applications and data, but don't incur the overhead associated with an enterprise bean approach. Chainsys intended to develop frameworks that implement these data access methods to support access to the persistent data layer without an enterprise bean implementation.(Bulk) Mass updates for EBS
This architecture is based upon the Struts MVC pattern and provides abstractions between the various tiers of the architecture. The dataflow is as follows:
Step 1 – Browser sends request to HTTP server via a URL that forwards the request to the Web application server. Based on the <servlet-mapping> entries in web.xml, the application server passes the requests having matching URL patterns, to the Struts Controller Servlet.
Step 2 – The Struts Controller Servlet matches the incoming request to a Struts Action. Further Struts Controller Servlet based on the action mappings passes control either directly to a JSP or instantiates the Action Form associated with the Struts Action. Struts populates the Action Form using the HTTP request parameters and stores the form bean in either HTTP request or HTTP session based on the form scope.
Step 3 – The Custom Action creates a Value Object (VO) and sets its attributes using data provided within the Action Form. It then calls Business Delegate method with VO as parameter. The Business Delegate serves to abstract the lookup of other resources and the methods accessed by the Custom Action
Step 4 – Business Delegate directs application business logic and calls other business objects to affect the application workflow.
Step 5 – Business Object requiring data access uses DAO Factory. A DAO Factory provides connections to a specific data store and implements retrieval of various DAOs.
Step 6 –DAO Implementation implements DAO Interface and provides interaction with Persistent Data (in some cases) via embedded SQL. For other sources of Persistent Data, this access may include EDI interfaces, XML exchanges or proprietary formats. The getDAO () method of the DAO Factory instantiates a new DAO Implementation object.
Step 7 –DAO object reference is passed to the Business Object.
Step 8 – Object calls CRUD operations on DAO Interface.
Step 9 – DAO Interface abstracts data store request to data store-specific DAO Implementation.
Step 10 – Data Access Object (DAO) accesses Persistent Data through JDBC or data store-specific interface.
Step 11 – Persistent Data is returned to DAO Implementation.
Step 12 – DAO Implementation converts retrieved data into list of VO's.
Step 13 – DAO Interface passes VO list back.
Step 14 – Business Objects passes VO list back.
Step 15 – Business Delegate passes VO list back.
Step 16 – Custom Action places results embedded list of VOs into either the HTTP Request Object or HTTP Session Object depending on whether the information is session-persistent or transactional in nature. The Custom Action returns a "forward" tag attribute value to the Controller Servlet, indicating the next URI to which the flow should proceed.
Step 17 – Controller Servlet identifies and forwards request to the appropriate JSP for the above Custom Action.
Step 18 – JSP assembles HTML page and responds to browser with resulting page.