Enterprise Operation: 10 major risks of the J2EE Project

Avoid the top 10 J2EE risks listed in this article and ensure the success of enterprise-level Java Projects
Author: Humphrey sheil

Translation: blueski

Note:
This article is published in 3rd Journal of China System Analyst, 51cmm website.
Original inHttp://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html

--------------------------------------------------------------------------------

In the past period, I have worked as a programmer, senior designer, architecture designer, and so on. I have seen excellent enterprise-level Java projects, and I have also experienced poor experiences, it is even an "ugly" project. Sometimes I ask myself why one project can be successful, but the other is failing? It is difficult to define certain rules or standards to show how different projects should succeed. J2EE projects are no exception. On the contrary, we can examine the causes of project failure from various perspectives and layers. If these risks are well avoided, the project can be successful. In this article, I will propose the top 10 enterprise-level Java project risks for your reference.

Among all kinds of risks, some risks only delay the progress of the project, some bring unnecessary work, and others will completely eliminate the possibility of success. However, if you have enough preparation and a clear understanding in advance, there is no unavoidable thing. This is like if you are a traveler, you know the direction of the road ahead, you are fully prepared, and you have a clear guide to know where there is danger, in this way, you can reach your destination smoothly.

This article uses the following structure to describe risks:

Risk name: Risk title (in bold)
Project phase: the project phase in which risks will occur
Impact stage: Which stages will be affected in the future
Symptoms: symptoms at risk occurrence
Solution: how to avoid risks or minimize the impact on the project
Remarks: risk-related supplementary instructions and tips
Through a careful investigation of enterprise-level Java projects, the J2EE project process is divided into the following stages:

