How to Use tcptrace for soap trace in WCF

Source: Internet
Author: User

From: http://www.cnblogs.com/artech/archive/2007/06/14/782845.html

The article is very good. I directly reprinted it. Thanks to the author.

Whether for Web service or WCF, the only form of interaction between client and service is to send and receive soap messages. In our in-depth study of Web Service and WCF, it is necessary to use some soap trace tools to thoroughly analyze soap messages. Among these tools, I think it is best to use the soap trace utility and tcptrace in Microsoft soap toolkit. Let's talk about how to use the tcptrace tool in WCF today.

First, let's talk about the basic principles of tcptrace implementation. To put it simply, tcptrace is a listener/forwarder (Listening/forwarding ). When we start this tool, set the port it listens to, and the host and port (destination Server & Destination Port) it will forward ), then it starts listening to the listening port on the local machine. If an HTTP request for the listening port is sent at this time, it will remove the request content and display it in front of us, the request is then forwarded to our preset host and port.

For WCF, if the client wants to access the service, generally only the client and service are interacted, and the SOAP message is directly transmitted from the client to the service. However, in some cases, we need to add some extra nodes between the client and the service. We will intermediary these nodes. We can use these intermediary nodes to implement some additional functions, such as forwarding different requests to different servers to achieve load balancing ). According to the service-oriented principle, services have a high degree of autonomy (automation). Once a SOAP message is sent by a service, it cannot be controlled by the Service. Therefore, for soap, it requires a high degree of self-describing. It must contain all the necessary control information to guide any node that receives the soap to process it. The infinite extensions of SOAP Headers are indispensable in implementing this function. In principle, any control information can be placed in the SOAP header, header scalability also makes it possible to implement a series of WS-* specification. For each message exchange, addressing is the first problem to be solved. In the intermediary node scenario, two addresses are involved, one of which is the address of the final service endpoint, the other is the address of the intermediary node that actually receives the soap. In WCF, this function is implemented through clientviabehavior. I will discuss it later. In the case of getting soap through tcptrace, tcptrace actually acts as an intermediary node.

Now we will introduce how to use tcptrace.

Suppose we have a calculator service in the local host. The endpoint address URI is: http: // localhost: 8888/calculator (port is 8888 ). In order to give you a specific understanding, I have provided the configuration of the host service:

 

<? XML version = "1.0" encoding = "UTF-8"?>
<Configuration>
<System. servicemodel>
<Services>
<Service name = "artech. exceptionhandling. Service. calculatorservice">
<Endpoint binding = "wshttpbinding" Contract = "artech. exceptionhandling. Contract. icalculator" address = "http: // localhost: 8888/calculator"/>
</Service>
</Services>
</System. servicemodel>
</Configuration>

 

In general, the client has the configuration (Port 8888) corresponding to the following section)

 

<? XML version = "1.0" encoding = "UTF-8"?>
<Configuration>
<System. servicemodel>
<Client>
<Endpoint address = "http: // localhost: 8888/calculator" binding = "wshttpbinding" Contract = "artech. exceptionhandling. Contract. icalculator"
Name = "defualtendpoint"/>
</Client>
</System. servicemodel>
</Configuration>

 

The above is actually the method in which the client directly interacts with the service. What we need to do now is to first send soap to tcptrace, and then send the SOAP message to the real service after tcptrace performs soap trace. You need a special client endpoint behavior: clientviabehavior. Assuming that the port used by tcptrace to listen is 8080, the client implements the clientviabehavior configuration as follows:

 

<? XML version = "1.0" encoding = "UTF-8"?>
<Configuration>
<System. servicemodel>
<Behaviors>
<Endpointbehaviors>
<Behavior name = "calculatorendpointbehavior">
<Clientvia viauri = "http: // localhost: 8080/calculator"/>
</Behavior>
</Endpointbehaviors>
</Behaviors>
<Client>
<Endpoint address = "http: // localhost: 8888/calculator" behaviorconfiguration = "calculatorendpointbehavior"
Binding = "wshttpbinding" Contract = "artech. exceptionhandling. Contract. icalculator"
Name = "defualtendpoint"/>
</Client>
</System. servicemodel>
</Configuration>

 

Now we can perform soap trace. Now we start tcptrace. Set destination server and destination port as the host and port corresponding to the service endpoint. We can even save the trace through the log file.


Then run the service and client successively. You will see the request and response content intercepted by the tcptrace:


In addition, the corresponding content is recorded in the specified log file:

 

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.