10 J2EE avoid risks listed herein, to ensure the success of the enterprise Java projects: Humphrey Sheil translation: Blueski: This article has been contained in 51CMM website "China System Analyst" magazine third journals. Original text at http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html ----------------------- -------------------------------------------------- ------- In the past period, I served as a process preampl, senior designer, and architect designer, I have seen very good enterprise Java projects, and I have seen bad, and even very. Ugly "project. Sometimes I will ask myself, why can a project succeed, and the other is to fail? It is difficult to define a certain rule or standard to indicate how the various items should succeed, and the J2EE project is not exception. But in contrast, we can find out the failure of the project from all angles and levels. If these risks are well avoided, the project can succeed. In this article, I will raise the top 10 enterprise Java project risk for readers. In a variety of risks, some risks are only delayed the progress of the project, and some bring some unnecessary work, while others will completely eliminate the possibility of success. However, if there is enough preparation and clear understanding, then there is no inevitable thing. This is better if you are a traveler, you clearly know what the front road is in the direction, and have a full preparation, and one knows where there is a dangerous guidance, which will compare the destination smoothly. This article uses the following structure to describe the risk: Risk name: Title of risk (using bold) Project Stage: In which project stage will happen to influence the influence phase: which phase symptoms will affect the symptoms of risk generation : How to avoid risk or reduce the impact of the project to minimize the level: Risk-related supplementary instructions and prompts through careful investigation of enterprise Java projects, this article will decompose J2EE project process into the following phases: Provider selection: Before starting your J2EE project, choose the most appropriate provider, from the application server to the development tool, until the manufacturer of coffee during the work. Design: Without a series of strict specification and software engineering methods, you can start a sufficient design, and then naturally enter the development phase. Before developing, you should consider what is doing well, and how to do it down. In addition, I used some design templates to be confident that all issues and possible solutions have been thought of before entering the development. However, I sometimes do some codes in this stage, sometimes I can answer some questions, effectively determine the performance of performance and module division. Development: It is the program development phase, selects some good development tools, excellent design, etc., will show its superiority at this stage, and can give developments great help. Stability / load test: At this stage, system architects and project managers should freeze product features and put focus in quality and product parameters (allowed concurrent users, fault recovery, etc.). Quality and performance should be sufficient at this stage. Of course, it is best to avoid a lot of modifications to this stage to write poor running code in the pretty stage. Mature period: This is not a real project stage, but a fixed preparation stage.
Past latent errors (from bad design and development, wrong vendors) may also appear and affect your system. Risk 1: There is no truly understanding Java, EJB, and J2EE can be broken down into 3 parts for easy analysis. Description: There is no truly understanding of the Java project stage: development influence stage: design, stability test, maturity period impact on system performance: maintainability, scalability, performance symptom: Repeated development of the function or class in the JDK core API Know some items in the following list (this is just some topic or actual examples): Waste collector (General, Incremental, Synchronous, asynchronous) object can be used in garbage collection - DANGLING REFERENCES inheritance mechanism And its trade-off over-riding and over-loading method why java.lang.string (here you are replaced here) is not good in java PASS-BY reference semantics and semantics of Pass-By values in EJB Comparison use == or use equals () method for nonprimities in the running order of Java threads on different platforms (for example, is a comparison of new threads and local threads) HOTSPOT technology (and why old performance adjustment technology is lowered) HotSpot Optimization Effect) JIT, and when JAVA Compiler is not easy (un installed Java compiler, and your code is run enough enough) API collects RMI circumvention: you need to constantly improve Java knowledge, In particular, understand the advantages and deficiencies of Java. The existence value of Java is far more than a language, understanding platform (JDK and tools, etc.) is also equally important. Specifically, you should be a certified Java programmer. If you are not, you may sometimes be surprised for what you don't know. In addition, you can join Java mailing list. Each company I have added to each company has joined such a list of mailing, learned from a peer to technology, which will be your best resource. Remarks: If you or your team doesn't really understand the programming language and platform, how can you still maintain a successful hope? Strong Java programmers are like EJB and J2EE, just like a duck. In contrast, weaker, no experience, can only develop quality J2EE applications. Description: There is no truly understanding of the EJB project stage: design influence phase: development, stabilization on the system's impact: Maintenance Symptoms: EJB is not used after the first time being called (especially STATELESS SESSION bean) without re-use value EJB does not understand what developers want to do, what EJB provides any EJB without the specification definition (Fire thread, loads a local library, trying to perform I / O, etc.) Solution: To improve knowledge about EJB, you can find a weekend Come to read the EJB specification (version 1.1 is 314), then read the 2.0 specification (page 524!), Which can be understood that 1.0 is not defined in the 2.0 specification to supplement. EJB developers start reading from 18.1 and 18.2, it is relatively appropriate. Remarks: Do not look at EJB from the supplier's perspective, and know the standard EJB model supported by the specification and the difference between the special applications based on these models. This will also help you use it when you migrate. Description: There is no truly understanding J2EE project stage: design influence phase: development of the system impact: Maintenance, scalability, performance symptoms: "Everything is an EJB" design method replaces the container - provided mechanism customization Safety Processing - J2EE Platform In Enterprise Calculation, from represents logic to background, has the most complete integrated security architecture; but it is rarely used.
Solution: Learn the key components of J2EE, and understand their advantages and disadvantages, use them to replace each service; "knowledge is power" here is effective. Remarks: Only knowledge can make up for these issues. A good Java developer will become a good EJB developer, which will also gradually become a master of J2EE. The more Java and J2EE knowledge can be mastered, the more well-design and development work will be. Everything in the design phase will be normal. -------------------------------------------------- ------------------------------ Risk 2: Over-Engineering (using EJB or EJB) Project Stage : Project stage of design: Development of the system: Maintenance, scalability, performance symptoms: too large EJB developers unable to explain what EJB do, and the contact between the contacts cannot be repeatedly used EJB, component or service EJB launched new The transaction, the transaction, this transaction is initiated by an existing EJB to secure, the data separation level is fixed to too high solution: excessive engineering solutions directly come directly from the Extreme Programming (XP) method: Using the smallest design And programming to meet the needs, don't dry it. Unless you need to expressly know that future possible needs, such as future load requirements, or system in the highest load, you must do too much to consider or guess for the future. In addition, the J2EE platform has defined scalability and error recovery, allowing the server system to process you. In the smallest system, only one widget is only one thing, and these components do only one thing. As long as these requirements are achieved, the system stability has been improved, and the maintenanceability of your system It will become very powerful in the future to meet the new demands to meet new needs. Remarks: In addition to the schemes listed above, you can implement design patterns - they can significantly improve your system design. The EJB model itself also uses the design model. For example, the HOME interface of each EJB is the example of the Finder and Factory mode. The EJB's Remote interface plays a actual bean implementation agent and is also critical to the ability to provide containers, which intercepts calls to call the signal and provide services such as transparent load balancing. Ignore the design model is also part of danger. Another danger I often mention that it is: only use EJB to use EJB. A part in your application may not require EJB, or even your entire app is not needed. This is extremely engineered, and I really have witnessed some good servlets and JavaBean applications being refactored to EJB, and do not have a good technical reason. -------------------------------------------------- ------------------------------ Risk 3: Do not separate business rules and logical expressions in the project stage: design impact project Stage: Development of the development of the system: Maintenance, scalability, performance symptoms: too large, no marginal JSP program must modify the JSP when the business logic changes, you need to modify and reconfigure EJB and other background components when you need to change the interface. Avoidance scheme: J2EE platform allows you to separate the logic and navigation control phase, thereby separating the business rules. This is called a mode 2 structure. Note: You can use a consistent design to connect to the user interface frame. (For example, you can use taglib), which will help you avoid logically separation issues. There are many ready-made methods to choose from. Each one is evaluated, and then the most suitable framework is used.
-------------------------------------------------- ------------------------------ Risk 4: There is no appropriate configuration project stage in the development environment: the project stage affecting the impact : Stabilization, concurrency, maturity on the system: Your trade-off symptom: After many days or weeks, it can transition to mature system risk, with a lot of uncertainties, some main function scenes Tested to data and development in the actual system, different data in the test cannot be set up on the developer machine in development, stabilization, and product environments in the product environment: solving the way is faithful in the development environment. Configure the actual environment to allow the development used by the development to be close to the environment you want to implement. If the future environment is JDK 1.2.2 and Solaris 7, do not develop on JDK 1.3 and Red Hat Linux. The same is true for the application server used. Similarly, you have to see the data in the product database and use such data to test. Do not rely on manually created data. If the product data is very sensitive, you have to make it breathable and configure it. The product data that has not been expected in the development will result in damage to the following procedure: Data Inspection Rule System Test Behavior System Components Construction (especially: EJB-EJB and EJB-Database) The most bad thing is that it may also produce an exception, empty Pointer, and you have never seen any problems. Remarks: Developers often put security issues in the stabilization phase began to resolve. To prevent such traps, you can also spend the same time to improve security in business logic. The maturity period is a complex process, which is full of technical issues and non-technical issues. You may be in a big pile of problems you can't think of, this is everything that maturity means. The development and stabilization environment process provides you with more such problems, as well as finding such problems, constantly doing, can greatly reduce risks. The more you do, the more you can understand what is feasible, what is not feasible. You can record engineering issues to avoid the same errors. -------------------------------------------------- ------------------------------ Risk 5: Choose the wrong provider project stage: providers choose the influence phase: design, Development, stabilization / load test, maturity on system effects: scalability, performance, maintenanceability and stability symptoms: developers should use more time to handle tools, rather than very effective Using these tools In order to cope with known and unknown issues, it has to be significantly reduced between different tools (application server and IDE tool, IDE tool and debugger, source code control and synthesis tool) , Etc.) For IDE tools and debuggers, developers often reject them, and promote their favorite tools: To avoid risk 5, you need a good provider choice process, risk 10 circumvention also applies Here. It is truly used to truly use the most appropriate way to be used in the right way. The only way to evaluate a J2EE application is to create a conceptual test for proven that in the test, you need to include your application framework. In fact, you don't want to train and develop after 3 months, and found some bugs during use. Assume that when it is developed to half, I suddenly discovered that your tool set has a problem, then you should know that some tools are more important than others. If your selected application server can't fully satisfy your needs, you have to modify the original settings. If IDE is not good, you need to set the minimum code standard and let developers arbitrarily choose the most effective tool.
Note: To really understand which vendor is the most appropriate for a special task, it is not a one-time decision. You need to continuously track and evaluate this market. For example, I have used four different IDE tools in the past year, depending on what kind of application server, platform, whether to use EJB. -------------------------------------------------- ------------------------------ Risk 6: Don't know your provider project stage: providers choose the influence phase: provider All phases of the selection phase: design, development, stabilization / load test, maturity on the system's impact: maintainability, scalability, performance symptom: Development cycle exceeds the worst prediction of more than 1/3 or more Commerce has provided a feature, but developers re-perform the development avoidance schemes of this feature without knowing: To avoid such risks, you can subscribe to the provider's online resources, such as mailing lists, News group, version information (especially for the bug fixing patch), you can get more harvests from it. Once you have already selected the provider, you will immediately invest in training, and you will start before the project starts. Then, gradually establish awareness and trust in the team. Try to build a few EJBs and deploy it, use your representation layer technology (Swing GUI, JSP, etc.) to call them. If you need to build an development environment, you will have some unnecessary conflicts in achieving project objectives. In fact, I have seen that there has been no construction process: "We have no time." Therefore, these work must be carried out early. Some people will say: "There is no time to provide us in our plan." My answer is: "There is no time to give you time in your plan." Remarks: In J2EE world, each What is the technical compatibility of provider products? Let's take a look at the specific analysis of IBM and BEA. Both support EJB 1.1 in their respective application servers. So, how many similarities have been backed by BEA WebLogic 5.1 and IBM WebSphere 3.5? BEA WebLogic and IBM WebSphere system configuration and management methods are almost completely different. IBM uses a comprehensive GUI environment in WebSphere, and relative, BEA provides a set of command lines in WebLogic. IBM WebSphere communicates with CORBA with IIOP, which is visible to programmers; WebLogic does not have a CORBA constructor at all, and the default use T3 protocol. WebSphere and Visual Age are tight, and WebLogic is independent of IDE. In fact, you can use any development tools almost any development tool. It can be seen that the difference is quite a lot. If you are an expert from an application server, you don't mean that you are an expert from all application servers. This difference is reflected in the aspects of IDE, DEBUGGER, Build tools, configuration management, etc. Experience with a particular tool for a provider, can have some convenience when assessing the provider's competitors. However, do not expect seamless transfer or connection between different products. Therefore, you have to spend enough time to master these tools in proficiency. -------------------------------------------------- ------------------------------ Risk 7: The design is not fully taken into account: the design is subject Project stage: development, load testing and maturity on the system impact: scalability, performance, maintenance symptoms: Unbearable speed slow system to increase the heavy burden on the server side, and cannot be utilized .
Avoidance: focus on the needs of performance and scalability, identify the performance indicators to achieve in the development. If you need 50 transactions per second, your EJB design can only provide 40, then you need to consider alternatives, such as stored procedures, batch, or reconsider OLTP design. To add your providers to come in, they should be very clear from the strengths and weaknesses of their products, and then give you the most direct help. Remarks: This risk and risk 2 seem to have some conflicts. In fact, both of them affect each other. My solution given to risks 2 is that it is only built in absolutely necessary. And to performance and scalability, you have to pre-divide what you must do. If you implement the system requires very strong scalability and uses it as a more critical needs, then you first need to choose a application server with strong cluster support and transaction cache. In addition, you should design the business object as EJB, so that you can take advantage of the server architecture. XP has no problem, you are still only absolutely necessary. I regard this point of view as a method of checking and balancing. We only need the simplest system, which only provides the functions and behaviors that customers need. -------------------------------------------------- ------------------------------ Risk 8: Old Development Process Project Stage: Development Impact Stage: Stable, Mature The impact of the system: maintainability, code quality symptoms: The project plan seems to seem to be similar to the waterfall model: "First graphic design, then develop in a long period of time." Due to the fact that there is a build process, each The subsequibility is like a date with a nightmare is equal to the date of loss development, because nothing is not made in integration, and the integrated test means putting 2 unstable components together, then View the tracking results in the stack. Avoidance plan: Good software methodology will improve your software life. I have mentioned the XP method before you can find a lot of information on this area. Note: JUnit can be used to perform unit testing, and the ANT tool can compile and build. These two tools have good support for XP methods. -------------------------------------------------- ------------------------------ Risk 9: No good architectural method Project stage: development influence stage: development, stabilization, The impact of maturity on the system: maintainability, scalability, code quality symptoms: BUG is found in the core library in the code. There is no log standard - which is difficult to read or analyze it. Poor inconsistent abnormalities. In some sites, we can even see that the error information is directly exposed to the end user, for example, when the user sends a SQLException stack tracking information when his shopping cart, users will then do it? Do you call the database administrator to fix the Primary Key constraint? The following tasks have been developed in a variety of ways, which must be placed in the first batch of objectives designed for any framework. Log abnormal handling and resource connection (database, name service, etc.) Build JSP page Data legitimacy check circumvention: I am a light-backed believers and practitioners. I am in JavaWorld's first article - "frameworks save the day" - is an architecture discussed in the enterprise Java environment. Even if you have already started to develop, consider the architecture is still worth it. Maybe you have to endure the exception handling and log processing brought by the reconstruction, but from the long run, it is worthwhile, so that time saves money. Remarks: Let us think about the different levels of reusability based on component development in the architecture.
The first level is Plumbing, with a reusable ratio of 0.9 or more, that is, 90% of items can be reused. The more detailed service is defined, the lower the reusability ratio. In other words, I need to build a accounting service, but to provide management of these resources and usage so that they can be reused in other 50% projects. But for those projects, you can get these resources, it's great! -------------------------------------------------- ------------------------------ Risk 10: Project Plans and Design Based on market effects, it is separated from technical realism: continuous Newcomers join the Java / EJB development field, not understanding Java's number of people generally more than imagination. Project stage: All phases will be affected, including the selection of providers: all phases will be affected on the system: maintainability, scalability, design quality, code quality symptoms: EjB Just for the convenience of portable processing, it is not necessary to change the product's trial in the life cycle of the project. Do not believe in any person's views outside the project, these people may already have some stakeholders. Don't believe in providers (unless you have already understood), don't believe in white paper. If you want to get recommendations from the real world about the application server, you can get online. You can also download these tools to evaluate, use them to do some prototypes, and run the samples. (Good providers have such a case). Overall, choose the best provider and tool for your project to take time, and you may not have too much time. You can limit the selection range at 3-4 objects and then compare and inspect with a week. Finally, the more satisfactory tools and products are selected. Remarks: If you lack J2EE experience, you may have problems in the previous period of the project. The decision determined in the previous period affects the entire process and then affects the success of the project. A good J2EE consultant will help you choose a good provider and draw a good configuration for design and development. -------------------------------------------------- ------------------------------ just only these 10 risks? 10 is just a specific number, obviously, there is more risks that will exist. Just I can guarantee that if you overcome the risks listed, your project will have excellent performance and have already been successfully found. There is also a need to pay attention, that is, there is no thing that can replace experience and plan. If you have no experience, you must find a way to get and accumulate. Don't train on the side of the project. Before developing, it is best prepared before design, it is best to prepare before design. You can make your team accept the guidance of Java / J2EE consultants and ensure that such guidance can be passed to other team members. Finally, it is necessary to mention the following points: When is the external impact of software engineering for unit testing, when is the integrated test? The design pattern is abnormal. The above 10 risks are the main difficulties that you will face during the development of enterprise Java projects. I also believe that there must be more traps in your journey, but I am more confident is that the risks I mentioned have covered the main problems.