Provider Selection: Before starting your J2EE project, you must select the most suitable provider, from the application server to the development tool combination, until the coffee provider that you enjoy during work.
DESIGN: under the premise of complying with a series of strict specifications and software engineering methods, you can start to carry out adequate design, and then naturally enter the development stage. Before development, you must carefully consider what you are doing and how to proceed. In addition, I used some design templates to make sure that I had thought of all the problems and possible solutions before entering the development stage. However, I sometimes do some coding at this stage. Sometimes I can answer some questions to effectively identify performance and module division issues.
Development: in the stage of program development, some good development tools are selected and well-designed. At this stage, the advantages of these tools are displayed and can be of great help to development.
Stability/load testing: At this stage, System Architects and project managers should freeze product features and focus on quality and product parameters (number of concurrent users allowed, fault recovery status, and so on. Quality and performance should be paid enough attention at this stage. Of course, it is best to avoid writing poor code that runs slowly in the previous stage and make a lot of modifications at this stage.
Maturity: this is not a real project stage, but a fixed preparation stage. Previous Latent errors (from poor design, development, and vendor selection) may occur and affect your system.

Risk 1: do not really understand Java, EJB, and J2EE

This problem can be divided into three parts for analysis.

Description: I didn't really understand Java.

Project Phase: Development

Impact stage: design, stability testing, and maturity

Impact on system performance: maintainability, scalability, and performance

Symptoms:

Features or classes in JDK core APIs are developed repeatedly.
Some items in the following list are not understood (this is just a topic or an example ):
Garbage Collector (train, generational, incremental, synchronous, asynchronous)
When the object can be garbage collected -- dangling references
Inheritance mechanisms used and their trade-offs
Over-riding and over-loading methods
Why does java. Lang. String (replaced by your favorite class here) provide poor performance?
Comparison between the pass-by reference semantics in Java and the pass-by value semantics in EJB
Use = or the equals () method for nonprimitives
The running sequence of Java threads on different platforms (for example, whether it is preemptive)
Comparison between new thread and local thread
Hotspot technology (and why the old performance tuning Technology reduces the efficiency of hotspot optimization)
JIT, and when the good JIT gets worse (uninstalled Java compiler, and your code runs well enough)
API collection
RMI
Solution:
You need to constantly improve Java knowledge, especially to gain an in-depth understanding of Java's advantages and disadvantages. The value of Java is far more than just a language. Understanding platforms (such as JDK and tools) is equally important. Specifically, you should be a certified Java programmer. If you are not a Java programmer, you may be surprised at the fact that there are so many unknown content. In addition, you can add the Java mail list. Every company that I joined previously has added such a list of emails. It is your best resource to learn the technology from your peers.

Note:
If you or members of your team do not really understand the programming language and platform, how can you maintain the hope of success? A strong Java programmer is like a duck to water in EJB and J2EE. On the contrary, less experienced programmers can only develop poor J2EE applications.

Description: I didn't really understand EJB.

Project phase:
Design

Impact phase:
Development and Stabilization

Impact on the system:
Maintenance

Symptoms:

EJB is not used after the first call (especially stateless session bean)
EJB with no reuse Value
I don't understand what developers need to do, what containers provide
EJB is not defined in accordance with the specification (Fire thread, loaded local library, tried to execute I/O, etc)
Solution:
To improve knowledge about EJB, you can read the EJB specification (1.1 page for version 314) over the weekend, and then read the 2.0 specification (524 page !), In this way, we can understand what is added in the 1.1 specification, which is not defined in 2.0. It is appropriate for EJB developers to read from chapters 18.1 and 18.2.

Note:
Do not look at ejbs from the provider's perspective. Be sure to know the differences between the standard EJB models supported by the specifications and the special applications based on these models. This will also help you migrate data to other providers.

Description: J2EE is not really understood.

Project phase:
Design

Impact phase:
Development

Impact on the system:
Maintenance, scalability, and performance

Symptoms:

"Everything is an EJB" Design Method
Replace the container-provided mechanism with manual Transaction Management
Custom Security Processing-the J2EE platform has the most complete integrated security architecture in enterprise-level computing, from presentation logic to background processing. However, it rarely uses all of its functions.
Solution:
Learn the key components of J2EE, understand their advantages and disadvantages, and replace each service with them in sequence. "Knowledge is power" is effective here.

Note:
Only knowledge can make up for these problems. Good Java developers will become good EJB developers, and should gradually become masters of J2EE. The more java and J2EE knowledge, the better the design and development work. Everything will be well organized in the design phase.

--------------------------------------------------------------------------------

Risk 2: over-engineering (using EJB or not using EJB)
Project phase:
Design

Affected project phase:
Development

Impact on the system:
Maintenance, scalability, and performance

Symptoms:

Too large EJB
Developers cannot explain what ejbs are doing and how they interact.
EJB, component, or service that cannot be reused
The EJB starts a new transaction, which should have been started by an existing EJB.
To ensure security, set the data separation level too high
Solution:
The solution to over-engineering is directly from the extreme programming (XP) method: To meet the needs with the smallest design and programming, there is no other way to do it. Unless you need to clearly understand the future requirements, such as future load requirements, or the performance of the system under the highest load, you do not have to worry too much about or guess the future situation of the system. In addition, the J2EE platform has defined features such as scalability and error recovery, so that the server system can handle them for you.
In the smallest system, only small components are included. These components only do one thing. As long as these requirements are implemented, the system stability has been improved, the maintainability of your system will become very strong, and it will be easy to add new functions to meet new requirements in the future.

Note:
In addition to the solutions listed above, design patterns can be promoted-they can significantly improve your system design. The EJB model is also widely used in the design mode. For example, the home interface of each EJB is an instance in the finder and factory modes. The remote interface of EJB acts as a proxy of the actual bean implementation and is crucial for providing container capabilities. These containers intercept call signals and provide transparent APIs) server Load balancer service. Ignoring design patterns is also a dangerous part.

Another danger I often mention is that EJB is used only to use EJB. A part of your application may not need ejbs, or even your entire application. This is the extreme of over-engineering, and I have indeed witnessed some good Servlet and JavaBean applications being restructured into ejbs, and there is no good technical reason for doing so.

--------------------------------------------------------------------------------

Risk 3: business rules and logical representations are not separated
Project phase:
Design

