Implementation of the observer mode in J2EE

Http://35java.com/zhibo/forum.php? MoD = viewthread & tid = 108 & extra = Page % 3d3

Introduction:
The design pattern is experience documented. It is a description of classes and objects used to solve general design problems in specific scenarios. In more general terms, it is a problem/solution pair. Once we have mastered the design model, we have a strong team of experts. It even allows new object-oriented users to use their previous experiences to find classes and objects with clear responsibilities, so as to get an elegant solution. Because the design pattern is also the goal of reconstruction, if the design pattern is introduced appropriately at the initial stage of design, the workload of reconstruction can be reduced.
However, we cannot fall into the pattern trap. To use the pattern, we will fall into formalism. When using the pattern, we must pay attention to the intent of the pattern (intent), instead of paying too much attention to the Implementation Details of the pattern, because these Implementation Details are under specific circumstances, some changes may occur. Do not stubbornly consider the class diagram or implementation in the design pattern bookCodeThe pattern itself.
Next, we will discuss why the observer mode should be used in distributed, multi-tier systems.

Multi-tier architecture ):
The three-tier architecture is the simplest of the multi-tier architecture. It generally includes:

• Presentation layer (Presentation)-window, report-
• Business logic layer-manages tasks and rules in a business process. It can be subdivided into the domain object Layer (representing the domain concept) and the service layer (providing database interaction, security, and printing reports ).
• Storage-persistent storage mechanism. Such as database servers.

Figure 1: three-tier architecture

Java 2 Platform Enterprise Edition (J2EE) is an architecture that uses Java 2 platform to simplify the development, deployment, and management of many complex problems related to multi-level enterprise solutions. It is an open, standard-based platform for developing, deploying, and managing enterprise-level applications that are web-oriented and server-centric.
In order to support reuse of domain objects and minimize the impact of interface changes on domain objects. We separate the domain layer (model) from the presentation layer (view.
The Model-View Mode has the following meanings:

• A model with a higher degree of polymerization can be defined so that the definition of the model can be concentrated on the definition of the domain process, rather than the graphic interface.
• Allows concurrent development of models and user interfaces.
• Minimize the impact of changes in user interface requirements on the domain layer.
• Allows you to create a new view connected to an existing domain layer object without affecting the domain layer.
• A model can have multiple views at the same time, such as using SVG and tables.
• The model layer can be executed independently of the user interface layer.

This exactly matches the intention of the observer mode. Therefore, it is necessary to implement the observer mode across layers.
In fact, most applications use the MVC Framework to construct the entire enterprise application. In the MVC framework, there is a dependency between model and view, which is a typical application of the observer mode. Of course, the MVC framework also includes other modes such as composite mode and Strategy Mode. On the J2EE platform, we can regard Web Tier (including JSP, servelet, and JavaBean) as the presentation layer, and EJB Tier as the domain layer. The Controller may span from Web Tier to EJB Tier.
Java. util. observable class and Java. util. the observer interface to implement the observer mode. but if you want to use them in EJB, there will be some problems. As we mentioned in the introduction, the specific implementation of the pattern may change under certain circumstances.

Value transfer or remote reference transfer?
Value transfer:
In Java RMI, all parameters and return types are required to be the basic types of Java or objects that implement java. Io. serilizable. Serialized objects are passed through value transfer (also known as copy transfer) instead of reference transfer, which means that the serialized objects in a layer do not automatically affect other objects.
Remote Reference transmission:
An EJB object consists of two interfaces (home interface and remote interface) and one class. The container generates classes that implement the above two interfaces according to the EJB specification (called xxxejbhome object and xxxejbobject object respectively ). In many container implementation schemes, the xxxejbhome object uses the factory mode to create the xxxejbobject object, and the xxxejbobject object adopts the proxy mode as the proxy class of xxxbean. When the preceding two objects are generated, the container reads the security, transaction, persistence, and other services from the deployment file and adds the code of the preceding services to the xxxejbobject object and xxxejbhome object. The xxxejbhome object and xxxejbobject object are both distributed objects. We will only discuss xxxejbobject objects here. Distributed objects are divided into three parts: Object Server, skeleton, and stub. Here, Object Server and skeleton are on the server, while stub is on the client. The Object Server is responsible for implementing the business logic, and skeleton is responsible for signing the marshal and unmarshal methods.

Figure 2: Distributed Objects

Obviously, the client of EJB (the object that calls EJB) can be any object, including ejbs and general Java classes, or even a CORBA client written in any language.
From the client perspective of EJB, we can only see one home interface and one remote interface (for entity beans, we can also see one primary key class, the bean class is invisible to customers ). However, from the above discussion, we can know that for method calls in the remote interface, xxx_stub class is actually called in polymorphism. That is, the xxx_stub object is visible to the customer (but this visibility is transparent, that is, the customer does not know the existence of this visibility ). Because the xxx_stub object implements the same interface as the object server, and the Object Server actually implements the business logic. Therefore, when the client calls the xxx_stub object method, the xxx_stub object passes the method signature to the xxx_skeleton object through the socket communication mechanism, and the xxx_skeleton object delegates the Object Server to complete the business processing logic. Therefore, the object server itself has changed. We call the xxx_stub object a remote reference of the Object Server object, and think that when the distributed object is passed as a parameter, it is passed through reference (it will produce side effects introduction:
The design pattern is experience documented. It is a description of classes and objects used to solve general design problems in specific scenarios. In more general terms, it is a problem/solution pair. Once we have mastered the design model, we have a strong team of experts. It even allows new object-oriented users to use their previous experiences to find classes and objects with clear responsibilities, so as to get an elegant solution. Because the design pattern is also the goal of reconstruction, if the design pattern is introduced appropriately at the initial stage of design, the workload of reconstruction can be reduced.
However, we cannot fall into the pattern trap. To use the pattern, we will fall into formalism. When using the pattern, we must pay attention to the intent of the pattern (intent), instead of paying too much attention to the Implementation Details of the pattern, because these Implementation Details are under specific circumstances, some changes may occur. Do not stubbornly think that the class diagram or implementation code in the design pattern book represents the pattern itself.
Next, we will discuss why the observer mode should be used in distributed, multi-tier systems.

Multi-tier architecture ):
The three-tier architecture is the simplest of the multi-tier architecture. It generally includes:

• Presentation layer (Presentation)-window, report-
• Business logic layer-manages tasks and rules in a business process. It can be subdivided into the domain object Layer (representing the domain concept) and the service layer (providing database interaction, security, and printing reports ).
• Storage-persistent storage mechanism. Such as database servers.

Figure 1: three-tier architecture

Java 2 Platform Enterprise Edition (J2EE) is an architecture that uses Java 2 platform to simplify the development, deployment, and management of many complex problems related to multi-level enterprise solutions. It is an open, standard-based platform for developing, deploying, and managing enterprise-level applications that are web-oriented and server-centric.
In order to support reuse of domain objects and minimize the impact of interface changes on domain objects. We separate the domain layer (model) from the presentation layer (view.
The Model-View Mode has the following meanings:

• A model with a higher degree of polymerization can be defined so that the definition of the model can be concentrated on the definition of the domain process, rather than the graphic interface.
• Allows concurrent development of models and user interfaces.
• Minimize the impact of changes in user interface requirements on the domain layer.
• Allows you to create a new view connected to an existing domain layer object without affecting the domain layer.
• A model can have multiple views at the same time, such as using SVG and tables.
• The model layer can be executed independently of the user interface layer.

This exactly matches the intention of the observer mode. Therefore, it is necessary to implement the observer mode across layers.
In fact, most applications use the MVC Framework to construct the entire enterprise application. In the MVC framework, there is a dependency between model and view, which is a typical application of the observer mode. Of course, the MVC framework also includes other modes such as composite mode and Strategy Mode. On the J2EE platform, we can regard Web Tier (including JSP, servelet, and JavaBean) as the presentation layer, and EJB Tier as the domain layer. The Controller may span from Web Tier to EJB Tier.
Java. util. observable class and Java. util. the observer interface to implement the observer mode. but if you want to use them in EJB, there will be some problems. As we mentioned in the introduction, the specific implementation of the pattern may change under certain circumstances.

Value transfer or remote reference transfer?
Value transfer:
In Java RMI, all parameters and return types are required to be the basic types of Java or objects that implement java. Io. serilizable. Serialized objects are passed through value transfer (also known as copy transfer) instead of reference transfer, which means that the serialized objects in a layer do not automatically affect other objects.
Remote Reference transmission:
An EJB object consists of two interfaces (home interface and remote interface) and one class. The container generates classes that implement the above two interfaces according to the EJB specification (called xxxejbhome object and xxxejbobject object respectively ). In many container implementation schemes, the xxxejbhome object uses the factory mode to create the xxxejbobject object, and the xxxejbobject object adopts the proxy mode as the proxy class of xxxbean. When the preceding two objects are generated, the container reads the security, transaction, persistence, and other services from the deployment file and adds the code of the preceding services to the xxxejbobject object and xxxejbhome object. The xxxejbhome object and xxxejbobject object are both distributed objects. We will only discuss xxxejbobject objects here. Distributed objects are divided into three parts: Object Server, skeleton, and stub. Here, Object Server and skeleton are on the server, while stub is on the client. The Object Server is responsible for implementing the business logic, and skeleton is responsible for signing the marshal and unmarshal methods.

Figure 2: Distributed Objects

Obviously, the client of EJB (the object that calls EJB) can be any object, including ejbs and general Java classes, or even a CORBA client written in any language.
From the client perspective of EJB, we can only see one home interface and one remote interface (for entity beans, we can also see one primary key class, the bean class is invisible to customers ). However, from the above discussion, we can know that for method calls in the remote interface, xxx_stub class is actually called in polymorphism. That is, the xxx_stub object is visible to the customer (but this visibility is transparent, that is, the customer does not know the existence of this visibility ). Because the xxx_stub object implements the same interface as the object server, and the Object Server actually implements the business logic. Therefore, when the client calls the xxx_stub object method, the xxx_stub object passes the method signature to the xxx_skeleton object through the socket communication mechanism, and the xxx_skeleton object delegates the Object Server to complete the business processing logic. Therefore, the object server itself has changed. We call the xxx_stub object a remote reference of the Object Server object, and think that when the distributed object is passed as a parameter, it is passed through reference (it will produce side effects