12.3. The Small Package Application
The FSD was originally organized to handle large items, such as equipment and supplies, not small packages. The FSD agreed to help implement this contract because it realized that its customers send large packages, as well as thousands of small packages (less than 150 lbs.) each year to various domestic and international destinations. Until recently, these customers shipped all their small packages using dedicated terminals with software from FSD's domestic small-package carrier, FedEx.
However, the FSD was concerned about the high cost and lack of flexibility in this process. The FedEx software, which relied on a server at the carrier's facility to handle the entire shipping transaction process, did not give the FSD enough control to ensure that the process conformed to all its business rules, and it did not integrate with its billing system. Moreover, the FSD wanted to be able to select from multiple carriers to handle its international shipments, and installing and maintaining carrier software on multiple dedicated terminals for each of its 3,000 users was prohibitive from both cost and resource perspectives.
Another obstacle was that these small-package shipments, which need to be delivered overnight or within two business days, could not be handled through the FSD's existing Web-based transport application (FAST). The main reason: FAST was developed for the transport of larger items and equipment that used complex bills of lading, which required several days to complete.
While the Small Package application was built from scratch in the sense that it initiated the construction of a new application framework based on J2EE technology, it still leveraged the FSD's existing Sun servers and Oracle and Unidata databases. Furthermore, because the vendors of the existing Web and application servers offered J2EE-compliant versions of their products, the developers were able to make use of the new releases of the already familiar software.
12.3.1. Collaboration with Sun Professional Services
Sun Microsystems has been serving the MTMC since 1997 with hardware and software technology solutions. Soon after the MRM 15 directive was issued in 1997, the Sun Professional Services Java Center assisted the FSD in migrating its FAST system—then a DOS-based systems written in FoxPro—to a system based on Java technology that enabled the use of standard Web browsers. The use of thin clients eliminated the need to install and maintain client software on each desktop, which in turn enabled the FSD to cost-effectively accommodate a growing user base.
In late 1999, the Sun Professional Services Java Center conducted a Java Architecture Assessment of one of the FSD's primary Java applications. Among other findings, the assessment pinpointed that the FSD was spending a great deal of time developing much of its own system-level code—for services such as object caching, distributed garbage collection, for remote method invocation (RMI), lifecycle management, transactions, and so on. These elements were already standardized within the framework of the J2EE-based platform. Sun suggested that the FSD could rely on its J2EE-compliant container vendors to implement these services within their products, freeing the FSD developers to focus on the business logic and the presentation parts of the applications.
Other findings and recommendations of the assessment included the following.
The core business logic, written in Unibasic, could be managed more easily if it were ported to an object-oriented design. This would allow the system to easily evolve as needs and requirements changed.
Some objects within the system were much too coarsely defined and, consequently, were consuming exorbitant amounts of memory within the system, causing the system to require frequent restarts. This could have impaired future scalability as more users began to use the system.
To keep the FSD project moving forward and to prevent project members from becoming completely engaged in maintaining the current system, a more componentized architecture was needed. Such an architecture would provide maximum scalability and flexibility if it were based on open standards and designed as a collection of services. Further benefits would result if the architecture focused on the reuse and abstraction of proprietary implementations.
As technology evolves and requirements change, new interfaces with the host rating and ranking system should be developed. For example, extensible markup language (XML) can be used to design interfaces for the exchange of data between the rating and ranking system and other applications.
Todd Lasseigne, an enterprise Java architect with the Sun Professional Services Java Center, worked with the FSD on assessment and the development of the Small Package application. He sums up the recommendations: “With the goals expressed by the FSD management—scalability, reliability and maintainability, among other things—a J2EE technology-based architecture became the natural choice. J2EE technology would not only inherently provide all of these capabilities but also allow the FSD development staff to focus on the business logic and not the internal plumbing.”
In addition to performing the architectural assessment and delivering the ensuing recommendations, Sun also played a critical role in mentoring the FSD developers on the implementation of the J2EE technology specifications. The FSD was familiar with J2EE technology but had no practical experience and thus needed some guidance in applying the new architecture to the application at hand. “We discussed the use of stateful and stateless session beans and how to integrate the Web tier with back-end services,” recalls Lasseigne. “We also covered concepts in object modeling and object design, such as starting with use cases, creating a high-level object model, and sequence diagrams—essentially introducing a very structured process into their design.” These concepts are the core of the services-driven architecture from Sun, which incorporates elements of the Rational Unified Process (RUP).
To demonstrate the benefits of J2EE technology, Lasseigne turned his attention to the FSD's Spot Bid application, a reverse-auction service that allows freight carriers to bid on ad hoc shipments for the agency. Although relatively simple, the Spot Bid application had been created by copying and customizing the FAST application, and as a result, was becoming difficult to maintain. Every change to the business logic in FAST required an update to Spot Bid.
Using the process inherent to the services-driven architecture, Lasseigne and two FSD consultants created a general-purpose reverse-auction service to serve as a proof-of-concept to the FSD management. “The key was to introduce the concept of services,” Lasseigne explains. “When I design something using J2EE technology, I think of it as a generic service; it's no longer a requirement of a specific application.”
One of the prerequisites to enabling the development of such generic services is a clear separation of services and the infrastructure from the specifics of each application.[1] By applying the J2EE patterns developed by the Sun Java Center, the development team could address the core issues of each problem. This ultimately offered solutions that represented an applicable distillation of theory and practice. These patterns were used to assist in addressing the complicated navigational issues in the presentation tier. The key pattern used was Sun Professional Services' Service-to-Worker pattern. The J2EE platform specifies a clear distinction between the roles of Java ServerPages (JSPs), Java Servlets and EJBs to ensure maximum scalability and ease of maintenance. The Servlets are tasked with handling the initial requests from the Web server and delegating them to the application (business logic) tier; JSPs focus solely on presenting responses to the clienttier; and EJBs, with their associated worker beans and business delegates, are responsible for executing the business logic.
[1] Lasseigne, Todd, “Dynamic Servlet to JSP Page Navigation,” The Java Report, November 2000.
However, a servlet is still faced with the administrative overhead of deciding which worker bean to use to process each request, and which JSP to invoke to present the response. A navigation service fills this role, thus abstracting the navigation from the servlet. As illustrated in Figure 12.1, the navigation service stores the information that matches incoming requests with the appropriate worker beans and JSPs in a database. It uses a caching mechanism to ensure efficient loading of the navigational information into memory.
Figure 12.1. A Typical Navigation Service
With the navigation service in place, the servlet needs to contain only the code necessary to pass on the request to the navigation service. The navigation service returns the relevant information to the servlet, which then invokes the designated worker bean(s) and JSP(s).
The reverse-auction function is one example of a practical implementation of the navigation service concept. Another example is a user login service. And as Lasseigne explains, one generic service can be embedded within another. For instance, the login service can be used by the reverse-auction service.
Because they make use of stateful and stateless session beans, supported by the J2EE-based platform specifications, these generic services can reside anywhere on the enterprise network, where they can be accessed by any application that requires them. Consequently, they don't need to be maintained separately for each application.
As a result of the successful prototype, the FSD gave the go-ahead to build the Small Package application on the basis of a fully compliant J2EE-based architecture, enlisting Sun Professional Services to assist in design and implementation. “The dot-com consultants from Sun Professional Services did a fantastic job of helping us to architect and integrate an extensible infrastructure,” says Lieutenant Colonel Abercrombie. “This architecture not only enables us to leverage our existing systems, but also positions us for future innovation.”
12.3.2. Solution Analysis
The solution analysis for the Small Package application follows two scenarios, a use scenario and a transaction scenario.
Use Scenario
The following scenario illustrates a typical transaction that a user would perform on the Small Package application.
1. |
A user logs on to the system through a log-on screen on a secure FSD Web page. |
2. |
Once the user's identity and authorization are verified, the system presents a form in which the user can enter the details of a new shipment, or reuse the information from a previous shipment sent to the same location. |
3. |
The system stores the information in a database and concurrently transmits the information to the carrier, which returns a confirmation number and a shipping label. |
4. |
At this point, the user can decide to either cancel the transaction or complete it. If the user cancels the transaction, the system notifies the carrier, the carrier confirms the cancellation, and the system sends a cancellation notification to the user and then presents the user with the option of creating a new shipment. |
5. |
If the user decides to complete the initial transaction, the system stores the transaction details in a completed-items database. The carrier, which already has the shipping request, will proceed to schedule pick up and delivery of the package. Meanwhile, the user can print out the shipping label and attach it to the package. |
6. |
Once a day, the system collects all the completed transaction data and applies a bundling discount to groups of packages addressed to the same location. This is in accordance with the FSD's contract with the carrier. After the discount is applied, the payment information is sent by file transfer protocol (FTP) to a Unidata database in the FSD's host system. The host system creates an EDI transaction which the FSD uses to pay the carrier. |
This is a description of the major functionality provided by the first-phase implementation of the Small Package application. Currently, the application provides domestic shipping through FedEx only. Future phases of the application will enable selection of carriers for domestic and international shipments.
Architecture
The Small Package application consists of four logical tiers—client, Web, business logic and databases (see Table 12.1).
The client tier consists of numerous clients running Netscape version 4 or higher or Microsoft Internet Explorer.
The Web tier, which accepts requests from iPlanet Web Server 4.1, runs on the FSD's existing cluster of four Sun Enterprise 4500 servers. This tier consists of the following objects.
Controller servlet (called the generic controller)— handles all the incoming requests from the Web server.
Navigation service— generates a generic controller that determines for the servlet which worker beans and which JSPs to invoke based on the incoming request.
JSPs— handle the dynamic presentation for the outgoing requests.
Figure 12.2. Three-tier Architecture for the Small Package Application
| Hardware |
|
| Software |
|
| Services |
|
Session objects— provide the JSPs with information they need from the worker beans. (Because the JSPs contain pure presentation logic, they cannot call any business logic within the system.)
Worker beans— serve as an interface to the business-logic tier.
Helper classes (also referred to as business delegates)— provide the worker beans with appropriate access paths to the EJBs.
The business-logic tier runs on the same server as the presentation tier and consists of the following objects contained in BEA WebLogic Server 5.1.
EJBs (stateful and stateless session beans)— contain the application's primary transaction-related business logic.
Domain objects— Java classes defining each of the entities participating in the shipping transaction process.
Data-access objects (DAOs)— contain the SQL code that defines how the domain objects access the databases. In this way, the system hides the data-access methods from the domain objects. The data-access layer is highly granular, containing separate DAOs for each domain object, for each database. This allows the FSD developers to redefine domain objects or create new ones, without affecting the database access code for the other objects. It also allows the developers to reuse the Oracle and Unidata DAOs, which were created for the FAST system, in the Small Package application. Finally, the segmentation makes it relatively easy for the FSD to switch databases in the future, with minimal impact on the application.
FedEx Ship— the shipment service package from FedEx, with a Java API wrapper that enables it to be called from within the Java application. Similar packages from other carriers will be added in the future.
The database tier consists of Oracle and Unidata databases running on a cluster of two Sun Enterprise 6000 servers supported by 10 Sun StorEdge arrays for backup and recovery.
Transaction Scenario
The following is a partial description of what happens within the system in a typical user interaction, as described in the use scenario above. A package shipping transaction begins when a user logs into the system from a standard Web browser, as shown in Figure 12.3. The initial HTML screen presents the user with a choice of tasks. We'll assume the user elects to create a new package by clicking on the appropriate menu item. The request is posted to the servlet, which takes the incoming request and forwards it to the navigation service.
Figure 12.3. A New Package Request Transaction in the J2EE Technology-based Application
The navigation service looks at two hidden fields within the incoming HTML request: the ToScreen and the FromScreen (See Table 12.2). The FromScreen field tells the navigation service where the user came from within the application, and the ToScreen field tells the navigation service where the user wants to go. Using these fields, the navigation service finds the appropriate worker beans for the specified screen. The navigation service then passes control back to the servlet, providing an object called a generic controller, on which the servlet invokes its call process request.
The generic controller knows that every incoming request involves two steps: (1) saving the information from the incoming screen, and (2) loading information for the out-going screen. For step one, it retrieves the same worker bean that the navigation service found and invokes the process incoming on the associated worker bean, passing on the ToScreen and FromScreen variables. Based on these variables, the worker bean determines which services to access on the business-logic tier.
| SAVE | ||||||
|---|---|---|---|---|---|---|
| ToScreen | FromScreen | Role | Worker Bean | Error JSP | Order | |
| ListScreen | LoginScreen | User | Com.sun.exampleWB | ListError | 1 | |
| ListScreen | LoginScreen | User | Com.sun.example2WB | ListError | 2 | |
| MainScreen | ListScreen | User | Com.sun.example3WB | MainScreenError | 1 | |
| MainScreen | ListScreen | Admin | Com.sun.example4WB | MainScreenError | 1 | |
| LOAD | ||||||
| ToScreen | FromScreen | Role | Worker Bean | Success JSP | Error JSP | Order |
| ListScreen | LoginScreen | User | Com.sun.loadListWB | List | ListFailure | 1 |
| MainScreen | ListScreen | User | MainMenu | MenuError | 1 | |
| MainScreen | ListScreen | Admin | Com.sun.mainWB | MainMenu | MenuError | 1 |
The worker bean prompts the business delegate it needs to access these EJBs and then invokes the appropriate EJB to call that service.
The EJB recognizes the request to create a new shipment and passes the new shipment arguments to the DAO for that user. The DAO accesses the Oracle database to get a new shipment ID and returns it in a domain object to the EJB (most likely a stateful session bean).
The EJB then returns control to the worker bean, across the tier, which may or may not serialize that domain object, depending on the method signature (that is, pass the shipment domain object back to the worker bean). The worker bean then stores that shipment ID (the shipment object) in the HttpSession object.
It's now time for step two—displaying the next screen the user needs (specified by the ToScreen field). In this case, that means getting the shipment details of the new package. The generic controller invokes the appropriate load information JSP, which accesses the session object, pulls out the shipment ID that was just created and creates an HTML screen that displays the shipment ID and requests the address information for the package.
The user fills out and submits the HTML form. When the servlet receives the HTML and forwards the request to the navigation service, the generic controller calls out a new worker bean, which initiates the same kind of process as before, putting the appropriate information back into the session object and then returning control to the servlet.
Figure 12.3 represents a componentized approach to a service-based architecture. A distinct separation of responsibilities allows for a clear understanding both of the system structure and the transactional flow, which proceeds as follows.
1. | The servlet handles the incoming request. |
2. | It passes the data to the worker bean, which then does the low-level syntactical validation. The worker bean holds the data pertaining to the business services available to it, as well as the process workflow. |
3. | The worker bean requests the use of these services via the business delegate. |
4. | The business delegate is responsible for abstracting out the network communication necessary to use the EJB services. |
5. | The business services have the ability to process the request, by working in conjunction with service beans to handle the business logic. |
12.3.3. Benefits
As the first organization in the DoD to comply with the DISA specification, the FSD is demonstrating several positive results of implementing a J2EE technology-based architecture.
Operational Benefits
Improved productivity. Using the J2EE technology-based system-level services provided by the BEA WebLogic Application Server, the Small Package application exhibits high performance, enabling the users to complete a new shipment transaction in three minutes, with 700 concurrent users online. Overall, the FSD expects the Small Package system to handle 10,000 shipments per day.
Freedom in carrier selection. The Small Package application accommodates interfaces to multiple carriers through a single Web-browser-based interface. This cuts costs by up to 70 percent by eliminating the need to install dedicated terminals for each carrier, or alternatively, by no longer being locked into a single carrier. This also strengthens the FSD's control over its shipping processes.
Ability to expand user base cost effectively. Through the use of thin clients, the FSD estimates that it will save up to 60 percent annually on the cost of client software upgrades and distribution. In effect, client software maintenance will no longer be a cost consideration in the deployment of future applications.
Rapid return on investment. Rolled out in Fall 2000, the Small Package application enables 700 concurrent users to schedule and manage 10,000 daily shipments. Through these productivity improvements, the reuse of the application's components in other applications, and the ensuing reduction in application development time, the FSD estimates it will achieve a 100 percent return on its investment in the Small Package application within 18 months. Additional returns will be achieved when the Small Package system is enabled for multiple domestic and international carriers.
Lieutenant Colonel Henry Abercrombie concludes, “As a result of Sun's technologies and services, the tremendous relationships we have built with our industry partners and the instructions we receive from the top, such as MRM15, we are achieving our goals and conducting business the way it will be done in the future.”
IT Benefits
Use of J2EE technology for application development provides a number of benefits to IT professionals.
Better utilization of development resources and freedom in vendor selection. EJB developers don't need to worry about creating or maintaining system-level infrastructure services. These services are provided by any J2EE-compliant container vendor, allowing the FSD developers to concentrate on specific application functionality. Further, since the FSD can rely on the fact that all J2EE-compliant containers will provide at least a minimal set of infrastructure services, the organization is not locked into a single vendor. The need for this type of flexibility should provide an impetus for container vendors to update their products to the J2EE technology specifications and motivate developers to upgrade their existing container products to these J2EE-compliant versions.
Improved application performance. The J2EE technology-based platform, because it reduces, rather than increases, the proliferation of coding, improves application response times and transaction reliability.
Reduced time to market. Thorough documentation and adherence to the principles of the J2EE platform—especially the separation of tiers using the SunConnect Solutions Stack Architecture—provided two main benefits. First, it enhanced developer productivity by minimizing the complexity of the evolving code and making testing easier. The architects were able to reuse up to 50 percent of the business logic. Second, it mitigated the effects of staff turnover. The FSD's Small Package project experienced a complete turnover of its two-person team in mid-project, yet the new team was able to get up to speed and complete the entire project in an aggressive three-month time frame. Lasseigne estimates that the Small Package application would have taken five to eight months to complete, or as much as 66 percent longer, using the previous development approach under the same conditions. The reuse of generic services developed for the Small Package application is also expected to help reduce the development cycle time for subsequent FSD applications by as much as 50 percent, and these new applications will be completely independent of changes in the Small Package application.
Easier and less costly application maintenance. As previously noted, the J2EE-based architecture, and the navigation service created by Sun Professional Services, are making it easy to enhance, modify, and scale the initial Small Package application. For example, adding new carriers will require only the addition of the appropriate third-party APIs and minor screen changes to add the new carrier selection to the screens. It will not require any changes in the overall business logic. Alternatively, if the FSD wants to enhance the user interface, modifications to the JSPs need not affect any other part of the application. Database changes will also have minimal impact on the application, as the only development effort would be the creation of new DAOs. And because each of these updates can be made by developers who don't need to be familiar with the entire application model, the FSD can complete these upgrades quickly and, likely, at a lower cost.
| Technical Process Area | Nature of Benefit | Actual Result |
|---|---|---|
| Application development | Enhanced productivity | Up to 25 percent reduction in development time and reuse of 50 percent of business logic; up to 50 percent reduction in future development cycles |
| Site performance | High performance, scalability | Depending on transaction type, delivers three-second response time on average; support for up to 700 concurrent users scheduling and managing 10,000 packages daily |
| IT operations | Reduced costs, improved productivity | Able to avoid future client software upgrades through thin client, resulting in 60 percent reduction in IT costs |
| System integration | Reduced costs, cost avoidance | Able to integrate with disparate systems from multiple carriers to seamlessly connect front-end Web transactions with disparate back-end legacy systems |
On this note, Barnhill comments, “We have a clear migration path into the future and can grow our platforms to meet the coming data demands of our customers. And because our team was able to meet our deadline for the Small Package application, we have gained significant credibility with the Office of the Secretary of Defense and our customers.”
For more information about Sun Professional Services, visit http://www.sun.com/service/sunps/jdc. For more information about USMTMC, visit http://www.sarda.army.mil/peo-pm/usmtmc.htm.