"J2EE core mode" second edition was launched at the Javaone Conference
http://developer.java.sun.com/developer/technicalArticles/J2EE/J2EEEVOLUTION/BY DAN MALKS and DEEPAK AlURjune 2003
At the 2001 Javaone meeting, we launched "J2EE Core Model", which contains a mode directory that involves 15 J2EE design patterns. These modes are typical issues that are often encountered under the J2EE platform and their solutions. This book also enumerates countless bad implementation and reconstructs them. Through these examples, you can improve your existing design. All of these modes are found and refined during the J2EE application we have created successfully.
Mode and communication technology issues and their solutions are closely related to us to record some repeated problems and their solutions and communicate with others. One of the motivation to write "J2EE core mode" is to confuse the "learning J2EE technology" with "design J2EE technology". Existing many Java books mostly introduce all aspects of J2EE technology, but almost no books describe how to apply these technologies. Based on the experience of the Java system architect from the SUN expert service Java, we think we can fill this gap.
But that is already the past, let's talk about now
After the first edition of "J2EE Core Mode", we received a lot of feedback from the 15 models. In the past few years, the J2EE mode discussion area is very active, and the registered member has more than 2,000 people. We are very happy to receive a large number of readers from J2EEPATTERNS-FEEDBACK@sun.com. In the past few years, we have made several important large J2EE structures, and we also participate in several project development, and we have continuously applied these modes, and in addition, some other modes are summed up.
Based on everyone's feedback and our experience in work, we have launched the second edition of the book at the 2003 Javaone meeting. The original 15 modes have been corrected and updated, introducing many new implementations and routines, increasing the contents of the Web Service, overwrites the latest J2EE1.4. We introduced 6 new models, so there are 21 J2EE design patterns. The newly added six mode main purposes is to improve mode language, providing high abstraction, you can use to construct and understand J2EE applications.
Mode directory
We introduced 6 new modes in the second version, two each layer:
Representation layer mode:
Environmental objects (Context Object)
Application Controller
Business Layer:
Application Service (APPLICE Service)
Business object
Integrated layer mode:
Domain Store
Web Service Broker (Web Service Broker)
Next, 21 modes in the mode directory are shown, and Fig. 1, Fig. 2, and FIG. 3 show a mode in each layer, and FIG. 4 shows the relationship between the respective modes. Note that all modes have been fixed and updated, including some new implementations and some new routines.
Figure 1: Representation layer mode (click to enlarge)
Figure 2: Business layer mode (click to enlarge)
Figure 3: Integrated layer mode (click to enlarge)
Figure 4: Relationship between each mode (click to enlarge)
Selection mode
In this part, we make a simple introduction to a small part of the newly introduced six modes. Other more detailed information, including other modes, implementations, routines, UML block diagrams, bad implementation and J2EE reconstruction, etc., refer to "J2EE core mode". Although until the current Object is recorded as a pattern, we actually use it often at work. The use of Context Object can improve the reusability, maintainability, scalability, and easy testability of the system. Let's introduce the problems involved in this mode, solution, UML class diagram, UML sequence diagram, and consequences using this mode.
Environmental objects (Context Object)
problem
You want to avoid using information related to the system specific protocol outside the relevant environment.
An application always uses system information, such as request information, configuration information, and security data, such as request information, configuration information, and security data, by requesting / responding, etc., which are always related to a particular processing environment. If the application's components or services use these system information directly outside the particular environment, the flexibility and reuse of these components are reduced. The API-related APIs related to the external use protocol in a particular environment means that all components that use these APIs are fully exposed and too exposed to detail. Each customer component is thus tightly bound with a particular protocol.
solution
Create an environment object to encapsulate system information in a way that is unrelated to the protocol, then use this environment object within the entire application.
As shown in Figure 5, the system information is packaged in an environment object, allowing other parts of the program to share access, which can avoid binding the application with a specific protocol. For example, each domain in the HTML Form is an HTTP request parameter. If you use an environment object to store these data in a way with the protocol, then the data conversion and verification will become easier. Moreover, other parts of the program can also access this information directly from the environment, without considering the problem of HTTP protocols. If the protocol has changed, only the other part of the application is not used as any change.
Figure 5: UML class diagram of the environment object (Context Object)
result
Improved accessibility and maintainability The interface of the application is independent of a specific protocol, then the components and subsystems defined are more common, and can be multiplexed by a wide variety of clients.
Improve easy testing use environmental object patterns can help clear the code associated with a specific web container or application server. If these dependence is restricted or eliminated, it can be tested easier. For example, you can use some automatic test tools, such as using JUnit to perform automated testing.
Reduces the interface of the interface changes the original application's interface to accept a large number of system information, and now use the environment object to encapsulate this data, the application is only available to accept the environment. This reduces the coupling of the application and a specific platform so that future modifications can be easier to perform. This is very important for developing application frameworks, of course, it is also valuable to develop general programs.
Performance Reduction Use Environmental Object Mode To deliver various data between objects, thus causing a certain degree of performance. However, the benefits of performance have brought by the use of environmental objects, such as application component reuse, applications are more prone to maintenance and modification, etc., it is insignificant.
We have added two modes in business layer mode, one of which is an Application Service. This mode is related to ordinary business logic. Because if you use Session Façades, you will cause the code to repeat, and if you encapsulate these logic in business object, it will cause the number of objects to increase.
Application Service (APPLICE Service)
problem
You want to span several business layer components and services to form a business logic facade, such as Session Façade or Pojo Façade, almost does not contain business logic, just provide a simple, rough interface. Business object encapsulates a set of related business operations. Use case (USE case) is used to coordinate these business objects and services, and the application is used to implement these use cases. However, you should not let the acts within the business object, which increases the in-coupling, reduces the internal strength between these business objects. Similarly, you should not add business logic to the service facade because business logic is potentially copied between different facators, which reduces the reuse and maintainability of universal code.
solution
Use an Application Service to aggregate a variety of behaviors to provide a unified service layer.
Application Service provides a central location of business logic, which can encapsulate various business objects and services. This way of implementing business logic can reduce coupling between business objects. Using the Application Service mode, you can package the dispersed, packaged components and services of the service into a advanced business logic.
Even if you don't use the business object in your application, you can also use the Application Service mode to provide a unified business logic implementation layer, even if you use the APPLICE mode. In this case, Application Service may contain all the intermediate business logic required to implement different services in your program. If you want to handle persistence data, you may include data access objects (Data Access Object, DAO) .
Figure 6: Application Service (Click to enlarge)
In addition
The CONTEXT Object and Application Service is just a new small part of the second edition of J2EE core mode. We will also write some articles to discuss other modes.
We also hope that readers can join the model community, and the J2EE mode discussion area is a great place to discuss and modes. Or, you can also contact us through J2EEPATTERNS-FEEDBACK@sun.com. Of course, if you like, you can also participate in the Javaone's technology conference on Thursday, we can communicate in face-to-face.
Finally, we thank all the readers who bought this book to participate in our conference and people who directly communicate with me through Email, and those who support J2EE Mode discussion areas. It is great to receive feedback from your feedback, we look forward to the next exchange.
Here are more information about the mode
J2EEPATTERNS-FEEDBACK@sun.comj2ee core mode
