|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 7
In order that the knowledge represented by design patterns can be effectively utilized and become part of the collective design knowledge, the patterns have to be structured. The whole set of patterns for a specific application domain, together with their structuring principles, becomes a high-level language and a design method for the domain that accompanies the software life cycle.
For its part, the GOF taxonomy includes categories such as creational and structural, with the patterns presented under these categories. This structure has been followed by most current pattern presentations.
In contrast to the GOF taxonomical approach, we'll look at patterns with a pattern language for creating a J2EE framework with the hope that a pattern approach would be more useful for designers and more understandable for developers.
Again, just as a framework is not a collection of classes, a pattern language is not just a loose collection of patterns. The pattern language provides an organization of the decision sequences that generated the framework design, and these must be understood in their proper context by the developer when making new decisions regarding which classes and collaboration structures to add to the framework.
With that in mind, the E++ pattern language extends previous design pattern work and presents, within the J2EE application context, ideas closer to Alexander's idea of a pattern language as a whole design method.
In this series, we'll target an application domain that is a Web-based, large-scale B2C and B2B integration framework implemented in J2EE. We'll employ the following business case to illustrate the E++ pattern language.
Telecommunication Service Provider, Inc. (TSP) distributes telecom services to subscribers and resellers. This fictitious company requires a Web-enabled business application to support order creation, provisioning, fulfillment, deletion of orders, and billing information, as seen in Figure 1.
Figure 1. TSP use cases
Click on thumbnail to
view full-size image.
(5 KB)
Along with providing interactive applications to handle its orders and billing information, TSP wants to integrate the Web application with backend services to automate processes of order provisioning, fulfillment, and banking services to enhance the application's efficiency. The application needs to access remote services through HTTP/HTTPS, CORBA, and RMI protocols. XML should be supported in the process. As business rules change frequently, the company should be able to modify or update the application at runtime.
An application provider, Telecom Soft Co. (TS), will develop the application for TSP. The application will also be used as the basis for a product sold by TS to other businesses within the telecom distribution industry. TS's goal: create an application that is highly flexible, portable, and easily customizable for other clients. Under such conditions, the application framework must comply with object-oriented design principles and patterns to generate a MREPICS solution.