Affected project phase:
Development

Impact on the system:
Maintenance, scalability, and performance

Symptoms:

Too large and non-marginal JSP program
When the business logic changes, you must modify the JSP
Modify and reconfigure the EJB and other background components when you need to change the interface display.
Solution:
The J2EE platform gives you the opportunity to separate the representation logic from the navigation control, and thus be isolated from the business rules. This is called the Pattern 2 structure.

Note:
You can use a consistent design to connect the user interface framework. (For example, you can use taglib), which helps you avoid the problem of logical separation. There are many good options available. Evaluate each of them separately and then adopt the most appropriate framework.

--------------------------------------------------------------------------------

Risk 4: no proper configuration in the Development Environment
Project phase:
Development

Affected project phase:
Stabilization, concurrency, and maturity

Impact on the system:
Your balance

Symptoms:

It takes several days or weeks to transition to a mature system.
There are many uncertainties in the risk existence and transition period, and some major functional scenarios have not been tested
The data in the actual system is different from the data in development and test.
Cannot be set up on the developer's machine
Application behavior varies in the development, stabilization, and product environment
Solution:
The solution is to faithfully configure the actual environment in the development environment, so that the development environment is close to the environment where the product is to be implemented. If JDK 1.2.2 and Solaris 7 are in the future, do not develop on JDK 1.3 and Red Hat Linux. This is also true for the application servers used. Similarly, you need to quickly check the data in the product database and use the data for testing. Do not rely on manually created data. If the product data is sensitive, you need to make it insensitive and configure it. Unexpected product data during development may cause damage to the following processes:

Data Inspection Rules
System Test Behavior
System component build (particularly including: EJB-EJB and EJB-database)
Worst of all, exceptions, null pointers, and issues you have never seen before.

Note:
Developers often put security issues in the stabilization phase before they begin to solve them. To prevent such traps, you can spend the same amount of time improving security in the business logic.

Maturity is a complex process, full of technical and non-technical issues. You may be stuck in a lot of unexpected problems. This is what maturity means. The process of developing and stabilizing the environment provides you with the opportunity to create more such problems, discover such problems, and continue to do so, which can greatly reduce risks.

The more projects you make, the more you can understand what is feasible and what is not feasible. You can record engineering problems to avoid repeated errors.

--------------------------------------------------------------------------------

Risk 5: Incorrect provider selected
Project phase:
Provider Selection

Impact phase:
Design, development, stabilization/load testing, and maturity

Impact on the system:
Scalability, performance, maintainability and Stability

Symptoms:

Developers need to spend more time dealing with tool issues, rather than using these tools effectively.
In order to cope with known and unknown problems, we had to make a significant system redesign.
It is difficult to integrate different tools (application server and IDE tools, IDE tools and debuggers, source code control and Synthesis tools, etc)
For ide tools and debuggers, developers often reject them and respect their favorite tools.
Solution:
To avoid risk 5, you need a good provider selection process. Risk 10 also applies to this process.

The most appropriate way to really measure an IDE tool is to actually use it. The only method to evaluate a J2EE application is to establish a conceptual test to prove that your application framework should be included in the test. In fact, you do not want to discover bugs after three months of training and development.

If you suddenly find a problem with your toolkit during development, you should know that some tools are indeed more important than others. If the application server you selected does not fully meet your needs, you have to modify the original settings. If the IDE is not good, you need to set a minimum of code standards and let developers choose the tools they think are the most effective.

Note:
It is not a one-time decision to know which supplier is most suitable for a special task. You need to keep track of and evaluate this market. For example, I have used four different ide tools over the past year, depending on what application servers and platforms I use and whether I use ejbs.

--------------------------------------------------------------------------------

Risk 6: do not know your provider
Project phase:
Provider Selection

Impact phase:
All phases after the Provider Selection phase: design, development, stabilization/load testing, maturity

Impact on the system:
Maintainability, scalability, and performance

Symptoms:

