Title: Stepping into J2EE Architecture and Process Restaurant: BBS Shuimu Tsinghua Station (Fri Apr 26 16:02:08 2002)
This article is transferred from Sidi.com developers developer.ccidnet.com
Summary The Java2 Enterprise (J2EE) platform consists of four key parts: specifications, reference implementation, compatibility test kits and blueprints. The blueprint depicts the best practices and design guidelines for distributed component architecture. This article is based on the Rational Unified Process and the BluePrint sample program to introduce an eight step J2EE development methodology. By reading this article, you can understand the topic of many important J2EE architectures, and can expand and modify this simple way to solve your own business problems. In the commercial world, we use Java2 Enterprise Edition (J2EE) to resolve business issues, develop business software or provide a packing service. If a company wants to build an e-commerce website using multi-layer architecture, usually involves administrators, architects, designers, programmers, testers and database experts throughout the development life cycle. In order for different departments to work efficiently, they often need a software development process. Some classic development processes include waterfall models, fast application development (RAD) and limit programming (XP). This article we will focus on a popular software engineering process, that is, the Rational Unified Process (RUP). RUP provides a strict method for assigning tasks and responsibilities to role. Its goal is to ensure that we have developed high quality software that meet user needs in the expected progress and budget. I use RUP for three reasons in J2EE development. First, RUP is centered on architecture; before the resource is allocated to comprehensive development, it first develops an executable architectural prototype. Second, RUP is iterative and based on component. The architecture baseline typically includes a frame or infrastructure to customize and extend a system without affecting the other parts of the system without affecting the other parts of the system. Finally, RUP utilizes an industrial standard language -uml, visualizing the architecture and components of the modeling system. RUP has four different development phases: initial, refined, constructed, and handed over. However, this paper covers eight necessary activities developed by J2EE from the technical perspective, mainly focusing on the system architecture. 1. Demand Analysis Demand Analysis Description The system should do or should not do what developers and customers can sign a primitive business contract. You can form a functional requirements document using business concepts, domain terms, use cases, and user interface (UI) models. For non-functional needs, such as performance and transactions, you can detail in the demand document attachment. According to the depth of participation project, it is determined to build a high-level UI model on paper or using HTML. Figure 1 shows two use cases in a typical e-commerce system. View Order (ViewOrder) Tell us to log in to the system through the web interface, check the order list, click the link to view the details of a specific order. Increase the AddLineItem, tell us to browse the product list, select the product of interest and add them to the purchase order. Figure 1 Ordering Example 2, object-oriented analysis analyst construction problem domain model: class, object and interaction. Analysis should be independent of technology and implementation details and include an ideal model. Object analysis can help understand the problem and obtain knowledge about the problem area. Because the change of business processes is much slower than the change of information technology, it is necessary to maintain a pure field model that does not contain technical details. These two steps - demand analysis and object-oriented analysis - not J2EE unique; for many object-oriented law, they are very common. Figure 2 shows the high-level object analysis model of a pet store sample program. It illustrates the main concepts we identified from demand analysis cases. We build these concepts into objects and identify their relationships. Figure 2 Higher layer analysis model: The result of the pet shop area demand and object analysis is to provide an entry point for the development of J2EE architecture. To develop architectures, you can choose a vertical component-often transaction, such as order domain object model - object design, implementation, testing, and deployment.
(Longitudinally integrated part, a RUP concept refers to a small part of the system. The starting point is the use of examples shown in Figure 1 and the field analysis model shown in FIG. One longitudinal joint part is a full-featured Miniature systems, including the JSP, intermediate business objects of the UI layer, such as EJB and backend databases, such as EJB and backend databases, can be applied from the experience in the domain to domain objects and as a guide for the object design phase. Figure 3 Detailed object analysis: Order 3, Architecture Specifications After the previous two steps, the business domain issues and demand should be more clear. Now we focus on technical strategies and architectures. Architecture refers to a blueprint for all component combination definition systems: structures, interfaces, and communication mechanisms. We can further divide the architecture into an enterprise-class and application level architecture. Enterprise-level system architecture enterprise system architecture includes hardware and software infrastructure, network layout, development, testing, production environment, and more. It reflects a long-term investment of a company. Before development, you need to assess existing software and hardware infrastructure. If you do not fully support J2EE, add a new component update already existing system. You need to completely assess hardware, including computers, routers, network converters, and network layouts because they all affect the performance and reliability of the system. Figure 4 shows a possible multi-layer network layout. Figure 4 Enterprise Architecture: Network Layout A multi-layer enterprise architecture shown in Figure 4 includes the following main components: a web browser client, may not be an HTTP server in the firewall organized by the client. A web server that is open to the public. It is typically located in a subnet called the DMZ WEB container main representation layer and possible business logic component application container main business logic component relational database management system (RDBMS) and database master data, data logic you use system architectural type dependence The need for security, performance and reliability, also depends on the financial situation of the organization. In the absence of experience, it is also possible to order a simple second-hand computer from a repair shop phone. There are many open source operating systems, web servers, application servers, and database management systems on the Internet. The price of these systems is just a few hundred dollars and a few more all nights. High-end customers like many Wall Street financial institutions may need a system that continuously supports security, high throughput trading and unpredictable network communication. In this case, for fault, it is often necessary to configure the web server and the application server cluster into an N-layer architecture. It also needs to assess software infrastructure, including web servers, security management software, application servers, domain management servers, database management systems, and third-party software components. If you have not purchased an application server, you choose a J2EE vendor will be an important aspect of the evaluation process. It should be noted that different suppliers have different degrees of implementation of J2EE, and some vendors only support old J2EE versions. In addition, some web containers or application containers may be faster than other speeds. In addition to achieving J2EE specifications, many suppliers also sell J2EE infrastructure or framework. It is also very important to choose a stable support for J2EE suppliers. Universal features you can purchase or develop on the system infrastructure include: Transaction Internationalization and Localization Clusters and Object Distribution Applications Performance Measurements and Analysis Communication Workflow Management Inlets and Personalized Management Hiem Communication Protocol Security and Firewall Applications Architecture Application Architecture Refers to a specific project and specification to establish an upper layer of an enterprise system architecture. After the completion of the infrastructure, architects study how to construct a specific application. If your enterprise architecture only supports the old J2EE version, you can upgrade your system first. If the budget or time relationship cannot be upgraded, you must work within the technical range specified by the older version. Although constructing enterprise reuse components is very important, you must first be able to use. The ultimate goal here is to meet the needs of our customers - one project. Architect is not a designer; architecture and design are completely different. An application architecture includes the main structure of the system, architecture design mode, and a framework that can increase the component above. The architecture mainly focuses on non-functional aspects, while design focuses on application business use cases convert domain object model into technical object model. The application architecture is the structure of the project, a special application.
Through application architecture development, you must usually do the application architecture decisions, including: Functional Division, Domains, Software Components to be protected, to be protected, to be developed, how to integrate, how to integrate third-party components Figure 3 Object description how to model domain objects. Using the current Java technology, domain objects can be distributed in a Web container as a developer management persistent object, or in the EJB of the application server or as the Java stored procedure of the RDBMS host. In a pet store blueprint, we design the order object as an entity bean, a detailed object, and a data access object, as shown in Figure 5, and FIG. When you see this, you should realize the importance of the architecture. Why is a domain object in the analysis model map to so many objects? What happens if you change your design? You may have heard of the benefits of EJB, but pay attention to the performance of different suppliers. When a new technology arrives, you need to conduct some research before investing in a comprehensive design. You can often apply the experience of the design and implementation of the domain object model longitudinal joint part to many other domain objects. This is the content of architecture development. Figure 5 Order Object Design Model In the early stage of J2EE, some object-oriented designers try to map domain models into entity beans and transmitted through layer. They contain a good UML map, but the result is because unnecessary network communication makes the system run very slow. There is no architecture development, and there is no clear understanding of a new technology to directly transfer to object design from object analysis.
Architecture deliverable products Since the J2EE architecture is a relatively new topic, there is no good definition for J2EE architects. From the Pet Shop sample program, it is difficult to distinguish between the architecture where to stop, where is the design start. Document with the high-level examination of the application architecture, model - view - control design mode discussions and architectural overview begins. Low-level documents are in the source code. There is no UML map here. Sun's J2EE Enterprise Architect-certified delegation requires all products to use UML. However, the tag only represents a class diagram, a component diagram, and a small number of object interactions. These are far less than J2EE applications in real world. Architecture specifications and processes require at least the following things: a system architecture document describing existing hardware, software, network layout, and other components, a system architecture document describing existing hardware, software, network layout, and other components, a description application main Structure, including all important structural components, application architectural documents with example components and legacy components, if there are other options, describe all design guidance and architectural decisions, explain these decisions and describe new components design guidance. These guiders should capture all important basic determinants, and new component design must consider maintaining system architecture integrity. One running architecture prototype, can assess new technologies; experience the development and deployment of J2EE applications; construct architecture framework; measure performance, scalability, and ease of use to explain risk; you can also prove your method to the project It works. After developing several J2EE solutions, the prototype becomes less important, and a small number of UML maps and some design guidelines may be sufficient. 4. Under the guidance of an object design, the design is designed to scale and modify the results of the analysis. Although the field object modeling in the analysis phase should be independent of technical details, the object design is completely dependent on technical factors, including the type, language type and supplier selection in the architecture development phase. When analyzing, look up at the stars, but in the design phase, you have to work hard. In theory, in order to maintain the basic properties and behaviors of the business object, they should not destroy them unless it is absolutely necessary. Under the guidance of architectural results, the detailed design should explain the specifications of all classes, including properties that must be implemented, their detailed interfaces and pseudo code or plain text descriptions of the operation. Specifications should be in detail to combine with the model diagram, which provides all required encoding information. In many automation software production, we can generate a code framework from an object-oriented figure. Figures 5 and 6 illustrate the high-level and detailed design objects of some domain objects. Note that the stub and the frame (Skeleton) is often invisible in the figure because they are transparent to designers and programmers. I include them in Figure 6 to illustrate the basics of EJB. Figure 6 Object Design Model: Order EJB Detailed Design After completing the detailed object design, you need to complete the object of the domain object - the object-relational map. The reason is that although object-oriented is now very popular, most popular and mature persistent storage is a relationship. In addition, in many cases, the customer's IT infrastructure has reflected investment and preference to commercial RDBMS vendors. Therefore, it is very important to convert a domain object into a relational model or database table. Although there are many container management persistent tools, they cannot replace a good relationship database design. 5. Implementing the implementation of a clear task under a good architecture and detailed design conditions. In addition, because we design and implement the longitudinal joint portion of the architectural prototype phase, the implementation phase should not be more surprised. In many organizations, developers often reach the stage of implementation. Especially when the manager staring at the developer, this situation becomes more serious when it is coded instead of doing things they think that there is a waste of company time. As a result, the UML sketch is drawn no longer or few days, but it is usually tested at the same time or monthly coding while testing your own ideas. Because in this case, all the architectural decisions and design are made in the coding phase, so they often discover the direction of the development of the development after several months.
6. Verify verification includes testing verification systems running and meeting demand according to design requirements. The verification process occurs throughout the development of life cycle. Unit testing, integrated testing and user test itself are very important topics. 7, assembly and deployment component assembly and solution deployment is particularly important in J2EE development. The development and product environment may be very different. If EJB is in the system, you need to use the vendor-specific tool to get the class automatically generated by the container, because, as I earlier, the Web and Application Components Configuration are different for different suppliers. You must also consider whether the system to be deployed contains vendor-specific code implementation. In the scalable architecture, the system structure should be stable but should also support the incremental deployment of new or old components without affecting the entire system. 8, running and maintenance In the final stage, the application has been in the user's hand, you must give them training and documentation. Users will find errors and may require new features. You must appropriately change the management process to handle these situations. You don't have to close a running system for deploying a new component or replacing the old member. The architecture development process knows that many architectures must be made, so we must develop a process for architecture development. For a business, there are usually many application projects, some of them may span for years, and the result is that system evolution contains many cycles. There are many general needs across multiple projects in your field. You should not costly use the scalable and reusable architecture of the previous project cycle in its lifecycle or other project. A common framework for providing similar structures and behaviors for a series of software applications and reusable software architectures is very needed. If it is the first J2EE project, the architecture must be prototype, test, measure, and analyze and scrutinize in iteration. The blueprint provides many good design guidance and practices, and the pet store sample program can be used as a good reference architecture. The most efficient and high quality release solution is to accept and extend the blueprint reference architecture and insert your own business components. The last thing you have to do is to transform the wheels. Accepting a reference architecture on my understanding, the essence of the pet store architecture is the model - view - control and command mode. You can apply these modes to a Web-centered system-centered system. For each domain object, the view is indicated with nested JSP. Controller handles related business events, domain object package business logic, things, and security. We use the portal servlet as the central controller to accept and intercept all the user's actions. It distributes business events to specific call domain objects to change the field object controller for continuous state. Relying on event processing results, the controller selects the next view to be displayed. Below is the main component we can modify and used in most J2EE applications: A, MainServlet: interface B between portal components, web containers, and frames B, ModelupDateListener: Get the interface C, ModelupDatenotifier: When update When the model event occurs, the listener D, RequestProcessor: Processes all requests from MainServlet. E, RequestHandler: Plug and Play Request Processing Component Interface F, RequestHandlerMapping: Contains RequestToEventTranslator: The Center RequestToEventTranslator: The Center Request Processor Request Processing Map Rule Proxy Plug and Play Request Processing Components in accordance with the request.
