Cargo Movement Operations System of Outsourcing Project

Requirement
The objective of this outsourcing project is to replace the existing Cargo Movement Operations System (CMOS) with a modern, web-enabled functionally equivalent system using Java, Java Server Pages (JSPs) and Relational DataBase Management System (RDBMS) technology.

Project Background
CMOS supports base-level traffic management and distribution center movement operations. It has been used in Air Force, Army, Navy, and Marine Corps activities around the world. Other unique users also included HQ NSA and DCMA. CMOS provides proven traffic management support to the warfighter both in-garrison and deployed.

Challenges
To complete the CMOS, software developers are facing following challenges:
1.Add Product Tabs To Inbound Surface Cargo Screen
2.Add Tabs To Main Cargo Incheck Screen
3.Main DoDAAC/Delivery Screen Modification
4.Modification of Location Table 
5.Modify inbound detail TCN data screen
6.Modify Hazardous Cargo Template
7.create multi-pack TCN law defense transportation regulation(DTR)
8.Modify Movement Document Creation Process

To enable end-users using this logical system, CMOS must have the following functionalities:

• LOGAIS Interface;
• ARTCMD Interface;
• Select REPSHIP on Closed Consolidation;
• Service Codes and Passenger Manifest;
• SHIPDATA call button for CBL;
• Net Explosive Weight on Truck Manifest;
• CMOS Architecture – Regionalized

Technical features
In sum, the architecture of the redeveloped system uses JSP user interface supported by Struts Java classes (Dispatchers and Action Classes). It communicates with the relational database in turn using the Hibernate Object Relational Mapping framework. Security is controlled by Acegi Security Framework. The new system is “wired” together with the flexibility lightweight framework. The system is event driven, and the engineer tool implements a dispatcher-based architecture built on Struts for event processing, activation of services, and page navigation. 

The Solution
The modernization or target architecture for this system is based on the Model-View-Controller pattern, which provides separate presentation, control, and data modules within an application.  The redeveloped application will be a Java / J2EE server side applications, with clean, documented, readable source of code for Java classes and JSPs, using Struts framework and other reusable code. Struts provide robust application code, including separation of concerns, state management, and more.

Although this application will be redeveloped according to the J2EE standard, the use of session beans and entity beans is entirely optional. In most cases, avoiding these features will result in a simplified architecture, reducing maintenance cost, and possibly performance improvements. Enterprise Java Beans (i.e., session beans and entity beans) do provide programming and performance improvements for a specialized class of web applications, but they are not absolutely necessarily and will not be used in this redevelopment project.
Modernized Application Architecture

The web application consists of four application specific layers:

Presentation Layer 
Provides the user interface and handles input from the user delegating any business processing to the Service Layer. The well known Model-View-Controller pattern provides a separation of concerns and which facilitates good and provides maintenance efficiencies.  The view component is the presentation layer (JSP and associated processing), whereas the model in MVC is the database data and business objects, as well as value objects that provide a summary or composite view of data from one or more business objects.  The primary controller logic is provided by the Struts framework. 
 
Services Layer
Provides an explicit interface between the presentation layer and the rest of the software (i.e. Domain layer and Persistence layer). 
Business Domain layer

The set of objects that represent most directly represent the concepts in the business domain that the software system supports. The processing done by these classes should typically not be specific to the application but encapsulate business policies and other processing that could potentially be applicable across the company or enterprise.

Persistence Layer
Stores and retrieves business objects.

The Model-View-Controller design pattern prescribes a way of partitioning the application's code to keep the user interface (the view) isolated from the business logic (the model). A controller determines that how user requests are routed to pages and what business logic is invoked to process each request.

The combination of JSP pages for the view and servlets for the controller is often called Model 2 and is the currently accepted way to implement MVC architecture in a Web application.

The redeveloped CMOS application implements the MVC architecture by separating user interface from business logic and managing (controlling) the application flow with a controller servlet. Much has been written about MVC architecture, and a full discussion of Struts and MVC is beyond the scope of this document. For more information, please see the J2EE Blueprints on the Sun Microsystems Web site.

Struts is part of the Jakarta Project at the Apache Software Foundation. It is a framework that implements MVC for Web applications. It provides a servlet controller, tag libraries, and form classes that can handle information display in JSP pages, and a configuration file that tells the controller what classes to instantiate to process application data.

A typical Struts application includes the following components:

• JSP pages with Struts custom tags that display text, create forms for data input, and process collections of data for presentation on the page
• ActionForm bean classes that populate forms with data and retain data for future requests
• Action classes that set up data for JSP pages and process user input
• An action servlet that acts as the controller, routing requests to action classes and selecting JSP pages to display
• A configuration file that defines the associations between URLs, action classes, form classes, and JSP pages
• Resource files that contain the text strings for the application and can be provided in several languages

Struts implements MVC in the following fashion. In the Model, the action classes use the request or the session to store application state information. They can instantiate business logic classes to handle application data.  An action class is written for each URL that the controller is supposed to recognize. In the view, JSPs and ActionForm beans display data and forms. ActionForm beans populate form fields with data and retain and validate that data. The data can remain available between requests, while the form can display the previously entered data again.  There will normally be an ActionForm class for each form presented via JSP.

The Controller portion of the MVC design pattern is, of course, the heart of the design problem addressed by Struts. The Struts ActionServlet class (or extensions of it) runs as a server process and processes URLs that it recognizes. It reads the struts-config.xml file to find out which action classes to instantiate and what(which) JSP pages to display for each URL request. The ActionServlet class may be used as-is or it may be extended to provide custom behavior. 

Major Benefits
This project was completed in three months including unit and integrated testing tasks. The stable and efficient Cargo Management System win the high praise for  RayooTech that proves its business model is successfully for the client who needs outsourcing service. It also demonstrates a significant return on investment from low expenditures on a high-quality product.