The development cycle exceeds the cycle of the worst prediction by more than 1/3
The provider has provided a function, but the developer re-develops the function without knowing it.
Solution:
To avoid such risks, you can subscribe to the provider's online resources as much as possible, such as the list of emails, news groups, and version information (especially the descriptions of bug fixes ), you can get immeasurable results.

Once you have selected a provider, You need to invest in training immediately and try your best before the project starts. Then, gradually build awareness and trust in this provider in the team. Try to build and deploy several ejbs and use your presentation layer technology (swing GUI, JSP, etc.) to call them. If you want to build both the development environment and the project goals at the same time, there will be unnecessary conflicts. In fact, I have also seen a situation where the build process has never been performed: "We don't have time ." Therefore, these tasks must be performed in advance. Some may say, "Our plan does not provide us with these times ." My answer is: "You didn't give you time in your plan to stop doing this ."

Note:
In the J2EE world, what is the technical compatibility of products of various providers? Let's take a look at the specific analysis of IBM and Bea. Both of them support EJB 1.1 in their respective application servers. So how many similarities does BEA WebLogic 5.1 and IBM WebSphere 3.5 actually have?

BEA WebLogic and IBM WebSphere have almost different system configuration and management methods.
IBM has adopted a comprehensive GUI environment in WebSphere, and Bea provides a complete set of command lines in weblogic.
IBM WebSphere uses IIOP to communicate with CORBA exceptions, which are visible to programmers. WebLogic does not have a CORBA structure, and T3 protocol is used by default.
WebSphere and Visual Age are closely linked, while Weblogic is independent of IDE. In fact, you can use almost any development tool.
It can be seen that there are many differences. If you are an application server expert, it does not mean that you are an expert of all application servers. This difference lies in IDE, debugger, build tool, configuration management, and so on. Having experience in using a certain special tool of a provider can make it easier to evaluate its competitor products. However, do not expect seamless transfer or convergence between different products. Therefore, you have to spend enough time mastering these tools.

--------------------------------------------------------------------------------

Risk 7: scalability and product performance are not fully considered in the design
Project phase:
Design

Affected project phases:
Development, load testing and maturity

Impact on the system:
Scalability, performance, and maintainability

Symptoms:

Unbearable speed
The system imposes a heavy burden on the server, but cannot use clustering technologies.
Solution:
Focus on performance and scalability requirements, and clarify the performance indicators to be achieved in development. If you need 50 transactions per second, and your EJB Design can only provide 40, you need to consider alternative solutions, such as stored procedures, batch processing, or re-consider the OLTP design.

As much as possible, your providers should be very clear about the strengths and weaknesses of their products, and then provide you with the most direct help.

