The most important 10 J2EE best practices

zhaozj2021-02-16  71

Sender: WAS (Ginkgo Biloba ◇ THE Of Days), the letter area: J2EE

Title: The most important 10 J2EE Best Practices (IBM DW)

Sending station: BBS Shuimu Tsinghua Station (Tue Jul 13 20:52:45 2004), in the station

IBM WebSphere Developer Technical Journals: The most important 10 J2EE best practices

Level: primary

Kyle Brown, Advanced Technical Member, IBM Software Services for WebSphere

Keys Botzum, Senior Adviser / IT Professionals, IBM Software Services for WebSphere

Ruth Willenborg, Senior Manager, IBM WebSphere Performance

July 2004

This article lists the best practices for more than a dozen most important J2EE applications.

Introduction

In the past five years, many people have written books on J2EE best practices and articles. Now approximately

There are 10 (or more) books and many articles, they put forward the J2EE app

opinion. In fact, this area is so much, and there are still some spears between these reference materials.

Shield recommendation, when you experience these confusion, these confusion will form an obstruction for using J2EE itself. in order to

Can provide some simple guidance for people who have this confused, so we list the "most important 10"

List, they are the best practices we feel the most important J2EE. Unfortunately, 10 items are not enough to elaborate all

The content, especially when you develop web services as part of J2EE. So in order to get J2EE

Exhibition, we decided to use the "most important 12" list instead of "the most important 10" list.

In order not to complicate problems, we use - the most important 10 ( 2) J2EE best practice ...

Best Practices

Always use the MVC framework.

Automatic unit testing and test management is applied to each layer.

Developed in accordance with specifications, rather than in accordance with application servers.

J2EE security is planned from the beginning.

Create what you know.

When using the EJB component, always use session facades.

Use stateless session beans instead of state session beans.

Use container management transactions.

JSP is the first choice for the representation layer.

When using HttpSession, try to save the status required by the current business, do not save

In httpsession.

In WebSphere, start the dynamic cache and use the WebSphere Servlet Cache mechanism.

In order to improve the work efficiency of the programmer, the CMP entity bean is the preferred solution for the O / R mapping.

1. Always use the MVC framework.

The MVC framework can logic (Java Beans, and EJB components), controller logic (servlets / struts)

Action), the representation layer (JSP, XML / XSLT) is clearly separated. Good layers can bring a lot of benefits.

The MVC framework is so important for successful use J2EE, so that there is no other best practice to compare with it. mold

Type - View - Controller (MVC) is the basis for designing J2EE applications. MVC simply divides your program code

The following sections:

The code responsible for business logic (ie models - usually implemented using EJB or ordinary Java objects).

Responsible for the code displayed by the user interface (ie view - usually implemented by JSP and tag ", sometimes XML

And XSLT is implemented).

The code responsible for the application process (ie, the controller - usually uses the Java Servlet or class like the Struts controller).

Now there are a lot of excellent reviews about MVC, and we specially recommend interested readers can refer to [Fowler] or

[Brown] articles (see Resources), you can get a comprehensive and profound understanding of MVC.

If you don't follow the basic MVC framework, there will be a lot of questions during the development process. The most common question is

There is too much ingredients added to the view section, for example, there may be use JSP tags to perform database access, or

The process control of the application in JSP, which is more common in small-scale applications, but

In the late development, this will bring problems because JSP will gradually become more difficult to maintain and debug.

Similarly, we have often seen the case where the view layer is built to business logic. For example, a common problem is

The XML parsing technique used when constructing a view directly applies to the business layer. The business layer should be on the business object - not

It is a specific data representation that binds to the view.

However, it is only a suitable component that does not necessarily mean that your application can get a suitable hierarchy. We often

Common to some applications contain all three items, JSP, and EJB components, however, its main business

Logic is implemented in a servlet layer, or application navigation is processed in JSP. You must strict

Code check and reconstruct your code to ensure that the application's business logic is only in the model layer (MODEL LYER)

Direction, application navigation is only processed by controller layer, and your view (

Views only expressed the passing model objects in the form of HTML and JavaScript.

2. Automatic unit testing and test management are used in each layer of the application.

Don't just test your graphical user interface (GUI). The layered test makes testing and maintenance work extremely simple.

In the past few years, there is a considerable innovation in the field of methodology, such as newly appeared as Agile (for example

Scrum [Schwaber] and Extreme Programming [Beck1], see the lightweight method of the reference) Now

A very common application. A common feature in almost all of these methods is that they all advocate automatic testing

Tools, these tools can help developers return to the regression test with less time.

And help them avoid errors caused by insufficient regression tests, so they can be used to improve programmers.

effectiveness. In fact, there is also a method called Test-first development [beck2], this method is

To advocate, you will write unit test before developing the actual code. However, before you test the code, you need to

The code is split into some testable pieces. A "big mud" is difficult to test, because it is not only a simple

Easy to identify functions. If you implement multiple functions, such code will be difficult to guarantee

Its complete correctness.

One advantage of the MVC framework (and the MVC implementation in J2EE) is the component of the element (actually, phase

When you are simple), you can perform unit testing for your application. Therefore, you can easily make the entity bean, session

Beans and JSPs have written test cases independently without having to consider other code. There are now many J2EE tests

Framers and tools, these frameworks and tools make this process easier. For example, JUnit is an open source tool developed by junit.org and CACTUS (open source tool developed by Apache)

It is very useful to test J2EE components. [Hightower] explores how to use these tools in J2EE in J2EE.

Although all of these details how thoroughly test your app, we still see some people think that as long as he

They tested GUI (may be web-based GUI, or independent Java app), they

The entire application is tested. The GUI test is difficult to achieve comprehensive testing, with the following reasons. First, use

The GUI test is difficult to completely test each path of the system, and GUI is only a way to affect the system,

There is background operation, scripting, and various other access points, which also requires testing. However, they usually do not

GUI. Second, the test of the GUI is a very coarse particle size test. This kind of test is only tested in macro levels.

The behavior of the test system. This means that once there is a problem, the entire subsystem related to this issue is checked.

This makes it very difficult to find BUG (defect). Third, GUI test usually only throughout the development week

The later period of the period can be tested well because only this time GUI gets a complete definition. Herein

It is only possible to find potential bugs in later periods. Fourth, a general developer may not have an automatic GUI test

Try tool. Therefore, when a developer changes to the code, there is no simple method to retest

Subsystem of affected. This is actually unfavorable to conduct a good test. If the developer has an automatic code unit measurement

Test tools, developers can easily run these tools to ensure that changes made will not destroy existing work

can. Finally, if an automatic build function is added, an automatic unit test tool is added during the automatic build process.

It is very easy. After completing these settings, the entire system can be regularly reconstructed, and return

Test hardly requires people to participate.

In addition, we must emphasize that using EJB and web services, distributed, component-based development makes test orders

The components are very necessary. If there is no "GUI" to test, you must be low-level (Lower-Level)

test. It is best to start testing in this way, save the distributed component or web service as your application

When you are part of the order, you have to spend your mind and re-test.

In summary, by using an automated unit test, it is possible to quickly find the deficiencies of the system, and it is also easy to discover these defects.

Make the test work more systematically, so the overall quality is also improved.

3. Developments in accordance with the specification, rather than in accordance with the application server.

To be familiar with the specification, if you want to deviate from the specification, you can do this after careful consideration. This is because when you

When departing from rules, what you do is often not what you should do.

This is easy for you to make you unfortunate when you want to take the J2EE. We found some

Some developers have drilled things other than J2EE allowed, they think so can "slightly" improve J2EE sex.

Can, and they will eventually find that this will cause serious performance issues, or in the future transplantation (from a manufacturer

To another manufacturer, or more common from a version to another version. In fact, this

The migration problem is so serious, so that [Beaton] referred to this principle as the basic best practice of transplantation.

Now there are several places if they don't directly use J2EE, will definitely produce problems. A common example is that developers replace J2EE security by using JAAS modules, rather than using built-in compliance applications.

The program server mechanism is verified and authorized. Be careful not to detach the authentication mechanism provided by the J2EE specification, if you take off

From this specification, this will be the main reason for the system has security vulnerabilities and manufacturers compatibility. Similarly, use

The authorization mechanism provided by the servlet and the EJB specification, and if you want to deviate from these specifications, make sure to use the rules

Fan-defined API (for example, getCallerPrincipal ()) is the foundation of implementation. In this way, you will be able to

Such a strong safety infrastructure provided by the manufacturer, where business requirements need to support complex authorization rules.

Other common problems include the use of persistence mechanisms that do not follow J2EE specifications (this makes transaction management difficult),

Use inappropriate J2SE methods (such as threads or singleton) in the J2EE program, and use your own party

Method Solving the process of program to program-to-program, rather than using J2EE's internal support (

For example, JCA, JMS or Web services). When you transfer a server that follows J2EE to other servers

Or on the new version of the same server, the above design selection will result in countless problems. The only thing to depth

The condition of the specification is that when a problem is unable to solve in the specification. For example, arrange the operation of the timed business

Logic is a problem before EJB2.1 appears. In case of this, we recommend that the manufacturer provides the solution.

Use the solution provided by the manufacturer (for example, WebSphere Application Server)

The SCHEDULER tool in Enterprise), and uses third parties when there is no manufacturer's solution

Tool of. If you can use the solutions provided by the manufacturer, the application is maintained, and it will be transplanted to the new specification version.

It is a manufacturer's problem, not your problem.

Finally, be careful not to use new technologies too early. It is too keen to use other parts that have not been integrated into J2EE.

The technique that is not integrated into a product that is integrated into the vendor will often bring catastrophic consequences. Support is critical - if

Your vendor does not directly support a specific technology proposed in JSR, but this technology has not been accepted by J2EE.

Then you should use this technology. After all, most people in us work in solving business problems, not advancing

The development of technology.

4. Plan J2EE security from the beginning.

Enable WebSphere security. This allows your EJB and URL to at least access all authorized users. do not ask

Why - it is done.

In the customers who work with us, it is very small to set up WebSphere J2EE security.

This has always been surprised. According to our estimation of only 50% of customers, we will intend to use this feature.

. For example, we have worked with some large financial institutions (banks, agents, etc.), they have not intended to be enabled.

safety. Fortunately, this problem is resolved when deployed.

It is dangerous to use J2EE security. Suppose your application needs security (almost all applications

Need), you will bet your developer to build your own security system, and this system is from you

J2EE manufacturers have bought better. This is not a good bet, providing security for distributed applications.

It is often difficult. For example, you need to use a network security dollar to control access to EJB. In our experience

Most of the security systems built are unsafe, and have a significant defect, which makes the product system extremely fragile (please refer to Chapter 18 of [Barcia]).

