Legendary WCF (7): "one-way" & "two-way"

The legendary WCF (1): Is this hard to learn?The legendary WCF (2): What about service agreements?Legendary WCF (3): multiple protocolsLegendary WCF (4): send and receive SOAP HeadersLegendary WCF (5): data protocols ()Legendary WCF (6): data protocols (B)Legendary WCF (7): "one-way" & "two-way"Legendary WCF (8): Play with message protocolsLegendary WCF (9): stream and file transferLegendary WCF (10): message interception and tamperingThe legendary WCF (11): Session)The legendary WCF (12): What is the use of server callback?Legendary WCF (13): group chat programThe legendary WCF (14): WCF can also be used as a chat program.

 

Good afternoon, everyone. I'm going to brag again.

The weather was a bit strange this afternoon. Look out the window. Ah, it's dark outside. People in the distance can see the lights in my house, but I can't see people in the distance, this is "one-way communication". I hope to see Sun's sister tomorrow. As a result, I stand on the balcony and can see the sister walking on the opposite roof. The sister can also see me, we say hello to each other, which is called "two-way communication ".

So in WCF, the communication between the server and the client is like my window. There are one-way (single-work) and two-way (Duplex). Well, sorry, I can't, this is a very high level of Iot.

What is the form of expression? The one-way and two-way generated soap are different. Let's put down the code first. But in general, we do not need to study what the generated soap looks like, because these do not require us to do it, and we do not need to be proficient in it and have no practical use, if you are familiar with soap, the girl won't talk about it. We only need to know that some concepts are large. Don't make yourself so painful. People may not have the appearance of Niu B, but they should live with niu B's mentality. In this way, their mental health will become healthy.

 

Although one-way and two-way communication does not have the UI, we cannot see it, but we have some experiments. Why do we need to do experiments often? Only experiments can you get the knowledge that books cannot learn.

In the experiment phase, for example, we do not need to build a web project every time or set up IIS. This is too troublesome. We can understand the principle, I basically use the simplest "console application", mainly for convenience. In order to facilitate the experiment, we know that the code on the server side is almost the same almost every experiment. Therefore, I suggest you do the following two tasks when conducting the research experiment.

1. Run vs as an administrator because administrator permissions are required for running the server. If you do not run vs as an administrator, debugging fails. Switch to the compatibility tab from the shortcut Properties window of Vs, and select Run as administrator ".

Later, as long as you start vs, it will run as an administrator.

 

2. Create a console application, complete the following code, and save it as a project template.

Add the following reference

Enter the following code:

Using system;
Using system. Collections. Generic;
Using system. LINQ;
Using system. text;
Using system. Threading. tasks;

Using system. runtime;
Using system. runtime. serialization;
Using system. servicemodel;
Using system. servicemodel. description;

Namespace wcfservertemplate1
{
Class Program
{
Static void main (string [] ARGs)
{
// Server base address
Uri baseaddress = new uri ("http: // localhost: 1378/services ");
// Declare the server host
Using (servicehost host = new servicehost (typeof (myservice), baseaddress ))
{
// Add binding and endpoints
Wshttpbinding binding = new wshttpbinding ();
Host. addserviceendpoint (typeof (iservice), binding, "/test ");
// Add service description
Host. description. behaviors. Add (New servicemetadatabehavior {httpgetenabled = true });
Try
{
// Open the service
Host. open ();
Console. writeline ("service started. ");
}
Catch (exception ex)
{
Console. writeline (ex. Message );
}
Console. readkey ();
}
}
}

[Servicecontract (namespace = "mynamespace")]
Public interface iservice
{
[Operationcontract]
Int addint (int A, int B );
}

Public class myservice: iservice
{
Public int addint (int A, int B)
{
Return A + B;
}
}

}

 

Choose File> export template]

 

Then a wizard is displayed, and select "Project template" to confirm that your current project name is selected in the project list.

 

Then, continue until the operation is complete.

After saving the template, when you create a new project, you will see the exported project in the Project template. However, it is strange that the template name cannot be used in Chinese during export.

 

The above method is for reference only. Do you have to identify it by yourself.

We compile a service agreement as follows:

[Servicecontract (namespace = "mynamespace")]
Public interface iservice
{
[Operationcontract (isoneway = true)]
Void dotestwork (string message );
}

Setting isoneway of the operation protocol feature to true indicates that the operation is unidirectional. Now, we implement this interface.

Public class myservice: iservice
{
Public void dotestwork (string message)
{
Console. writeline ("messages sent from the client:" + message );
}
}

Add a client project to the solution and reference the service. And test the call.

Static void main (string [] ARGs)
{
WS. serviceclient Cl = new ws. serviceclient ();
Cl. dotestwork ("Nima! ");
Console. readkey ();
}

 

OK. The call is successful.

Next we will return to the server code and change the service agreement and service class to the following:

[Servicecontract (namespace = "mynamespace")]
Public interface iservice
{
[Operationcontract (isoneway = true)]
Datetime dotestwork (string message );
}

Public class myservice: iservice
{
Public datetime dotestwork (string message)
{
Console. writeline ("messages sent from the client:" + message );
Return datetime. now;
}
}

It is still in unidirectional mode, but the operation method returns a datetime structure, regenerate the server, and update the Client Reference to see how the running result is.

 

Haha, this is amazing! We come to the following conclusion from the error message:

The method for enabling one-way communication does not have a return value (void is acceptable) or an out parameter. Only parameters can be input.

 

Now, let's change the operation to two-way communication to see if it can be executed.

[Servicecontract (namespace = "mynamespace")]
Public interface iservice
{
[Operationcontract (isoneway = false)]
Datetime dotestwork (string message );
}

 

Update the Client Reference and modify the call code.

Static void main (string [] ARGs)
{
WS. serviceclient Cl = new ws. serviceclient ();
Datetime dt = Cl. dotestwork ("Nima! ");
Console. writeline ("server reply time:" + dt. tostring ("mm DD, yyyy, HH, mm, SS seconds "));
Console. readkey ();
}

 

This operation succeeds. Both the service and the returned data are called.

From the experiment above, we can see that:Two-way communication requires answers (even if the method returns the void, the client will receive an empty message ).

 

To sum up one sentence --There is always one-way communication, and there are two-way communication.

 

 

 

 

Turn to it