Note:
This risk conflicts with risk 2 (over-engineering. In fact, they interact with each other. The solution I provided to risk 2 is to build only when absolutely necessary. For performance and scalability, you must pre-define what is necessary.

If you implement it, you can identify that the system requires very high scalability and use it as a key requirement, first, you need to select an application server with strong cluster support and transaction cache. In addition, you should design business objects as ejbs to take full advantage of the server architecture. There is no problem with XP, and you are still doing the absolutely necessary work.

I think of this as a way of checking and balancing. We only need a system with the simplest possibility. This system only provides the functions and actions required by the customer.

--------------------------------------------------------------------------------

Risk 8: outdated development process
Project phase:
Development

Impact phase:
Stabilization and maturity

Impact on the system:
Maintainability and code Quality

Symptoms:

A project plan looks like a waterfall model: "First, design the grass and then develop it over a long period of time ."
Since the build process does not exist, every build is a nightmare.
The build date is equal to the date of the loss of development, because nothing is done.
Components were not fully tested before integration, and integration testing means to put two unstable components together and view the tracing results in the stack.
Solution:
Good software methodologies will improve your software life cycle. I have mentioned the XP method before. You can find a lot of information on the Internet.

Note:
JUnit can be used for unit testing, and ant tools can be compiled and built. Both of these tools have good support for the XP method.

--------------------------------------------------------------------------------

Risk 9: no good architecture
Project phase:
Development

Impact phase:
Development, stabilization, and maturity

Impact on the system:
Maintainability, scalability, and code Quality

Symptoms:

Bugs are found in core libraries that are used in the Code many times.
No log standards are set up-as a result, the system output is hard to read or parse.
Bad inconsistent exception handling. In some sites, we can even see that the error information is directly exposed to the end user. For example, when the user sends an sqlexception stack trace message to his shopping cart account, what will the user do next? Do I need to fix the primary key constraint by calling the database administrator?
The following tasks have been processed by developers for countless times in various ways and need to be placed in the first batch of objectives of any architecture design.

Logs
Exception Handling
Connection to resources (databases, name services, etc)
Create a JSP page
Data Validity Check
Solution:
I am a believer and practitioner of light methodology. My first article on javaworld -- "frameworks save the day" -- discusses the architecture in the Enterprise Java environment. Even if you have already started development, it is worthwhile to consider the architecture. You may have to endure the Exception Processing and log processing caused by refactoring, but it is worthwhile in the long run, saving time and saving money.

Note:
Let's look at the different levels of reusability based on component development in the architecture. The first level is plumbing, with a reusable proportion of more than 0.9. That is to say, 90% of projects can be reused. The more detailed the service definition, the lower the reuse ratio. In other words, I need to build an accounting service, but to manage these resources and usage so that they can be reused in other 50% projects. But for those projects, it would be great to get these resources!

--------------------------------------------------------------------------------

Risk 10: The project planning and design are based on the market effect and are separated from the technical reality.

Note: New users are constantly involved in the Java/EJB development field. Generally, there are more people who do not understand Java than expected.

Project phase:
All stages will be affected, including Provider Selection

Impact phase:
All phases will be affected

Impact on the system:
Maintainability, scalability, design quality, and code Quality

Symptoms:

Rashly make technical decisions and think that EJB is only for convenience of portable Processing
No product trial is available immediately when you select a provider.
Tools also need to be replaced during the project lifecycle
Solution:
Do not trust the opinions of anyone outside the project. These people may already have some vested interests. Do not trust the provider's statement (unless you have already understood it) or the White Paper. If you want to obtain suggestions about application servers from the real world, you can obtain them online. You can also download these tools for evaluation, use them to make some prototypes, and run the sample. (Good providers have such examples ).

In general, it takes time to select the best provider and tool for your project, and you may not have much time. You can limit the selection range to 3-4 objects, and then compare and test them in one week. Finally, select a satisfactory tool and product.

Note:
If you lack J2EE experience, problems may occur in the early stage of the project. The decision made in the early stage will affect the entire process and the success of the project. A good J2EE consulting expert will help you select a good provider and draw a good configuration for design and development.

--------------------------------------------------------------------------------

Is there only 10 risks?

10 is just a specific number. Obviously, there are more and more risks. I can only ensure that if you have overcome the risks listed above, your project will have outstanding performance and have laid the foundation for success.

Note that nothing can replace experience and planning. If you have no experience, you must find a way to obtain and accumulate. Do not perform training on the project side. Make full preparations before development, preferably before design. Allow your team to receive guidance from the Java/J2EE consultant and ensure that such guidance can be passed to other team members.

Finally, it is necessary to mention the following points:

External impact of Software Engineering
When Will unit tests and integration tests be conducted?
Design Mode
Exception Handling
Conclusion
In general, the above 10 risks are the main difficulties you will face in developing enterprise-level Java projects. I also believe that there will be more traps in your journey, but I am sure that the risks I mentioned already cover the main issues. Finally, let's repeat 10 risks based on their priorities:

No real understanding of Java, no real understanding of EJB, no real understanding of J2EE
Over-engineering)
Business Rules and logical representations are not separated
No proper configuration is made in the Development Environment
Wrong provider selected
Do not know your provider
Scalability and product performance are not fully considered in the design
Outdated Development Process
No good architecture
The project plan and design are based on the market effect and are separated from the technical reality.
Finally, let me wish you good luck!