Some reasons that do not use J2EE security include: worrying about performance decline, believes other security (for example

Netegrity Siteminder can replace J2EE security, or don't know WebSphere

Application Server security features and functions. Don't fall into these traps, especially, even

NETEGRITY SITEMINDER can provide excellent security features, but only it is impossible to protect

Protect the entire J2EE application. These products must be combined with J2EE application servers to fully protect

Protect your system.

The reason for other common non-use J2EE security is: the role-based model does not provide sufficient granular access

Q & A to meet complex business rules. Although the truth is like this, this should not be safe for J2EE security.

Sexual reason. Conversely, J2EE verification and J2EE roles should be combined with specific expansion rules. If complex

Miscellaneous business rules need to make safety decisions, then write corresponding code, and its security decisions should be based on

Use and reliable J2EE verification information (user ID and role).

5. Create what you know.

Repeated development work will allow you to gradually master all J2EE modules. Start with a simple and simple module from creating a small

Instead of being immediately related to all modules from the beginning.

We must admit that J2EE is a huge system. If a development team just starts using J2EE, it will be difficult to

Come and master it. There are too many concepts in J2EE and the API need to be mastered. In this case, successfully mastered

The key to J2EE is starting from a simple step.

This approach can be achieved by creating small and simple modules in your application. If one is open

Send a group By creating a simple domain model and the back-end persistence mechanism (perhaps JDBC), and

It has made a complete test, which will enhance their self-confidence, so they will use the domain model to master the use.

The front end development of servlet and JSP. If a development group finds it is necessary to use EJB, they will also open similarly.

Starting on the persistent EJB components managed by the container, use simple session facades, or use JDBC-based

Data Access Objects (JDBC-Based Data Access Objects, DAO), not skip these to use more

Complex construction (such as a message drive bean and JMS).

This method is not a new method, but there are very few developing groups to cultivate their skills in this way. Conversely,

Most Developers are constructing all modules because they try to immediately, while involving view layers, model layers and controls in MVC.

The result of this is that they tend to fall into the pressure of progress. They should consider some agile (Agile

Development method, such as extreme programming (XP), which uses an incremental learning and development method. In XP

There is a process called modelfirst [wiki], which involves first building domain model as a machine.

Produce organization and user scenes. Basically, you have to build a domain model as the first part of the user's scene you want to implement.

Separate, then build a user interface (UI) as a result of user scenes on top of top of the domain model. This method is very

Suitable for a development group only to learn a technology, not let them face a lot of situations (or let them

Read a lot of books), this will crash them.

Also, development of repetition of each application layer may contain some appropriate modes and best practices. If you start using some patterns such as data access objects and sessions facade, you should not be in your JSP.

And domain logic in other view objects.

Finally, when you develop some simple modules, you can perform performance testing for your application at the beginning of the beginning.

If performance test is performed until the later application development, this often has disastrous consequences.

[Joines].

6. Always use the session Facades when using the EJB component.

Never expose entity beans directly to any user type. You can only use local EJB interfaces for entity Beans

LOCAL EJB Interfaces.

When using the EJB component, use a session facades is a confirmation of undoubted best practices. In fact, this

General practices are widely applied to any distributed technology, including CORBA, EJB, and DCOM. Basically

It is said that your application's distribution "cross-region" is below the bottom, and the data of small blocks is due to multiple repetitive networks.

The less time consumption is caused. The method to achieve this is to create a large-scale Facades object,

This object contains a logical subsystem, so you can complete some useful business functions through a method call.

This method can not only reduce the network overhead, but also created a transaction ring throughout the business function inside the EJB.

The situation can also greatly reduce the number of access to the database ([Brown] is discussed in detail. [Alur]

This model is specified. [Fowler] (and include an EJB) and [Marinescu]

It also describes it. See the reference).

The EJB local interface (starting from the EJB 2.0 specification) provides performance optimization methods for coexisting EJBs. Local connection

The mouth must be explicitly accessed by your application, which requires a change in code and needs to be needed to configure EJB later.

The change in the application. Since session, Facades and the entire EJB it contains should be local for each other.

We recommend using local interfaces using entity beans behind session facade. However, conversation facades itself

Implementation (typical examples such as stateless session beans) should be designed as remote interfaces.

For performance optimization, you can add a local interface to the session Facades. This makes this fact

: In most cases (at least in the web application), your EJB client and EJB will also exist together

In the same Java virtual machine (JVM). Another situation, if the session facade is called locally, you can

Configuration Optimizations, such as WebSphere using J2EE application servers

"No Local Copies". However, you must notice that these optionable scenarios will make interactive methods

Pass-by-value is changed to passed by reference (pass-by-reason). This may be in your code

A delicious mistakes are generated. When you use these scenarios, you should consider its feasibility at this.

You can also use the remote interface in your session facade (instead of local interface), you can also

Facades are configured in a compatible manner in J2EE 1.4 as a web service. This is because JSR 109 (J2EE

1.4 Web Service Deployment section) Requires the remote interface of the stateless session bean as an interface implemented by the EJB Web service and EJB. This is worth it, because this can add client types for your business logic.

quantity.

7. Use stateless session beans instead of state session beans.

Doing so allows your system to stand the error. Use httpsession storage and user-related status.

In our point of view, the concept of stateful session bean is outdated. If you think about it carefully, one

There is a status session bean actually with a CORBA object is exactly the same, nothing more than one

An object instance, bind to a server, and rely on the server to manage its lifecycle. If the server is turned off

This object does not exist, then this bean's client information does not exist.

The J2EE Application Server provides failover (failover) provided by stateful session beans to solve some problems.

However, there is no state-of-state solution that is easy to expand. For example, in WebSphere

APPLICATION Server, requests for stateless session beans are members of deploying stateless sessions

The cluster is balanced and loaded. Conversely, the J2EE application server cannot be flattened to the stateful bean request.

Balanced load. This means that the loading process of the server in your cluster will be uneven. In addition, use stateful sessions

Bean will add some status to your application server, which is also a bad practice. This increases the system

The complexity and the problem becomes complicated in the event of a failure. One level of creating a robust distributed system

Key principle is to use stateless behavior as much as possible.

Therefore, we recommend using a stateless session bean method for most applications. Any need to be used during processing

The status associated with the user should be transmitted to the EJB in the form of parameters (and by using a mechanism

HttpSession to store it) or from persistence backend (eg, by using entity beans) as EJB

Part of the transaction to retrieve. In the right case, this information can be cached in memory, but pay attention to

Save this cache in the distributed environment. The cache is very suitable for readup data.

In summary, you have to make sure that stretchability is taken into account from the beginning. Check all the ideas in the design and consider when you

The application is to run normally when running on multiple servers. This rule is not only suitable for the above situation

The application code is also applicable to the case of MBean and other management interfaces.

Avoiding statusity is not just recommendations for IBM / WebSphere, this is a basic J2EE design principle.

See [Jewell] Tyler Jewell's criticism with state beans, its views and the above views are the same

of.

8. Using container-managed transactions.

Learn two stages of submission of J2EE, and use this way, not open your own transaction

. The container is almost always better in terms of transaction optimization.

Transaction (CMT) with container is provided with two key advantages (if there is no container support, this is almost impossible

): A combination of work units and robust transactions.

If your application code explicitly uses the start and end transactions (perhaps use javax.jts.Usertransac

TION or even local resource transactions, and future requirements require a combination module (perhaps the code reconstruction

Part), in this case, it is often necessary to change the transaction code. For example, if the module A starts a database transaction

Update the database, subsequently submit transactions, and have the same processing, consider what is the case when you try to use the above two modules in module C? Now, the module C is executing a logical action.

And this action will actually call two independent transactions. If the module b failed in the execution, the module A

The transaction can still be submitted. This is the behavior we don't want to appear. If, conversely, modules A and module B

With CMT, the module C can also start a CMT (usually by a configuration descriptor), and in the module A

And the transaction in the module B will be the implicit part of the same transaction, so no longer need complex rewrite code work.

.

If your application needs to access multiple resources in the same operation, you should use two phases to submit a transaction. E.g

If a message is deleted from the JMS queue, and then update the record based on this message, then to ensure

These two operations will be implemented or not executed. If a message has been deleted from the queue,

The system does not update the record in a database related to this message, then this system is unstable. Part of

Customers and business disputes are from inconsistent states.

We often see some client applications try to implement their own solutions. Maybe it will pass the application's generation

The code "revoke" to the queue when the database update fails. We don't advocate this. This implementation is comparable

Your initial imagination is much more complicated, and there are many other situations (imagine if the application is executing this

Suddenly crash during the process). As an alternative, two phases should be used. If you use

CMT, and access the two-stage submitted resources in a single CMT (eg JMS and most databases),

WebSphere will process all complex work. It will ensure that the entire transaction is executed or not, including

Crash, database crashes or other situations. It is actually saved in the transaction log. When app

When you ask a variety of resources, how do we emphasize the need to use the CMT transaction?

9. JSP as the preferred layer of the representation.

It is only used when multiple representation of output types are needed, and the output type is used by a single controller and backend.

XML / XSLT.

We often hear some debate that why you choose XML / XSLT instead of JSP as a representation layer technology. select

XML / XSLT's view is that JSP "allows you to mix models and views", and XML / XSLT will not

Have this problem. Unfortunately, this view is not completely correct, or at least not as clear as white and black. real

So, XSL and XPath are programming languages. XSL is Turing-Complete, although it does not match

Most of the programming languages ​​defined because it is rule, and does not have control tools for programmer habits.

The current problem is that since it gives this flexibility, developers will use this flexibility. Although everyone recognizes

JSP makes developers easily add "similar model" in the view, and in fact, it is also possible in XSL.

Make some same things. Although things that have access to the database in XSL are very difficult, we

I have seen some abnormal complex XSLT style sheets to perform complex conversions, which is actually model code.

However, the most basic reason for JSP as the preferred representation of JSP is that JSP is now the most widely supported

It is also the most widely understood J2EE view technology. With the custom tag, JSTL and JSP2.0

Sexual introduction, creating JSP makes it easier and does not require any Java code, and you can separate the models and views. In some development environments (such as WebSphere Studio) joined JSP (including compament

The strong support of the support of the test, and many developers have found that the development of JSP is simpler than using XLs.

Some graphics design tools that support JSP and other features (especially in the framework of JSF) make developers

The development of JSP is performed in the way you have obtained, and for XSL is sometimes not easy.

The last reason for cautious considers the use of JSP is the speed problem. Comparison XSL and JSP made in IBM

Speed ​​performance test show: In most cases, JSP is fast than XSL when generating the same HTML.

This is also a few times, and even the compiled XSL is also used. Although this is not a problem in most cases, in performance requirements

This will become a problem with high conditions.

However, this can not be said that you will never use XSL. In some cases, XSL can represent a set of fixed numbers.

According to different style sheets (see [FOWLER]), it can be displayed in different ways.

Force is the best solution for display. However, this is just an exception, not a general rule. in case

You only generate HTML to express every page, then in most cases, XSL is an unnecessary technology.

Also, it gives your developers much more than what it can solve.

10. When using the HttpSession, try to save the status required by the current firm, do not

Save in httpsession.

Enable session persistence.

HttpSessionS is very useful for storing application status information. Its API is easy to use and understand. regret

What developers often have forgotten HttpSession - used to maintain temporary user status. It is not

Any data cache. We have seen too many systems placed a lot of data for each user's session (reached

Megabytes). Well, if there is a user of 1000 login system, each user has 1MB number of sessions

According to, 1G or more memory is required for these sessions. To make these HTTP session data less,

Otherwise, your application will fall. A more appropriate amount of data should be every user

The session data is between 2k-4K, this is not a hard rule, 8K still has no problem, but it will obviously be 2K

The speed is slow. Be careful not to make httpsession become a place where data is stacked.

A common problem is to use the HTTPSession cache some information that is easy to create, if necessary.

Since session is persistent, unnecessary serialization and write data are a very extravagant decision. Conversely,

The hash table should be used to cache data, and a keyword that is referenced in the session.

. This way, if you cannot log in to another application server, you can recreate the data. (See

[Brown2])

Don't forget to enable this feature when talking about session persistence. If you do not enable session persistence, or service

For some reason, the current user of all this application service is stopped (server failure or normal maintenance)

Will be lost. This is a very unhappy thing. Users have to log in and re-do some of them

Things have been done. Conversely, if session persistence is enabled, WebSphere will automatically move the user (and their session) to another application server. Users don't even know that there will be this happening. we

I have seen some product systems because it is unbearable BUG in the local code (not IBM code)

! Suddenly crashing, in this case, the above functions can still operate well.

11. In WebSphere, use dynamic cache and use the WebSphere Servlet cache mechanism.

By using these features, system performance can be greatly improved, and the overhead is small. And does not affect the programming model

type.

It is well known to improve performance through caching. Unfortunately, the current J2EE specification does not include one

A mechanism for servlet / JSP cache. However, WebSphere provides support for pages and segment caches.

This support is implemented through its dynamic cache function and does not need to make any changes to the application. Slow

The strategy is declared, and its configuration is implemented by an XML configuration descriptor. So your application

The order will not be affected and maintain compatibility and portability with J2EE specification, while also from WebSphere

Performance is optimized in the Cache mechanism of Servlet and JSP.

The improvement of performance obtained from the dynamic caching mechanism of Servet and JSP is obvious, depending on the application

Features. Cox and martin [cox] point out the summary of an existing RDF (resource description format) site

(RSS) Servlet When using a dynamic cache, its performance can be increased by 10%. Please note that this experiment only involves one

Simple servlet, this performance growth may not reflect a complex application.

To more improved performance, cache the WebSphere Servlet / JSP results with WebSphere plugin ESI

FRAGMENT processor, IBM HTTP Server Fast Response Cache Accelerator (FRCA) and

The Edge Server cache function is integrated. For heavy read workloads, by using these features

You can get many additional benefits. (See the performance of performance described in [Willenborg] in the reference material

)

12. In order to improve the work efficiency of programmers, CMP entity beans as an O / R mapping preferred solution.

Optimize performance through the WebSphere framework (Readahead, cache, isolation level, etc.). If possible, have selected

Applying some modes to improve performance, such as Fast-Lane Readers [Marinescu].

Object / Relationship (O / R) mapping is the basis of using Java to create an enterprise-level application. Almost every J2EE application

The program requires some types of O / R mappings. J2EE manufacturers provide an O / R mapping mechanism that is different in different

The vendors are portable, efficient, and can be well supported by some standards and tools. This is the EJB rule

The CMP (Persistence of Container Management) section of the Fan.

Early CMP implementations are known for its poor performance and not supporting many SQL structures. However, with EJB 2.0 and

2.1 The emergence of the specification and adopted by some manufacturers, and with IBM WebSphere Studio

The emergence of Application Developer is no longer a problem.

The CMP EJB component is now widely used in many high-performance applications. WebSphere includes some optimization functions to improve the performance of EJB components, including: cache and read-ahead capability for lifecycle

. Both optimization functions are optional options and do not need to modify or affect the portability.

.

Lifecycle cache CMP status data in a cached state and provides time-based invalidity. From in a cached state

The performance improvement of life cycle can achieve the cache performance of option A and can still be your application

Provide stretchability. Read-ahead capability and the relationship between container management use. This feature passes the same check

Inquirildly retrieve relevant data as parent data, reducing the interaction with the database. If the relevant data should be made

If you use concurrent queries to access, this method can be improved. [Gunther] provides a detailed description

And the details obtained by these features improved.

In addition, in order to fully optimize your EJB components, pay special attention when specifying the isolation level. Use the lowest possible

Isolation level and still keep your data integrity. Lower isolation levels provide optimal performance, and

It can reduce the danger of the database deadlock.

This is the most controversial best practice. There have been a lot of articles to praise CMP EJB, the same deceased

ear. However, the most basic problem here is that database development is difficult. When you start using any persistence solution

Previously, you need to master the query and how the database locks how to work these basics. If you choose to use CMP EJB

You have to make sure you have learned how to use them through some books (such as [Brown] and [Barcia]). Lock

There are some subtle interactions that have some subtle interactions in terms of contention, but they will take their palms after you spend a certain time and effort.

Grip.

Conclude

In this short summary, we have introduced you to the core model and best practices in J2EE, which makes

J2EE has developed into a manageable process. Although we have not given the need to use these modes in practice

To be detailed, but we hope to give you enough guidance and guidance to help you decide what to do next.

Thank you

Thanks to all people who originally proposed these patterns and best practices (and those listed below), so I would like to thank John.

Martinek, Paul Ilechko, Bill Hines, Dave Artus and Roland Barcia's review on this article

read.

Reference

[Alur] Deepak Alur, John CRUPI and Danny Malks Complete "Core J2EE PATTERNS (Second

Version) ", Addison-Wesley, 2003

[Bakalova] R. Bakalova Wai WEBSPHERE DYNAMIC CACHE: IMPROVING WebSphere

Performance ", IBM Systems Journal, 2004, 2nd Volume 43

[Barcia] Roland Barcia et al. "IBM WebSphere: Enterprise Deployment and

Advanced Configuration, IBM Press, 2004

[BECK1] Kent Beck writes "Extreme Programming Explained: EMBRACE CHANGE",

Addison-Wesley, 1999

[Beck2] Kent Beck writes "Test Driven Development By Example", Addison-Wesley

,year 2002

[Beaton] Wayne Beaton written "Migrating to IBM Websphere Application Server, Part 1: Designing Software for Change", IBM DeveloperWorks

[Brown] Kyle Brown, etc. Enterprise Java Programming with IBM WebSphere

Second Edition) ", Addison-Wesley, 2003

[Brown 2] Kyle Brown, Keys Botzum written "Improving HttpSession Performance"

With smart serialization, IBM DeveloperWorks

[COX] J. Stan Cox and Brian K. Martin Written "Exploiting Dynamic Caching in

WAS 5.0 ", Part1, E-Pro Magazine (2003 7/8 month)

[Fowler] Martin Fowler Written "Patterns of Enterprise Application Architecture

", Addison-Wesley, 2002

[Gunther] Harvey Gunther et al. "Optimizing WebSphere 5.0 Performance Using

EJB 2.0 CACHING AND Read-ahead hints, WebSphere Developers Journal, 2003

March

[Jewell] Tyler Jewell written Stateful Session Beans: Beasts of Burden,

Onjava.com

[Joines] Stacy Joines, Ken Hygh and Ruth Willenborg "Performance

Analysis for Java Websites, Addison-Wesley, 2002

[Marinescu] Floyd Marinescu Written "EJB Patterns", John Wiley & Sons, 2002

[Schwaber] Ken Schwaber and Michael Beedle, Agile Software Developments, MiCILE Software

With scrum, costice-hall, 2001

[Wiki] Wiki website: http://c2.com/cgi-bin/wiki? Modelfelfirst

[Willenborg] R. Willenborg, K. Brown, g. Cuomo "Designing WebSphere"

Application Server for Performance: An Evolutionary Approach, IBM Systems

Journal, 2004 No. 2 Volume 43

About the Author

Kyle Brown is a senior technology member of IBM Software Services for WebSphere. KYLE to wealth

500 customers provide consulting services, training and guidance on object-oriented topics and J2EE technology. He is with others

Enterprise Java Programming With IBM WebSphere, WebSphere AES 4.0 Workbook

For Enterprise Java Beans (3rd Edition) and The Design Patterns Smalltalk Companion. He also often published a speech on enterprises Java, OO design and design patterns at the seminar.

Keys Botzum is an advanced consultant for IBM Software Services for WebSphere. He is distributed in large scale

There are more than ten years of experience in design, and specialize in safety issues. Keys uses various distributed technology, package

SUN RPC, DCE, CORBA, AFS, and DFS. Recently, he focuses on J2EE and its related techniques. He has

Master of Computer Science in Stanford University and Bachelor of Science / Computer Science in Carnegiemelon University.

Ruth Willenborg is a manager of the WebSphere Application Server Performance group. She is with people

Book of Performance Analysis for Java Web Sites (Addison-Wesley, 2002).

-

We are like this, each will go ..

※ Source: · BBS Shuimu Tsinghua Station SMTH.ORG · [From: 210.76.98.70]

Related resources: with sound access new year fireworks animation effects - html-code

转载请注明原文地址:https://www.9cbs.com/read-15070.html

New Post(0)