Sound
This chapter is translated by netizens withwind, the author is responsible for the subsequent article.
--------------------------------------------------
Design mode in the RIA architecture
During the development of a traditional web application, the design pattern in business development is used to solve the code reuse problem. Just as RIA is evolved from the traditional web model layer, it is used to construct the RIA's design model to evolve. Here, the noun "mode" is used to refer to a general solution to resolve the duplicate design problem.
The next section describes how to transfer features from traditional front-end controllers and commercial commission patterns to new client patterns. As with all software design, you will adopt an appropriate mode as needed. The high-order patterns described herein are for universal problems in the client / server communication; the later articles will discuss these client mode more detailed.
The universal problems in the development of two software are: how to communicate with business logic and how to communicate with the client and server. To establish a communication to business logic, require business logic to be unacceptable to the performance layer is too close to a change (regardless of logical or performance) affects the entire application. Communicates with the server, you need to make sure that each request contains enough information and overhead to establish secure, sessions, or status management. You must determine that each message sent to the server is considered a legal request, or an inspection message for an identifier for the entire application.
Many languages have realized traditional Internet mode, and the J2EE environment is a kind of especially excellent. In a Java environment, you often use a business delegate model to structure communication with business logic. The simplest form of this mode is to make a package outside the real business logic. This package converts a request from the client into an appropriate request for business logic components. In order to solve the problem with the server communication, many people use front-end controller mode. This mode boots all requests to a single controller file to perform security validation and establish the correct control flow so that it can make an appropriate response in a form of an HTML page. These two modes often work together under various complex structures.
In addition to transferring some behavior from the server side to the client, there is no big difference between a RIA architecture and implementing a traditional web client. From the perspective of an application design, two high-level patterns are highlighted: Service Brokering (Service Agency) and Client Component to Server Communication (Communication for Client Components to Servers). The service intermediary provides a connector for individual component communication. In the communication of the client component to the server, the page level connection is replaced by providing connectivity from the component to the server. For each component, provide appropriate application interface logic, including asynchronous event processing, and more. Of course, you can also establish a centralized communication structure in your client and server communication according to your application.
Service broker
One main principle to establish an application is to try to relax the coupling of business logic and interface logic, so that the application interface changes will not affect business logic, and business logic does not need to know how it is called. As mentioned above, in a conventional environment, you can solve this problem with commercial entrustment mode. You need to take into account the needs of components and services. The needs of components are as follows: * Provides a standard excuse for remote services. (Standard trigger method, set up callback, etc.). * Abstract remote service layers allow it to be local or remote. * Abstract call mode (SOAP, RMI, etc.). * Creating confusion when covering or anonymous access. * Provide the operation of the components that accept uplink requests. * Provide a place to connect to the service.
Service requirements include: * Abstract caller. * Provide standard methods to trigger the callback event.
A design that meets these needs contains two types of classes, as shown in Figure 4: Figure 4: Service intermediary design mode
The first class, service intermediary, is responsible for establishing an appropriate way to remotely serve, and maintains a list of available services and their definitions.
The second class is a bridging component that is a user interface component and a service between services. This bridging unit is initialized based on service definition and understands how to communicate with a local or remote service, as well as how to communicate securely through different communication protocols, and which services involved. It includes the operation of the component, so it provides a direct callback method for the component when it is successful, failed, or requested more information from the service.
Figure 5: Relationship between class
In order to understand this part, this is an example of a simple banking application. It includes multiple user options for users to manage their accounts and ask for queries to the bank. This application is built according to the hierarchical model mentioned above, providing a rich application interface to authenticate the user, enabling them to view account balances and transaction records, as well as transfers money between accounts, or record a user service request. The next part will describe how to establish an interface and focused on how to establish a client-to-middleware (intermediate level) communication.
The intermediate layer includes a remote service. In a bank case, you can have a customer request service in different servers because it is closely integrated with an existing customer relationship management system (CRM). The goal of the communication mode is to prevent the client interface from understanding the specific conditions of the service surrounding service. In fact, all the information you need is the name of the service, so you can request a connection to the service through the service intermediary.
The service intermediary from describing all the services you know from the XML file connected to the service, and the identity name used to reference these services. When the interface is submitted to the customer service request, the service intermediary finds the definition of the identity and generates the necessary information of the connection, and the details of the abstract processing of other parts of the interface.
A client established in this organization has great flexibility. For example, you can enhance the service intermediary so that it can detect the connection status of the server and remote request to the local service, so that the user interface component does not have to know the application, allowing you to create an accidental connection. (Please pay attention! Quote, transfer this article to note: rosen Jiang and the source: http://blog.9cbs.net/ROSEN
