The broker model for distributed schemas

Http://blog.chinaunix.net/uid-23093301-id-90459.html
Problem Source:

Create a game system that will run in the Internet environment. The client connects to the game server through the WWW service or the specific client software, and as the traffic increases, the system expands continuously, and the final background data and business logic are distributed deployment. However, compared with the centralized system, the complexity is inevitably increased, how to reduce the coupling between the components. Challenges:

The need to ensure scalability, maintainability, and scalability, the need to divide services into relatively independent components, components are distributed deployment, between them through interprocess communication between the implementation of interaction. Service additions, deletions, and changes should all be supported. Ideally, a centralized and distributed system is no different in the central logic of a developer's perspective. To achieve this goal:

L can access services remotely, and for visitors, the location of the service should be transparent.

• Components that provide services can be added, deleted, and changed, and should also be supported during runtime.

The client that accesses the service should not care about the implementation details of the service. Solution:

Introduce a broker component to decouple the client and server side. The server registers itself to broker, allowing the client to access the service by exposing the interface. The client sends the request through broker, which forwards the request-side service and sends the requested result or exception back to the client. By using the broker pattern, applications can access remote services by sending messages.

This architecture pattern allows for dynamic changes, additions, and deletions of services, which are transparent from the client's perspective. structure:

The Broker pattern defines the class in 6: Client,server,client_proxy,server_proxy,broker,bridge. Server :

L Responsibilities: Handle specific domain issues, implement service details, register yourself to broker, process requests, and return results or exceptions.

L Collaboration class: Server_proxy,broker Client:

A client is an application that requires access to a remote service, for which the client sends the request to broker and receives a response or exception from the broker. The client and server are logically related, but the client does not know exactly where the server is.

L Responsibility: 1. Implement client-side functionality, 2. Send request to broker,3. Receive the corresponding and exception.

L Collaboration class: Broker,client_proxy Broker:

Broker can be viewed as a message forwarder. Broker is also responsible for some control and management operations. It can locate the service side and, if an exception occurs, can pass the exception capture to the client. Broker needs to provide the interface for the registration service to the server. If the request comes from another broker, the local broker needs to forward the request and eventually respond to the corresponding remote broker with the result or exception. The services provided by broker are very similar to the name service (for example, DNS, LDAP).

L Responsibility: 1. Registration service. 2. Provide the service API. 3. Forwarding messages. 4. Fault-tolerant processing. 5. Interaction with other broker. 6. Positioning service.

L Collaboration class: Client_proxy,server_proxy,bridge client_proxy:

Connecting client and broker, this layer guarantees the transparency of the communication and makes the client invoke the remote service as if it were a local service.

L Responsibility: 1. Encapsulates a particular system call. 2. Package the communication parameters, control information and so on.

L Collaboration class: Client,broker. Server_proxy:

Server_proxy is corresponding to the client_proxy, it accepts the request, unpack the message, parse out the parameters and invoke the service implementation interface.

L Responsibility: 1. Encapsulates a particular system call. 2. Package the communication parameters, control information and so on. 3. Call the server's service interface.

L Collaboration class: Server,broker. Bridge :

Bridge is used to connect individual broker, and this component is generally optional. This role may be required when the system is made up of miscellaneous networks.

L Responsibility: 1. Encapsulates a specific network feature. 2. Transfer of communication between broker.

L Collaboration class: Broker. Application Scenario One:

Direct communication methods. Client and server understand each other's communication protocols. Broker mainly completes the handshake between client and server. All messages and exceptions are then directly interacted by the client and the server. (imagine DNS). Simple object interaction is shown in the diagram:

Application Scenario Two:

L Broker starts, completes its own initialization, then enters the event loop and waits for the message to arrive.

L Server starts by performing its own initialization and then registering itself to broker.

L Broker receives the registration request from the server, adds it to the list of available services, and responds to the ACK to the server.

L server receives ACK, enters event listening loop, waits for message arrival.

L Client invokes the remote service object's method, Client_proxy encapsulates the message and sends it to broker.

L Broker queries a server that can be used to send a request to the server.

L Server_proxy Parse messages, isolate parameters and control information, and invoke specific Server implementation interfaces. The results of the server's processing are forwarded to the server via Server_proxy encapsulation as messages.

L Broker forwards the corresponding message to the correct client_proxy,client and the response continues to other logic.

Simple object interaction is shown in the diagram:

Application Scenario Three:

L Broker A received a request to be processed by the server, but found that the server is located on another network node.

L Broker A sends the request to bridge A,bridge A to format the request as necessary and transmit it to bridge B.

L Bridge B Formats the request as necessary and translates it into a format that broker B can understand and is forwarded to broker B. Broker B Executes the procedure in scenario two, and the results of the processing are returned in reverse order.

Simple object interaction is shown in the diagram:

deployment diagram:

Summarize: