A Real-World Application Model


The preceding simple application is clearly a toy, not meant for deployment. Still, a real application should follow the same MVC pattern demonstrated by the simple application. Now, let’s look at how to modify some aspects of the toy to create a more realistic e-commerce application.

The grocery application implemented its model by using the BasketBean class. The BasketBean illustrates two qualities of toy software: it “hard codes” its data, and it fails to define a standard interface. Such flaws limit the maintainability, extensibility, and scalability of an application.

A production application should define a standard interface for accessing the application model. An interface establishes a contract allowing different implementations to be “plugged-in” as required. Such “pluggable” implementations illustrate the bridge pattern. The purpose of the bridge pattern is to decouple abstract functionality from any specific implementation of the functionality. For example, the inventory data is initially stored as static information imbedded in Java code[2]. To gain flexibility, you might pull this data out of code and store it on the file system. As data volumes grow, a common requirement is to move data storage into a relational database management system (RDBMS). If the BasketBean implements a standard interface, then you can reimplement this interface to use a file system or an RDBMS without rewriting the CustomerServlet.

Real-world applications may also require the separation of data from code. Data changes often, but code should rarely change. A minimum requirement for moving the sample application into a production environment would be to split its model into separate data access and data management tiers. This two-tier architecture allows data volumes to grow without affecting code. Figure 7.4 shows the design after separating data from data access and after defining a standard interface[1].

click to expand
Figure 7.4: Programming for the real world; production applications should define a standard interface for accessing the application model and split the model into a data access and data management tier.

Often, scalability or data transaction requirements force introduction of a third tier into the data management architecture. Common Object Request Broker Architecture (CORBA) or Enterprise JavaBean (EJB) interfaces to data management services are now common. If the BasketBean implements a standard interface, then you can reimplement it as a distributed service. Figure 7.5 shows this three-tier implementation of the application model[1].

click to expand
Figure 7.5: Three-tier data management production applications sometimes require a three-tier architecture for data management.

[2]Vacca, John R., The Essential Guide to Storage Area Networks, Prentice Hall PTR, 2001.




Electronic Commerce (Networking Serie 2003)
Electronic Commerce (Charles River Media Networking/Security)
ISBN: 1584500646
EAN: 2147483647
Year: 2004
Pages: 260
Authors: Pete Loshin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net