J2EE
Top 10 risks
Avoid listed herein
10
Big
J2EE
Risk to ensure enterprise
Java
Project success
Author: Humphrey Sheil
Translation: Blueski
Description:
This paper has been published in the 31CMM website "China System Analyst" Journal of China.
Original text
http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
Summary
When you start working to organize an enterprise Java project, you will throw several magic balls back to the same time: the owner relationship processing, the continuous and long design development process, and maintains sound and integrity, and so on. Every "small ball" will bring its inherent risks, some obvious, some are not easy to discover. Despite this, all of these risks can be avoided. The author of this article Humphrey Sheil analyzes 10 risks that threaten the success of enterprise Java projects, and the risk avoidance method is listed.
In the past period, I served as a process preampl, senior designer, and architect designer and other work, visible to an excellent enterprise Java project, and I saw bad, even "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
·
Influence phase: which stage will affect future
·
Symptoms: Symptoms when risk
·
Avoidance: How to avoid risks or reduce the impact of the project to the lowest level
·
Remarks: Risk-related supplements and prompts
Through careful investigation of enterprise Java projects, this article decomposes the J2EE project process into the following stages:
·
Provider selection
: Before starting your J2EE project, choose the most suitable provider, combined from the application server to the development tool, until the coffee 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.
·
Develop
: It is the program development phase, selects some good development tools, excellent design, etc., will show its superiority at this stage, and can be given to development. ·
stability
/
Load Test: At this stage, system architects and project managers should freeze product characteristics 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.
Figure 1 is affected by various reasons
OK, let us enter
TOP 10 Project Risk!
risk
1
:
No truly understanding
Java, EJB,
with
J2EE
This problem can be broken down to 3 parts for easy analysis.
description
: Nothing to understand Java
Stage of project
:
Develop
Impact stage: design, stability test, maturity
Influence of system performance: maintainability, scalability, performance
symptom:
· Repeatedly developed features or classes in the JDK core API
· Don't know some items in the following list (this is just some topics or actual examples):
o Garbage Collector (Train, Generational, Incremental, Synchronous, Asynchronous)
o Object When can be used in garbage collection - DANGLING References
o Inheritance mechanism and its trade-off
o Over-riding and over-loading method
o Why java.lang.string (instead here with the class you wish) is not good
o Java PASS-by reference semantics and semantic comparisons of Pass-BY values in EJB
o Use == or use equals () method for nonprimities
o Operation order of Java threads on different platforms (for example, is a first way)
o Comparison of new threads and local threads
o HotSpot technology (and why the old performance adjustment technology reduces the optimization effect of HotSpot)
o JIT, and when JAVA compiler is not installed, the Java compiler is not installed, you have justified enough)
o API collection
o RMI
Avoidance:
You need to constantly improve Java knowledge, especially in-depth understanding of Java's advantages and deficiencies. 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.
Note
:
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
:
No truly understanding
EJB
Stage of project
:
design
Influential phase
:
Development, stabilization
Influence of the system
:
maintain
symptom
:
· EJB did not use (especially STATELESS session bean) after the first time was called, EJB without repeated use of value
· Do not understand what developers do, what to provide
· EJB does not follow the specification definition (Fire thread, load the local library, try to perform I / O, etc.)
solution
:
To improve the knowledge of EJB, you can find a weekend to read the EJB specification (1.1 version is 314 pages), then read the 2.0 specification (page 524!), Which can be understood that 1.0 is not defined to supplement in 2.0 specification content. EJB developers start reading from 18.1 and 18.2, it is relatively appropriate.
Note
:
Don't look at EJB from the perspective of providers, it is necessary to know the standard EJB model supported by the norm and the difference between the special applications based on these models. This will also help you use it when you migrate.
description
: Nothing really understand J2EE
Stage of project
:
design
Influential phase
:
Develop
Influence of the system
:
Maintenance, scalability, performance
symptom
:
· "Everything is an ejb" design method
· With manual transaction management, replacing the container - provided mechanism
· Safety Processing Custom Way - J2EE Platform In Enterprise Calculation, from the representation logic to the 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.
Note
:
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
:
Excessive design
(Over-engineering)
use
EJB
Not use
EJB)
Stage of project:
design
Project stage
:
Develop
Influence of the system
:
Maintenance, scalability, performance
symptom
:
· Too large EJB
· Developers can't explain what EJB does, and the links therebet
· EJB, components or services that cannot be reused
· EJB launched a new transaction, and the transaction should be started by an existing EJB
· For safety, the data separation level is too high
solution
:
Over-engineering solutions directly from the Extreme Programming (XP) Method: Use the smallest design and programming to meet the needs, in addition to this, 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.
Note
:
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
:
Did not separate business rules and logical expressions
Stage of project:
design
Impact project phase:
Develop
Influence of the system
:
Maintenance, scalability, performance
symptom
:
· Too large, no marginal JSP program
· Must modify JSP when business logic changes
· You need to modify and reconfigure EJB and other background components when you want to change the interface display.
Circumvent
:
The 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
:
A connection with a consistent design can be used to perform the connection of 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
:
No proper configuration in the development environment
Stage of project:
Develop
Project stage
:
Stabilized, concurrent, mature
Influence of the system
:
Your trade
symptom
:
· After a few days or weeks, you can transition to a mature system.
· Risk existence and transition period, there are many uncertainties, some major functional scenes are not tested
· Data and development in the actual system, different data in the test
· Unable to form on the developer machine
· Application behavior is different in development, stabilization and product environment
Circumvent
:
The solution is to faithfully configure the actual environment in the development environment, so that the environment used in the development is close to the environment where you want to implement the product. 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 rules
· System test behavior
· System components construction (especially: EJB-EJB, EJB-database)
The most bad thing is that it may also produce an exception, empty pointer, and the problem you have never seen.
Note
:
Developers often put safety issues in a stable 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 a wrong provider
Stage of project:
Provider selection
Impact stage:
Design, development, stabilization / load test, maturity
Influence of the system
:
Scalability, performance, maintenanceability and stability
symptom
:
· Developers should use more time to handle tools, not very effective use of these tools
· In order to cope with known and unknown issues, no significant system redesign
· It is difficult to integrate 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.
Circumvent
:
In order to avoid risk 5, you need a good provider selection process, and the avoidance of risk 10 is also applicable.
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 truly understand which supplier is most suitable 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 understand your provider
Stage of project:
Provider selection
Influential phase
:
All stages behind the provider selection stage: design, development, stabilization / load test, maturity
Influence of the system
:
Maintainability, scalability, performance
symptom
:
· Developing the cycle used to exceed more than 1/3 of the worst prediction
· The provider has provided a feature, but the developer re-performs the development of the function without knowing.
Circumvent
:
In order to avoid such risks, you can subscribe to the provider's online resources, such as mailing lists, newsgroups, version information (especially the BUG repair patches), 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 not this time for us in our plan." My answer is: "There is no time in your plan to make you don't do this."
Note
:
In the J2EE world, what is the technical compatibility of each provider's product? 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 do you have in BEA WebLogic 5.1 and IBM WebSphere 3.5? 1. The system configuration and management method of Bea WebLogic and IBM WebSphere is almost completely different.
2. IBM uses a comprehensive GUI environment in WebSphere, and relative, BEA provides a set of command lines in WebLogic.
3. 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.
4. WebSphere and Visual Age are tight, and WebLogic is independent of IDE. In fact, you can use any development tools.
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
Seduce
:
There is no sufficient consideration and product performance in the design.
Stage of project:
design
Affected project stage
:
Development, load testing and maturity
Influence of the system
:
Scalability, performance, maintenanceability
symptom
:
· Unbearable speed slow
· The system adds a heavy burden to the server side, and some cluster techniques cannot be utilized.
Circumvent
:
Concentrate concentrate on the needs of performance and scalability, identify the performance indicators to be achieved 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.
Note
:
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
Stage of project:
Develop
Influential phase
:
Stabilization, maturity
Influence of the system
:
Maintainability, code quality
symptom
:
· The project plan seems to seem similar to the waterfall model: "First graphic design, then develop in a long period."
· Because there is no building process, each construction is a nightmare
· The date constructed is equal to the date of loss development, because nothing is
• The previous components are not fully tested separately, and integrated tests mean 2 unstable components together, then view the tracking results in the stack. Circumvent
:
Good software methodology will increase 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 for unit testing, and the ANT tool can compile and build, which has good support for XP methods.
risk
9
:
No good architecture
Stage of project:
Develop
Influential phase
:
Development, stabilization, maturity
The impact on the system:
Maintainability, scalability, code quality
symptom
:
• Using a number of core libraries in the code to find bugs.
· There is no log standard - which is difficult to read or analyze the output of the system.
· 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
· Connection to resources (database, name service, etc.)
· Build a JSP page
· Data legitory check
Circumvent
:
I am a lightweight legacy believers and practitioners. I'm here
The first article on JavaWorld - "
Frameworks save the day "- is an architecture in the Java environment in the enterprise. 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 from the reconstruction But from the long run, it is worthwhile, so that time saves money.
Note
:
Let us think about 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 planning and design is based on market effects, and the technical reality is separated.
Note
: Continuous newcomers join the Java / EJB development field, not understanding Java's number of people generally more than imagination.
Stage of project:
All phases will be affected, including the selection of suppliers
Influential phase
:
All stages will be affected
Influence of the system
:
Maintainability, scalability, design quality, code quality
symptom
:
· Empty technical decision, think that EJB is only convenient for portable processing
· When choosing a provider, there is no trial with the product.
· Replacement tools in the life cycle of the project
Circumvent
:
Don't believe in any person from the outside of 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. Note
:
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 this
10
Neighborness?
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, namely
No things can replace experiences and plans. 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:
· The external impact of software engineering
· When is the unit test, when is the integration test?
· Design Patterns
· Abnormal handling
in conclusion
In general, 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. Finally, let's re-listen to 10 big risks in accordance with priority:
1. There is no truly understanding Java, there is no truly understanding EJB, there is no truly understanding J2EE
2. Over-Engineering
3. Do not separate business rules and logical expressions
4. No proper configuration in the development environment
5. Choose a wrong provider
6. Don't understand your provider
7. There is no scalability and product performance in the design.
8. Old development process
9. No good architecture
10. Project planning and design is based on market effects, and the technical reality is separated.
Finally, let me wish you good luck!
Translation:
I basically did not have done J2EE project, but still have enough courage to translate such an article. In domestic software companies, it may be risky in extreme cases, which does not matter if it is risky. For selection J2EE technology routes, there will be J2EE unique risks, so the risk in this article is often specifically for J2EE projects. In addition, for J2EE projects, we should not ignore the point that its technical risk will be more.
