One of WCF technical profiling: simulating WCF infrastructure with a asp.net program

It has been a few months since the article was actually written. For nearly six months, I have been busy with my first WCF monograph "WCF Technical Analysis" writing, has been no time to manage their own blog. So far, the writing of WCF Technical Analysis (Volume 1) has come to an end and is tentatively expected to be published next month by the Wuhan Bowen Viewpoint. In the "WCF Technical Analysis" writing, the WCF has a new feeling, to this end to the title of my third WCF series. The purpose of this series is to "WCF technical analysis" of the supplement, will be some of the content of the book, and will include a lot of space for the reasons reluctantly 割弃 content.

In the first installment of this series, I'll give a general explanation of the basic architecture of WCF. However, as a traditional straightforward of WCF workflow, I will explore the alternative, using the familiar asp.net as the request processing platform, through a simple managed program to simulate the entire WCF client and server-side architecture.

WCF framework processing processes and components involved

Our simulation program will build you into a mini version of the WCF framework to showcase some of the special components used throughout the WCF process. Let's start with a brief introduction to a simple WCF service invocation, the processing process for WCF's client and server-side frameworks, and the use of those important components at every stage of the process.

The following list lists the functionality provided by the WCF server-side framework for handling a simple WCF service invocation request, and the corresponding functionality-hosted components:

Request message receiving and reply message sending: The server listens and receives the request from the customer at the transport layer, and sends the encoded reply message to the client via the transport layer.

Decoding of the request message and encoding of the reply message: The received byte array is decoded to generate the request message object and the reply message is programmed into a byte group. The encoding and decoding of the message is done through Messageencoder, and Messageencoderfactory is responsible for creating the object

The deserialization of the request message and the serialization of the reply message: The request message is deserialized, the corresponding input parameters are generated for the execution of the service operation, and the result of the service operation (return value or Ref/out parameter) is serialized and a reply message is generated. Serialization and deserialization complete by dispatchmessageformatter

Creation of service objects: Creating or activating service object instances, Instanceprovider for creation or acquisition of service objects

Execution of a service operation: invokes the action method of the created service object and passes in the deserialized generated input parameters. Operationinvoker completes the final execution of the service operation

Compared to the service-side process, the client's process is relatively simple, containing only the following three required phases:

The serialization of the request message and the deserialization of the reply message: Generate the request message and serialize the input parameters to the request message, and deserialize the reply message into the return value or Ref/out parameter of the method call. Serialization and deserialization complete by clienthmessageformatter

The encoding of the request message and the decoding of the reply message: Encoding the request message generates a byte array for the transport layer to send, as well as decoding the byte array received by the transport layer to generate recovery messages. The encoding and decoding of the message is done through Messageencoder, and Messageencoderfactory is responsible for creating the object

Send and Reply messages received by requesting messages: sending encoded request messages to the server at the transport level and receiving recovery messages from the server

Figure 1 Compact WCF client and server-side components

Figure 1 reflects the necessary steps to make a service call and the related WCF components that are used. What we need to do in this case demo is to create these components by hand and use them in our own code to build a simplified version of the WCF framework. If the reader can have a clear understanding of the implementation of this case, I believe that the entire WCF framework will not be unfamiliar.

Figure 2 shows the basic structure of this case solution, with a total of three projects. Contracts is used to define service contracts, which are referenced by the service side and the client. The client uses a console to simulate, while the server is implemented through a asp.net website.

Figure 2 WCF Framework simulation case Application Architecture