Im getting confused with WCF, can someone clarify this for me please.
According to Michele Leroux's WCF book the following is true.
"Regardless of the message-encoding format, messages are represented on the wire either as SOAP 1.1 or SOAP 1.2" - I confirmed this by creating a simple net.tcp bound service and used the WCF test client to see the request and response XML.
According to http://www.codemeit.com/wcf/wcf-restful-pox-json-and-soap-coexist.html however, the following is true."webHttpBinding specifies that the service understands generic HTTP requests instead of SOAP requests. The REST service is built on top of generic HTTP request with GET HTTP verb."
So how can both these statements be true?
WCF now has a split personality. The vast majority of it talks SOAP (1.1 or 1.2) and messages end up structured as SOAP on the wire even if the encoder produces something other than XML
However, the WebHttpBinding is special. It uses the Json/POX encoder which strips all of the SOAP framing off the message just sending the message body, however that happens to be structured, down the wire. This means that it can be used to send any content type over HTTP
Related
I have an endpoint that connects to SQL and returns a result set to the client. The WCF Service sets the MaxReceivedMessageSize to a low value and therefore the endpoint does not return a result set.
I fixed the issue by increasing the MaxReceivedMessageSize value. However, I need to see just how much data is coming from the endpoint to the client.
I tried using Postman but that's not working. What's the best way to capture what the endpoint is returning to the client?
Thank you
You can inspect or modify the incoming or outgoing messages across a WCF client by implementing a System.ServiceModel.Dispatcher.IClientMessageInspector and inserting it into the client runtime.
Inspect messages not only implements the inspector on the client side, but also manipulates the endpoint behavior.
I am struggling to understand answer for one question.
.net standard types are first converted to standard messages. This we call Serialization and will be done by one of the WCF serializer.
Those standard messages are converted to stream of bytes . Its called encoding and done by Encoders and which encoder will do that is decided by binding we choose.
My Question is why this serialization is kept in between, Why.net objects are converted to steams of bytes directly by WCF run-time engine and transferred across.
The only thing that connects a client and a server in WCF is the contract and the serialized XML format to exchange messages between the two parties.
WCF is an interoperable messaging service - it cannot rely on anything for the other party. WCF is NOT a ".NET object remoting" system or anything like that. WCF cannot rely on the other side of the communication being a .NET application, so therefore it cannot just exchange .NET objects.
WCF can talk to and serve data for anything - Ruby, Java - whatever. The smallest common denominator for this are serialized XML messages. Therefore, WCF will serialize your messages into a XML format (text or binary) and send them across the wire.
Say I have a service exposing two end points, 1st is a NetTCPBinding the second is any flavour of HttpBinding. They both implement exactly the same service contract.
What is the difference in what is sent on the wire?
Using netTcp is my message still serialised to XML ? Or some binary representation of my objects?
In terms of what receives the messages what is the difference? Will the http endpoint only understand http commands (get/post etc) where as the nettcp end point understands something different?
Why is nettcp more efficient (in this case I dont need interoperability) than http - where is the overhead?
I think that in all cases, before the message is put onto the wire it will be converted to binary so, also http sits on top of tcp in networking terms - so somewhere extra is needed for http communications.
Appreciate the question is a bit vague but hopefully someone will know what I am trying to ask :)
In WCF a particular binding does not necessarily imply a particular encoding. Various bindings can be configured to use various encodings. Net.TCP uses a binary encoding by default (MTOM I think), and HTTP uses a text/xml encoding by default.
With net.tcp your messages go sender -> net.tcp -> receiver. With HTTP they go from sender -> http -> tcp -> http -> receiver. There's an extra layer. The advantage of tcp is both of those: Both the extra layer and the default encoding.
HTTP with a binary encoding approaches net.tcp performance.
EDIT: Actually I think there may also be other optimizations in Net.TCP. It's a WCF-WCF communication scenario, so MS has control of both ends.
I'm contemplating a project where I'll be required to make use of what is variously called the "asynchronous" mode, or the "duplex" mode, or the "callback" mode of SOAP webservice. In this mode, the caller of the service provides in the SOAP header a "reply-to" address, and the service, instead of returning the output of the call in the HTTP response, creates a separate HTTP connection to this "reply-to" address and posts the response message to it. This is normally achieved in WCF using a CompositeDuplexBinding, like so:
<binding name="async_http_text">
<compositeDuplex clientBaseAddress="http://192.168.10.123:1234/async" />
<oneWay />
<textMessageEncoding messageVersion="Soap12WSAddressing10" />
<httpTransport useDefaultWebProxy="false" />
</binding>
This results in not one, but two HTTP connections per call: one from the client to the service, and then one from the service back to the client. From the point of view of the service implementation, nothing changes, you have a method that implements the interface method, and you take in the request and return the response. Fantastic, this is what I need, almost.
In my situation, the request and response can be separated by anything from minutes to days. I need a way to decouple the request and the response, and "store" the state (message, response URI, whatever) until I have enough information to respond at a later time (or even never, under certain circumstances).
I'm not terribly excited about having my methods essentially "paused" for up to days at a time, along with the required silly timeout values (if they're even accepted as valid), but I don't know how to go about putting a system like this together.
In order to be completely clear, I'm implementing a set of standards provided by a standards body, so I do not have flexibility to change SOAP message semantics or alter protocol implementations. This sort of interaction is exactly what was intended when the ReplyTo header was implemented in WS-Addressing.
How would you do it? Perhaps Workflow Foundation enables this sort of thing?
In such case don't use HTTP duplex communication as defined in WCF. It will simply not work because it is dependent on some other prerequisities - session, service instance living on the server, etc. It all adds a lot of problems with timeouts.
What you need is bi-directional communication based on fact that service exposes one way service and client exposes one way service as well (services can be two-way to support some kind of delivery notification). You will pass client's address in the first request as well as some correlation Id to differ multiple requests passed from the same client. You will call client service when the request is completed. Yes, you will have to manage all the stuff by yourselves.
If you are in intranet environment and your clients will be Windows based you can even think about changing your transport protocol to MSMQ because it has built-in support for all these requirements.
Edit:
I checked your updated question and you would call your communication pattern as Soap Messaging. I have never did it with WCF but it should be possible. You need to expose service on both sides of the communication - you can build your service to exactly follow needed contracts. When your service receives call you can use OperationContext.Current.IncommingMessageHeaders to access WS-Addressing information. You can store this information and use them later if you need them. The problem is that these information will not contain what you need. You have to fill them first on the client. This is generally possible by using OperationContextScope and filling OperationContext.Current.OutgoingMessageHeaders. What I'm affraid is that WCF can be "to clever" and override your changes to outgoing WS-Addressing information. I will probably try it myself during weekend.
It turns out the Windows Workflow Foundation (v4) does indeed facilitate this sort of message exchange.
Because WF allows you to decouple the request and response, and do basically whatever you want in the middle, including persist the workflow, idle it, and go outside and cut the grass, you get this capability "for free". Information can be found at these URLs:
Durable Duplex (MSDN)
Workflow 4 Services and duplex communications
Is there a way to intercept the raw data that's being sent over a TCP WCF endpoint? I have implemented IClientMessageInspector but I am not sure if that's what's actually being sent over the wire.
My goal is to measure the performance of different serializers. I know there is some information out there but I would like to take a closer look at how they behave in my app.
Enable Message Logging in your configuration. To see the raw messag you want to log at Transport level.
You probably want to look into the built-in tracing capabilities of WCF. I don't have a link handy, but search for WCF tracing.