Go to. NET Architecture Design-Chapter 6-service layer design (Part 2)

Go to. NET Architecture Design-Chapter 6-service layer design (Part 2)

The previous article introduced some basic knowledge of the service layer and briefly introduced the knowledge of SOA. This article mainly introduces some modes that can be used in the service layer.

This topic is as follows:

Fa C ade Mode

Document Message and Request-Reponse Modes

Reservation Mode

Idempotent Mode

 

Fa C adeDesign Mode

In the design of the SOA client, the most common mode is the Fa C ade mode. The Fa C ade mode simplifies the calling interfaces of complex subsystems. In other words, Fa C ade hides the complex relationships between subsystems and provides a simple calling interface for the client.

The advantages of the Fa C ade mode are as follows:

1. It allows third-party class libraries to be packaged and called through a simple interface, as shown in.

2. It can decouple dependencies between other systems through abstraction and other methods.

3. It hides the call complexity between subsystems and can be called through a simple interface, as shown in

 

 

 

In the figure above:

1. The client calls a Simple API of Fa C ade to execute a task. The client does not know how Fa C ade is implemented internally. The execution of only one task may involve the interaction and cooperation of many internal subsystems.

2. sub‑ema and SubSystemB are the real task executors.

 

Next we will look at some of the communication modes between the client and the service layer.

Note: An example of how to use these modes is given after you have finished speaking these modes.

 

Document MessageAnd Request-ReponseMode ("Document message mode"And"Request-Response Mode ")

Before learning about the benefits of "document message mode", let's take a look at a communication method: RPC (Remote Procedure Call Remote process Call ): the RPC method provides different services by exposing APIs with different parameters, as shown below:

 

Customer [] RetrieveCustomers (string country );
Customer [] RetrieveCustomers (string country, string postalCode );
Customer [] RetrieveCustomers (string country, string postalCode, string street );

 

 

The preceding service interface allows the client to obtain user information in three ways: by providing different parameters. It is difficult to maintain this method, and the client is often confused, and the server may finally expose many methods with the same name to the client, although you can change the method to display the client name in WCF, the method is still prevalent.

 

The "document message mode" allows clients to communicate with services in a unified and flexible manner. The "document message mode" encapsulates all request information from the client into an information body and sends it to the server. The interface definition of the server is also very simple, as shown below:

Customer [] FindBy (CustomerSearchRequest request );

 

The message body is defined as follows:

 

Public class CustomerSearchRequest
{
Public string Country {get; set ;}
Public string PostalCode {get; set ;}
Public string Street {get; set ;}
}

 

 

Sometimes the message body carries additional information to the server, such as the service version number and Authentication Authorization ID. Of course, we can define the basic information of a request message and integrate all request messages into the base class.

 

By using the "document message mode", we have solved some of the previous RPC problems. Of course, the server must process the messages.

"Document message mode" is generally used together with "request-response mode. For example, in the previous example, we directly returned the array of Customer. In fact, sometimes we may not want to expose the definition of the business class, and we may need to add additional information to the client, then our server interface is defined as follows:

 

CustomerSearchResponse RetrieveCustomers (CustomerSearchRequest request );

 

 

In fact, many examples of code in some previous chapters demonstrate the use of such a pattern.

You can see the common "document message mode" and "request-response mode" icons:

 

 

 

 

 

ReservationMode (Reservation reservation Mode)

In general, servers in SOA are stateless, but sometimes we need the server to save some statuses of a long-running service. During this period, the client may send many requests to the server as a transaction or a unit of work.

 

The Reservation mode solves the following problems:

1. We can send a request to the server to obtain a unique reservation number from the server response.

2. This number is included in the remaining client requests so that the server can handle these requests as a transaction.

Generally, the reservation number has a certain period of time. That is to say, after a period of time, the number will expire on the server side, this is mainly to avoid resource consumption and some security issues.

Let's take a look at the figure using the Reservation mode in the following online ticket booking system:

 

 

 

 

 

In:

1. The client first calls the ReserveTickets service method and provides some basic information to the server: Subscribe to two tickets.

2. The server returns an appointment Id and an expiration time in response.

3. The client executes a logic. These logics may take obtaining the details of a customer as a ticket booking process, or conduct more complex client-to-server interactions.

4. Finally, the client submits the information required by the server together with the booking Id, calls the PurchaseTicket method, and then the server returns the ticket booking success number.

 

The above example may not be very appropriate. You just need to understand what it means.

 

　　Idempotent Mode(Idempotent Mode)

When calling a service interface, you may use the same parameters to call the same service interface multiple times. In this case, it may be what we want, but it may not be what we want. For example, in the order system, for some reason, the user submits the same bill multiple times (for example, accidentally clicking the submit button multiple times ), data in the system becomes a problem. Therefore, you can use the Idempotent mode to ensure that the same parameters are submitted multiple times, but the server only processes them once.

The basic idea of the Idempotent mode is as follows: each client request is assigned a unique request identifier (for example, the generation rule of this identity may be generated using some algorithms of the request parameters ). When the server checks the unique identifier in a storage area, it has been processed and whether there is corresponding response information. If yes, the response information is directly returned. If no, then process the request.

As shown in:

 

 

 

 

I wrote it here today, and the next article began to use WCF for a Demo.