Design Patterns in the RIA System

Preface

 

Many developers use design patterns to solve repetitive problems. With the emergence of new technologies, such as Ria, you will have the opportunity to build applications that are closer to your needs.Program. In this way, some models that describe traditional server-based applications will become more focused on client capabilities. Such a change will evolve gradually. Fortunately, the technologies used today also apply to this new model. This articleArticleExplores the differences between traditional server-based applications and RIA models, and also describes their common high-level design patterns. Later articles will focus on special design patterns and how to build rich client applications.

Why is it rich?

Ria is an evolution of web development and deployment models. WWW and HTML were originally used to display information and store it randomly. The Web deployment mode is very useful. However, some development teams can't wait to use HTML to create an application interface. In this way, most applications are meaningless in terms of availability due to the collection of user interfaces and the lack of client data control modes.

In early web application development, developers spent a lot of time solving data transmission, resource allocation, business logic, and other basic problems. As a mature and standard technology to solve these problems, it has produced a more attractive web deployment model. Although it is very mature at the end, the presentation layer is still incomplete. The advent of RIA helps developers have the opportunity to implement functional requirements of the user program interface, create more practical applications, reduce the probability of failure, and increase the number of transactions completed.

There are two rich meanings: rich data models and rich user interfaces. Rich data means that the client's user interface can present and cope with more and more complex data modes, so as to process client operations and send and receive data asynchronously. The advantage is that after the page is created on the server and delivered to HTML, the client program provides users with a better experience than interacting with the server. To achieve a highly complex data model, the client allows you to build a highly responsive and interactive application.

Richer interfaces also provide more improved interfaces. HTML can only provide limited functions for user interface control. On the contrary, Ria allows some creative interface control and cleverly matches the data mode. The traditional Internet mode is a linear design method. The only choice for users is to submit pages to the server in batches. The user experience is terrible under such technical restrictions, and such a program is not required by the user. There are many obstacles to continuously processing server requests and page updates, including page response time, poor network bandwidth, and the increasing daily overhead meeting session or State cross-connection requirements. With rich user interfaces, You can migrate from the early mode in which server response affects the operation mode of the entire interface to the mode that only changes the specific area where the request is sent. Essentially, it means that the interface will be divided into individual components to adapt to local changes, server interactions, and communication between internal client components.

The rich result is that you can create a client interface, which is easier to reflect the data and logic of coexistence of richness and complexity.

Ria Design

Enterprise applications are generally designed in layers based on the organizational program logic. The following is a typical N-layer application model:

Figure 1: Typical N-layer applications

There are three main layers: Client Tier, middle tier, and Enterprise Information System (EIS. Each major layer is divided into several layers based on different logic.
· Containers at the customer layer that contain user interfaces and program Interfaces
· The presentation layer contains the logic for expressing content, processing user sessions, and state management
· The business layer contains the business logic of the system
· The comprehensive layer includes connectors and adapters for accessing remote programs and data sources
· The resource layer contains database information and Enterprise Information Resources and XML files such as ERP.

The structure of a typical network deployment system in J2EE is as follows:

Figure 2: typical web Deployment System

In a network deployment system, the logic for determining program processes, content creation, and content delivery exists in the middle layer, because the main feature of traditional Web applications is a request/Response Model Based on the client browser. To pass the interface, the system needs to format and compile the content in HTML format before it passes it to the customer layer through the middle layer. Any modification to the presentation layer must send a request to the server. The response is the whole page, not just the modification. In traditional network models, the use of Applet, JavaScript/DHTML and other methods to replace the customer-layer solutions has never become mainstream, mainly because of various technical problems, it is mainly about compatibility of different browsers.

The rich customer model can better reflect the program structure, as shown in:

Figure 3: Typical rich client Model

Unlike J2EE programs, client requests may cause the system to generate a page and return to the client. An Ria can support smaller units or components, these components go from small to a voting question to a complete view or interface, the rich customer model breaks down the interface into many small unit modules that can interact directly with users and communicate with servers.

This transformation from application design to a relatively independent page center to a component center will lead to a new level of customer-layer design, it also makes the customer layer more flexible. The rich customer layer is no longer the most terminal for server response, which also improves program performance, the user feels like the program does not need to communicate with the server or only needs to communicate occasionally.

The last Ria model features an event model. Unlike the traditional model, when a server receives a request, it creates a client interface from top to bottom. You do not need to predict the order of events. Since each component is independent, there is no need to respond to the entire view due to a single request. To make each component capable of transmitting information to the server, each component needs to know how to process the information transmitted from the server. In Ria, the interaction data between the client and the server is not synchronized, so that you can control the component creation Information to send to the server and process the server's response, it can control the decoupling and separation of program functions and build a service-oriented program structure.

Design Patterns in the RIA Architecture

In the process of developing traditional Web applications, the design pattern in enterprise development is used to solveCodeReuse problems. Just as Ria evolved from the traditional web model layer, the design pattern used to construct Ria also evolved from this. Here, the term "pattern" refers to a general solution for repeated design issues in software development.

The next section describes how to move functions from traditional front-end controllers and business delegation models to new client models. As with all software designs, you will adopt the appropriate mode as needed. The high-order mode described here targets common problems in client/server communication. The later articles will discuss these client modes in more detail.

The common problems in two types of software development are: how to communicate with the business logic and how to communicate with the client and server. The communication to the business logic requires that the business logic cannot be too tightly coupled with the presentation layer, so that a change (logical or expressive) will affect the entire application. To communicate with the server, make sure that each request contains sufficient information and overhead to establish security, session, or status management. You must determine that each message sent to the server is considered a legal request, or check the message to obtain the identity for the entire application.

Many languages implement the traditional Internet mode, and the J2EE environment is an outstanding one. In the Java environment, you often use a Business Delegate mode to structure the communication with the business logic. The simplest form of this mode is to encapsulate the actual business logic. This encapsulation converts a request sent from the client to an appropriate request to the business logic component. To solve the problem of communication with the server, many people adopt the frontend controller mode. This Mode Directs all requests to a single controller file for security verification and the correct control flow, so that it can make appropriate responses in the form of an HTML page. These two models often work together in a variety of complex structures.

Apart from transferring some behaviors from the server to the client, implementing an RIA architecture is not very different from implementing a traditional Web Client. From the perspective of application design, two high-level modes are highlighted: Service Brokering (service intermediary) and client component to server communication (client component to server communication ). The service intermediary provides a connector for separate component communication. In the communication between Client components and servers, page-level connections are replaced by the connectivity from components to servers. Provides appropriate application interface logic for each component, including asynchronous event processing. Of course, you can also establish a centralized communication structure between your client and the server based on your application needs.

Service intermediary

The main principle for establishing an application is to try to relax the coupling between the business logic and the interface logic, so that the changes in the application interface will not affect the business logic, the business logic does not need to know how it is called. As mentioned above, in the traditional environment, you can use the business entrusting model to solve this problem. In the rich client, you need to consider the needs of components and services.

The requirements for components are as follows:
* Provides a standard excuse for remote services. (Standard trigger method, set callback, etc ).
* Abstract the remote service layer so that it can be local or remote.
* Abstract call methods (soap, RMI, etc ).
* Confusion occurs when access is protected or anonymous.
* Provides operations on components that accept upstream requests.
* Provides a place to connect to the service.

Service requirements include:
* Abstract caller.
* Provides standard methods to trigger callback events.
A design that meets these needs contains two classes, as shown in Figure 4:

Figure 4: Service mediation Design Model

The first category is service mediation, which is responsible for establishing appropriate channels for remote services and maintaining a list of available services and their definitions.

The second category is a bridge component, which is a pipeline between user interface components and services. This bridge component is initialized based on service definitions, and understands how to communicate with a local or remote service, and how to communicate securely through different communication protocols, and the services involved. It includes operations on components, so it can provide a direct callback Method for components when they are successful, fail, or request more information from the service.

Figure 5: Relationship between classes

For a deeper understanding of this Part, a simple bank application is used as an example. It includes multiple user options for users to manage their accounts and send queries to banks. This application is built based on the hierarchical model mentioned above. The user layer provides a rich application interface to authenticate users so that they can view account balance and transaction records and transfer funds between accounts, or record a user service request. The next part describes how to build an interface and focuses on how to build a client-to-Middleware (intermediate level) communication.

The middle layer includes remote services. In the banking case, you can have a customer request service located on different servers, because it is closely integrated with an existing customer relationship management system (CRM ). The purpose of the communication mode is to prevent the client interface from understanding the details of the services surrounding it. In fact, all the information you need is the Service Identifier name, so that you can request a connection to the service through the service intermediary.

The service mediation loads all the services that the application knows from the XML file that describes how to connect to the service, and the identity names used to reference these services. When a customer service request is submitted on the interface, the service intermediary finds the definition of the identifier and generates the necessary information for the connection. The details of other parts of the interface are abstracted.

A client established according to such an organizational structure has great flexibility. For example, you can enhance the service intermediary so that it can detect the connection status of the server and remote requests to the local service, so that the user interface components do not have to know the application status, this allows you to create apps that are connected by accident.

Communication between Client components and servers

When designing the communication between Client components and servers, you must use components as small as possible and with fine granularity to build the interface and have the ability to contain other components, at the same time, keep it * Central Control of component functions
* Central Control of message receipt
* Central control of service communication
* Separate code to control interface logic and event management
This design creates four classes based on the user interface, as shown in:

Figure 6: four types required for client component-to-Server Communication

Their respective responsibilities are as follows:
* The user interface is the place where controls (calendar, data tables, check boxes, colors, and so on) are dependent.
* The View logic contains the code used to operate the user interface, map data to fields, and describe data.
* A local data model is a component that stores data for an application.
* Controllers and coordinator are usually implemented as a component.

-The controller controls all processes for the user interface. It determines how to handle events sent from a remote server or from the user interface.
-The Coordinator is responsible for external communication from components to remote services. The coordinator is also responsible for the methods for callback from remote services.

To design a user interface in this way, no matter in which form you place the components in the interface, the UI components maintain their individual independence. By providing a common abstract interface for individual components, the Coordinator allows the UI components to operate independently or be used as part of a larger interface component. Depicts the client structure:

Figure 7: client architecture

Taking the bank application as an example, it contains an interface component that can submit user service requests to the bank. The service intermediary requests a processor for the remote service from the interface component so that it can run the appropriate method. This interface includes a large number of controls and a button to trigger the RESPONSE event. The view logic of the interface controller can capture this event. When an event is called, it triggers the controller and notifies the view logic to create a local data model for this transaction. After the application prepares the data model, the Controller notifies the Coordinator to submit a user service request and transmit the collected data. The Coordinator contacts the service intermediary to request the appropriate service and pass it an operation handle for itself. When the Coordinator receives a message transmitted from the service intermediary, it sends a message to generate an appropriate request. When the service on the server ends, it transmits the response data message to the client. The bridge adapter directs the Response Message to the Coordinator to determine which method on the controller is called, and then calls the information to change the interface appearance correctly.

Eternal Theme

As a matter of course, any application architecture is gradually getting away from its unique needs and should begin to follow a rigorous design approach. This article proposes two huge client models. You should apply the general ideas they have stated to all application development projects. Later articles will explain more special design patterns and problems they can solve.

Migration to a variety

Software development and the idea of promoting software development to "a collection of technologies and problems" is very important. The traditional web application development model organizes information and program resources to meet broad user needs, but the availability and user experience are often poor. Ria intuitively retains this web deployment mode to respond to user experience. In this way, this concept is centered on how to build applications that focus on new features and user models. There will be minor changes in opinion, and the use of existing backend servers and program structures can also provide a better user experience.