Content area
Summary - E++, an Alexandrian pattern language, describes the process for creating a J2EE application framework and represents the essential design knowledge of the framework. Compared with a loose collection of patterns, the pattern language provides rules for design patterns to work together to solve a set of related problems. By applying one pattern at a time and following the relationships between the patterns with the pattern language, it leads to high- quality Java applications. The E++ pattern language addresses J2EE platform technology using design patterns. The language describes a J2EE e-business integration framework. Bin Yang, in this first article of two, introduces the pattern language concept and three architectural design patterns, saving detailed design patterns for part 2. (5,300 words)
As explained before, a pattern language initials a collection of co-related design patterns. The E++ pattern language is structured as a tree-like topology shown in Figure 2. Each circle denotes a pattern, with arrows representing the relationships between patterns. Architectural patterns are green-colored to indicate the "beginning" of the language. The pattern language guides the developers through the evolutionary development process from overall architecture analysis to logical and physical design for final implementation. As depicted in the Figure 2, a J2EE application's design results from following the tree network from the root to the leaves. The framework provides mechanisms, abstract classes, and customizable building blocks for the solutions documented by the pattern language. Since most of the design patterns presented here are introduced in by the GOF, their names are given in such way that would remind readers of their GOF references if applicable and, at same time, reflect the application context in the framework.
The REAI (Rule Engine-based Enterprise Application Integration) architecture pattern is the framework to conduct B2B integration services. It leverages the XML DTD design pattern to design its XML schema, the XML Transformer pattern to transfer between different XML schemas so that the sent XML can be understood by receivers, and the E-Security pattern to secure the data transportation if required. The Rule Engine pattern evaluates business rules, then takes actions using the Dispatcher pattern to get remote services. The Dispatcher pattern uses the Proxy Adapter, Remote Faade Wrapper, and Message Broker pattern to establish the actual connectivity. By the way, if adopted as standard of integration, the JCA (J2EE Connector Architecture) could eventually replace the Dispatcher here. Again the Prototype Reality Bridge pattern describes a seamless development evolution from simulation to reality.
Summary - E++, an Alexandrian pattern language, describes the process for creating a J2EE application framework and represents the essential design knowledge of the framework. Compared with a loose collection of patterns, the pattern language provides rules for design patterns to work together to solve a set of related problems. By applying one pattern at a time and following the relationships between the patterns with the pattern language, it leads to high- quality Java applications. The E++ pattern language addresses J2EE platform technology using design patterns. The language describes a J2EE e-business integration framework. Bin Yang, in this first article of two, introduces the pattern language concept and three architectural design patterns, saving detailed design patterns for part 2. (5,300 words)
Different from the GOF's taxonomy approach, the E++ pattern language contains architectural and design patterns, and, moreover, describes the rules for design patterns, working together, to construct a high-quality object-oriented framework. Indeed, the E++ approach proves more consistent with Alexander's original statement that design patterns do not exist apart from a pattern language.
As we'll see in the sections below, the E++ language begins with the Layered Architecture pattern describing why and how to decompose the system and partition functionalities in different subsystems in general. Next, the E-MVC architecture pattern provides a set of patterns for laying out the architecture of the interactive B2C scenario. Further, the REAI (Rule Engine-Based Enterprise Integration) architecture pattern depicts how the application to integrate with backend remote systems based on rule engine in an extensible and local transparency way. Following the architecture patterns are design patterns working together to form the actual framework. Three organization patterns are also introduced to describe how to migrate, deploy and secure the framework in production environment.
Pattern language: a better approach
The first systematic attempt to describe patterns was made by the ancient Greeks, in particular Aristotle about 340 B.C. The efforts resulted in the creation of Aristotelian logic prepositional logic. Indeed, the heart of today's Pentium processor essentially comprises a complex prepositional logic patterns, etched into silicon.
The current design pattern movement draws on the work of the architect Christopher Alexander. He suggests that each design pattern, " ... is a rule, which establishes a relationship between a context, a system of forces which arises in that context, and a configuration which allows these forces to resolve themselves in that context." In an object-oriented programming environment, a pattern indicates a cluster of cooperating objects linked by certain relationships found repeated in a design. Design patterns focus attention on the fundamental role that patterns of relationships between the elements of an architecture have in any design. Application design is tremendously hard work. With design patterns existing in isolation and without correlation, it is always a struggle to integrate the patterns into an actual design project.
In order that the knowledge represented by design patterns can be effectively utilized and become part of the collective knowledge in an application domain, it has to be structured. The whole set of patterns for a specific application domain, together with their structuring principles, becomes a high-level language and is a design method for the domain that accompanies the software life-cycle from the analysis to the final implementation.
The GOF taxonomy includes categories such as creational and structural, with the patterns presented under these categories. This fashion has been followed by most of current pattern representations. Instead of using the current taxonomy, we'll look at patterns with a pattern language for creating an e-business framework with the hope that pattern approach would be more useful for designers and more understandable for developers.
In order to describe the patterns, we use the generally accepted structure with the fields below. Each component within a group is detailed with:
The pattern name</li>
The context in which the pattern applies</li>
The design problem raised by the context</li>
The conflicting forces that must be resolved</li>
The solution offered by the pattern</li>
References to related patterns at lower levels of the language, if applicable</li>
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 sequence of decisions 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 user also benefits from a better understanding of the architecture and design behind the framework.
The E++ pattern language extends previous design pattern work and presents, within the Java Internet (e-business) application context, ideas closer to Alexander's idea of a pattern language as a whole design method. Further, E++ aims at offering a conceptual modeling support to standard J2EE platform.
The electronic commerce problem
The application domain targeted here is the Web-based, large- scale B2C and B2B integration=server framework implemented in J2EE. The application domain by its very nature is a point of Web aggregation of human inputs and heterogeneous remote elements. The following business case is going to be used for explanation of the 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 its e- business; one that provides business processes to support the creation, provisioning, fulfillment, and deletion of orders and billing information.
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, the exchange data between different systems is in XML format. As business rules change frequently, it is required to be separated from application layer and can be modified or updated by non-programmers.
An application provider, Telecom Soft Co. (TS), will develop the application for TSP. This application will also be used as the basis for an application sold by TS to other businesses within the telecom distribution industry. The TS's goal: create an application that is highly flexible, portable and easily customizable for other clients, while providing the functions required by TSP such that TS can easily make future changes. Under such conditions, the application framework has to comply with object-oriented design principles and patterns to generate a MREPICS solution. We'll solve this problem using E++ pattern language.
The use-cases model for the electronic commerce system is depicted in Figure 1. There are three actors, the customer, the supplier and the bank.
Figure 1. TSP use cases
The pattern language in detail and practice
As explained before, a pattern language initials a collection of co-related design patterns. The E++ pattern language is structured as a tree-like topology shown in Figure 2. Each circle denotes a pattern, with arrows representing the relationships between patterns. Architectural patterns are green-colored to indicate the "beginning" of the language. The pattern language guides the developers through the evolutionary development process from overall architecture analysis to logical and physical design for final implementation. As depicted in the Figure 2, a J2EE application's design results from following the tree network from the root to the leaves. The framework provides mechanisms, abstract classes, and customizable building blocks for the solutions documented by the pattern language. Since most of the design patterns presented here are introduced in by the GOF, their names are given in such way that would remind readers of their GOF references if applicable and, at same time, reflect the application context in the framework.
Figure 2: E++ 1.0 pattern language
The problem addressed by the pattern language presented here is that of the design of large J2EE systems made up of layers installed on a distributed environment. The chosen development process is evolutionary, obtained by exploiting transformations, which first map the analysis into a logical design to be locally prototyped, and then map the logical design into a physical design.
When designing such distributed applications for enterprise information systems, you have to decide how to distribute application functionality or responsibility between distributed processing contexts in order to optimize the usage of components and resources involved. This distribution of functionality carries with it numerous ramifications. Indeed, it will affect the way your projects are managed, and how your applications are structured and built. E++ is going to be under extending to leverage the rapid evolution within community of design pattern and Java language. The later version is going to be consistent with early version. Hereafter is work through of the language current version:
Layered Architecture discusses how and why to partition application functionality into tiers, it is a general guideline to arrange large-scale applications. In the light of Layered Architecture, with Model-View-Control (E-MVC) architecture B2C classes and objects can be effectively organized into three major functionality subsystems: Model, View, and Control, which is considered to be a well-established methodology for MREPLICS.
B2C flow
Under the Layered and E-MVC architecture patterns, the Application Mediator of Web layer acts as a mediator of the whole application. It works as a single entry point to the application as suggested by the Layered Architecture. It dispatches user requests to the JSP Template pattern, which produces all the required JSP/HTML files for user- browsing, the Template mechanism is created by combining JSP Tags and JSP Pages. At same time, it forwards users' requests to the Event Processor pattern, the processor interprets gesture inputs to generic Java event for platform independent using the Event pattern, uses Web Update Command pattern to update Web Model Proxy, and delegates the event handling to EJB Facade pattern, the EJB Faade pattern acts as single entry point to the EJBs, which exposes available functionalities to EJB tier and moreover controls and synchronizes concurrent access to the EJB layer.
Next, JSP Tag, an environment-aware JavaBean, usually extracts application-model information from the Web Model Proxy JavaBeans mirroring application-model EJBs, however for read-only access such as catalog browsing, the tag can directly access backend data-access objects to get data with much better performance. The Event pattern is directly based on the Java delegation event model. As such, the Event Processor is the events generator, the Web Model Proxy is the event listener, and the Web Update Command is the event notifier, responsible for registering event listeners and updating them.
The EJB Controller is a stateful session EJB since it keeps unique user session information. All of the method calls usually go through this EJB Controller interface, representing a single entry point. The EJB Controller simplifies the processing and leverages the State Machine pattern to change application state. The State Machine then uses the Model Update Commands pattern to fulfill the processing and create or change the Model EJB, representing the business entity within the framework. Many design patterns can play effective roles here; the model EJB leverages the Transport Object pattern to come up with a traffic effective transportation between layers, and uses the Session EJB Facade for better method-invocation performance and reusability. Further, the Flyweight Object pattern can reduce the number of objects in memory. Moving one, the Data Access Strategy pattern accesses relational databases, while the Data Iterator pattern provides a better way to handle large chucks of data.
B2B flow
The REAI (Rule Engine-based Enterprise Application Integration) architecture pattern is the framework to conduct B2B integration services. It leverages the XML DTD design pattern to design its XML schema, the XML Transformer pattern to transfer between different XML schemas so that the sent XML can be understood by receivers, and the E-Security pattern to secure the data transportation if required. The Rule Engine pattern evaluates business rules, then takes actions using the Dispatcher pattern to get remote services. The Dispatcher pattern uses the Proxy Adapter, Remote Faade Wrapper, and Message Broker pattern to establish the actual connectivity. By the way, if adopted as standard of integration, the JCA (J2EE Connector Architecture) could eventually replace the Dispatcher here. Again the Prototype Reality Bridge pattern describes a seamless development evolution from simulation to reality.
The Migration pattern shows how Web-centric applications can be moved to an E++-recommended architecture. E-Security addresses security related to Internet-based enterprise solutions: confidentiality, integrity, authentication, and nonrepudiayability. E- Cluster provides rules about how to deployment the framework in production.
The Architecture pattern
The Architecture patterns focuses on the overall structure of a system or application: an architecture pattern expresses a fundamental structure-organization schema for software systems. It provides a set of predefined subsystems, specifies their relationships, and includes rules and guidelines for organizing the relationships between them.
Egyptian architects knew that a triangle whose sides have lengths 3,4, and 5 units is right angled, and used this knowledge for constructing right angles as long ago as 2000 B.C. The square columns from the Temple of Luxor are some of those, these splendid right angle facilities hints today's designers that even though the application is complex, the architectural pattern should and can be simple.
Pattern name: Layered Architecture
Context
You have to design a large-scale Java Internet application in a distributed environment.
Problem
How do you arrange application functionality or responsibility between distributed processing contexts in order to achieve more MREPLICS features in general?
Forces
Traditionally, developers draw a UI with an interface-building tool, then write blocks of code that execute application actions in response to user input. Many interactive development environments encourage this sort of code structure, since they emphasize building the interface first and asking questions about functionality later. Some design methodologies emphasize starting with the UI, which all too often solidifies into a final system design. The result: a program organized around UI elements and user actions on those elements, with persistent data manipulation, application functionality, and display code completely intertwined. Developer decided when to invocate function calls and was responsible for the overall structure and flow of control of the program.
Code structured in such a fashion can succeed for small, single- user systems whose functionality requirements change slowly over time. But such a structure proves inadequate for larger, long-term, distributed projects in terms of the MREPICS principals described as follows:
Poor modality: Because of monoclinic fashion and everything depending on everything else, it is much more difficult to achieve modular systems. Indeed, a change to the code anywhere produces side effects everywhere. Unit tests prove difficult too.</li>
Poor reusability: Your code will be less reusable because each component depends on many other components in order to do anything. Dependencies between components make the components less usable in other contexts.</li>
Poor extensibility: When new functional requirements appear, it's difficult to find the code needing changes or extending. New interfaces must be developed from scratch, since the application logic is buried in the code for a different interface.</li>
Poor consistency: More sophisticated applications often require multiple ways to view and manipulate the same data. The result is often similar data calculated or accessed in different ways, resulting in display-value inconsistencies. Even if the displayed data are correct, any change to data display must be updated in multiple places, opening the door for software flaws.</li>
Poor scalability: Distributed systems implemented in this way often perform redundant data accesses, because UI elements individually query for similar information. Also, maintaining consistency between multiple viewers of a shared, dynamic data store proves difficult -- the solution simply doesn't scale.</li>
Not event driven: A Java J2EE application is very different from transitional applications: it is networked and event-driven by nature.</li>
Poor portability: Porting the application can become much more difficult under this scheme. If business-logic code accesses a particular vendor's product (a database, for example) from everywhere in the application platform moves can be next to impossible.</li>
The solution
In our solution, we implement the well-known FTP protocol as a layered architecture starting from the Ethernet. This is considered better practice than implementing the protocol as a monolithic block since it implements conceptually different issues separately -- giving us the inspiration of implementing complex applications in a layered fashion.
From an architectural point of view, partition your system in a number of layers and place them on top of each other such that services of layer N +1 consist mostly of the services provided by layer N or combination of sublayers. This moves us significantly towards a MREPLICS solution because within same layer, all the components work at the same level of abstraction or the same functionality.
As shown in Figure 3, we need to design a complex system to implement a virtual functionality provide_Service() method. Figure 3(a) illustrates how it looks when done in a monolithic programming fashion; components cross talk whenever necessary at coding time. It's difficult to image how to extend the code to provide more functionality, in particular if the programmer responsible left the company. In contrast, Figure 3(b) illustrates the correct way to handle the situation: layer the system and allow components to talk to different layers through a unified interface. For a typical Web application, the usual layers are presentation, application logic, domain, and database.
Figure 3: Layered Architecture
There are many benefits and advantages of a layered architecture, including more freedom and increased flexibility, which leave the designer with more responsibilities. Indeed, they have to design interfaces between layers and to ensure application consistency and availability themselves.
Note that the layer architecture is simple from high-level point of view, however it demonstrates an important object-oriented decomposition principle: it does not prescribe how many layers an application needs to be spitted to and the orders the processing flow through, while very simple, the layered architecture plays very important role in achieving MREPLICS solution.
Related patterns
This pattern was introduced by F. Buschmann et. al., the only slightly discrepancy here is that the original layered architectural pattern requires the current layer solely relay on the immediately sub-layer, we suggest instead the current could have dependences on other sub layers, this become important when one partitions system in terms of functionality.
Pattern name: E-MVC Architecture
Context
After adopting the layered Architecture, in the context of user- application interaction, we want to determine the number of layers needed and establish the control and communication mechanism of the inter- and intra-layers such that the architecture is simple, more MREPICS-compatible, and maintainable over the long term.
The problem
How do we determine the most appropriate number of layers to have a simple but effective control and communication mechanism?
The forces
Compared with traditional computer programs, a Web-based J2EE program must offer a UI for various users with different roles. Indeed, J2EE UI are prone to change, so a UI tightly interwoven via rest of other parts will prove expensive and error-prone.
At the same time, a synchronization issue exists between front and back end; users have to see the real application states changed by the user gestures so that the layered architecture only would not solve the detailed synchronization problem. To solve the problem, we need a more dedicated inter- and intra-layer control and communication mechanism.
Figure 4: E-MVC Architecture Pattern
The solution
E-MVC represents the solution to our problem. The MVC pattern, first introduced in the Smalltalk-80 programming language, defines that an application consists of data, presentation, and control information. The pattern requires that each of these be separated into different objects. The Model (the data information) contains only the pure application data; it has no knowledge about how this data can be presented to a user. The View (the presentation information) presents the model's data to the user, most likely (but not necessarily) in form of a windows-based graphical UI. The View knows how to access the Model's data, but it does not know what this data means or what the user can do to manipulate it. Finally, the Controller (the control information) exists between the View and the Model. It listens to events triggered by the View (or another external source) and knows what action should be executed in response. In most cases, the response calls a method on the Model. Since the View and the Model are connected through a notification mechanism, the result of this action then automatically reflects back to the user in the View.
In our e-business case, for a browser-based Web application, GUI views are completely defined by their URLs. These views are consistent within a certain functionality and their application models are closely related to each other. Therefore, it makes prefect sense to have a functional-level control module. This differs from traditional MVC pattern, which requires each view to come up one control. In our case study, there will be three control models for three different functionalities: B2C, B2B, and TSP administration. In terms of programming structure, the control module is also slightly unique in our approach since it has to be mapped into a composition of component set due to the layered structure.
The model components contain the functional core of the application. They encapsulates the appropriate data, and export procedures that perform application-specific processing. Controllers call these procedures on the user's behalf. The model also provides functions to access its data that are used by view components to acquire the data to be displayed. The change-propagation mechanism maintains a registry of the dependent components within the model. All views and also a selected controller register their need to be informed about changes. Changes to the state of the model trigger the change-propagation mechanism -- the only link between the model and the views and controllers.
Under an e-business scenario, the Control might act as the link between the B2C and B2B portions, it may notifies B2B control components through events and initiated B2B scenario.
View components present information to the user. Different views present the information of the model in different ways. Each view defines an update procedure activated by the change-propagation mechanism. When the update procedure is called, a view retrieves the current data values to be displayed from the model, and puts them on the screen. During initialization all views are associated with the model, and register with the change-propagation mechanism. As mentioned before, E-MVC requires function-based controllers. This Logically ask one View Mediator to handle all the related views for a specific functionality.
Controller components accept user input as events. How these events are delivered to a controller depends on the UI platform. For simplicity, let us assume that each controller implements an event- handling procedure that is called for each relevant event. Events are translated into requests for the model or the associated view. Finally, we'd like to take advantage of Java J2EE component technology to further improve and fine-grain the application in four tiers:
Front-end clients -- usually a Web browser or Java applet or application</li>
Web container -- runs the servlet/JSP container</li>
EJB container -- runs encapsulating business logic</li>
Enterprise information systems -- like database or other business entities</li>
It is pretty simple and self-explaining, the control module spitting self into web server and EJB server because it needs control both the view and the model.
These four layers can benefit your application in numerous ways. First, because of the architecture's simplicity, it is easy to explain and demonstrate where each object's role fits into the big picture. If a designer strictly defines where objects fit within the layers, and the interfaces between the layers, then the potential for reuse of many objects in the system can be greatly increased. It is easy to assign different teams or individuals to the work of coding the layers in a four-layer architectures, since the interfaces are identified and understood well in advance of coding.
Related Patterns Reenskaug created MVC and introduced it to the Smalltalk environment. Buschmann discussed in detail the MVC Architecture pattern.
Pattern name: REAI Architecture
Context
You need to design a B2B integration architecture, which integrates multiple, independent backend services that may use incompatible technologies and needs to remain independently managed. The architecture must determine what method invocations and messages go to what destinations, under what conditions, and what recipients do when they receive them. These rules are subject to changes over time and should be modified by non-programmers.
The problem
How do you architect the application to integrate and automate the processes through a location transparency way? At same time, can the rules of process flows be introduced and modified quickly by non- programmers in a cost-effective, manageable, and changeable fashion?
Force
EAI (Enterprise Application Integration) is a challenging tasks, and, perhaps most difficult of all, the processor in an EAI environment must be able to accommodate heterogeneous systems and applications. Moreover, it must be able to launch each application required in the process flow. Further, it must be able to deliver and receive data in whatever forms the applications can handle. The processor will need the capabilities of message brokers, such as the ability to transform and move data, drive application APIs to gather or distribute data, and so on.
EAI automates these flows, thus completing the business process automation. This doesn't mean eliminating people, whose judgment and adaptability are often critical elements in a production environment. But business process flow and information flow can automatically present to people the information they need and tasks they must address.
The Solution
The REAI architectural pattern can solve this problem using a set of decoupled and interoperating components, resulting in greater flexibility, maintainability, and changeability. As shown in Figure 5, the REAI architectural pattern consists of the following four modules:
Figure 5: The REAI architecture pattern
Tear business process logic out of application objects, complex processes are encapsulated and defined in rule scripts, this way error rates fall, manageability, changeability and less developer intervention have been achieved.</li>
A Rule Engine module dynamically loads a rule engine, so that the application is independent of any specific rule engine implementation. The loaded rule engine executes rules and asserts business actions.</li>
A Data handle layer ensures that when data reaches its destination, the format of data is what's expected. It is quite possible that the backend will use a different data model (traditional data or XML schema). Another functionality is to secure the XML file if such security measures are required.</li>
A B2B Dispatcher registers remote services and locates, adds, and removes exchange and remote services. It also serves as a gateway to available messaging services. Components uses these services should not depend on specific remote system details to guarantee portability and interoperability so that location transparency is also required.
SP]--> Very recently Sun released the J2EE Connector Architecture(JCA) to establish a standard backend integration APIs, if the connector architecture is going to be adopted in major application server vendors and the adapters become commercially available, then the dispatcher is going to be replaced by JCA, however at this moment, the dispatcher is still valuable to help applications to integrate vendor specific backend systems quickly.</ li>
The REAI architecture is a higher-level of abstraction over so- called adapters or message brokers, it provides the following benefits: Works with non-standard adapters or facades of remote services. One can change services or add new ones without modifications to the processing components; Work with commercial messaging services, acting as surrogate to these services. Client do not need to know where servers are located that is they do not depend on any location information. Using EJBs to conduct actually business so that it leverage the existing security and transaction capability of EJB container. When network or remote server failures occur, new servers can be activated at a different network node without any impact to clients. Again J2EE connector architecture is going to try to standardize B2B integration connectivity and make it simpler for developers. It could potentially replace our dispatcher pattern to offer a standard way of integration.
According to experience, REAI should be designed in a way that it can be intervened and controlled by human actors in a quasi-seamless fashion even with automation in default.
Related Patterns Buschmann discussed a broker architectural pattern contains a bridge pattern for possible low level implementations, a client-server dispatcher pattern to forward user requests to server in a location transparent way.
Conclusion
The E++ pattern language is a framework and pattern language for the evolutionary development of e-business systems on the J2EE platform. Many of the problems raised by the current E++ language are similar to problems in other domains, the E++ is expected to be appropriate for solve diverse projects on J2EE technology platform. From the experience gained in the project, E++ possesses the following important advantages:
The framework is well suited for the fast development of prototype, which can then be used to further develop a productive version. Hence, the time lost on coding that is often experienced when using Java language does not occur when a framework like E++ is applied.</li>
It is easy to integrate different applications within a master application. The framework allows the realization of open and scalable system. The J2EE standard component implementation makes the framework truly portable over different operating systems and different application servers.</li>
In Part 2, we will work through E++'s detailed design patterns, so stay tuned.
Resources
Interesting descriptions on the development of human logic:
The Development of Logic, W. Kneale, et al. (New York: Oxford University Press, 1962)
The first pattern language concept:
A Pattern Language, C. Alexander, et al. (New York: Oxford University Press, 1977.)
The applications of design patterns in building city:
The Timeless Way of Building, C. Alexander,(New York: Oxford University Press, 1979.)
The popular GOF book:
Design Patterns: Elements of Reusable Object-Oriented Software. E. Gamma, et al. (Reading, MA: Addison-Wesley, 1996.)
J2EE platform technology:
http://java.sun.com/j2ee
Contains many interesting architecture and design patterns:
Pattern-Oriented Software Architecture A system of Patterns, F. Buschmann, et al. (New York: John Wiley & Sons, 1996)
MVC design info:
The OOram Software Engineering Method: Working with Objects, T. Reenskaug, et al., (Manning Publication Company, 1996)
Sidebar:
Copyright Web Publishing, Inc. May 1, 2001