Can we identify if WCF Request is coming from our Silverlight APP or some place else?
You could possibly declare a [MessageContract] and define a header in there, which your Silverlight app could set to a known, defined value.
Marc
The headers should already have requester info in them, and you should be bale to parse it out and tick up a counter or whatever on the server side. I would think marc_s's suggestion of MessageContract would be the simpler solution however.
Related
I need to receive XML data from HttpPost requests. Currently I use HttpWebRequest to send the request and I convert the request to xml with StreamReader and XDocument.Parse.
Are there any benefits to switching over to WCF? Thanks!
If you don't plan to dramatically extend your application and only want to switch to WCF so that you are using it, no. :-)
WCF will give you some more flexibility - you could for example consume data in other data formats or from other transport formats (Named Pipes, ...)
I hope i understood your question correctly !!!
The use of WCF lies where you know that both the sending as well as receiving end share the same data contract.
I think in your case, using WCF will benefit if both are MS application and the contract is not supposed to change very frequently.
I want to add a complex poco that will pass itself within each wcf call. Whats the bast practice for this case?
Typically, the best way to do something like this is passing such "meta-information" in a WCF header. You can easily create a message inspector to extend WCF (it's really not that scary and hard to do!) which would inject the POCO class (or what of it is necessary) into every outgoing request from the client, and retrieve it from the header and validate it on the server side.
There are a number of pretty good blog post out there showing you how to create a message inspector:
Richard Hallgren's WCF postings
Writing a WCF message inspector
Automatic Culture Flowing with WCF by using Custom Behaviour
Check out the two relevant interfaces to implement:
IClientMessageInspector on the client side, which has a BeforeSendRequest and AfterReceiveReply message to implement
IDispatchMessageInspector on the server side, which has a AfterReceiveRequest and BeforeSendReply method to implement
Here you go, check this out...
https://kinnrot.github.io/passing-complex-type-through-wcf/
We are using an authentication string (guid) for client identification in our wcf services
and for database lookups.
We dont want to add this to every messagecontract.
Is there a way to do this in wcf?
Regards,
Rune
The best and typical way is to add this to a header in your WCF message - and that would be perfect in a message contract.
Why do you not want to add it to the message contract??
WCF typically encourages a "per-call" methodology - you send all necessary info with your call, each and every call that is. It is discouraged to have any kind of "state" that lingers around between calls.
So again: why not just include your authentication string as a header in every message? That's the preferred way of doing things these days.
UPDATE:
Check out Nicholas Allen's blog post on Adding Headers to a Call. Besides adding them to the message contract, you could also check out the Message Inspector sample he links to, which creates a message inspector that automagically adds those header entries to each outgoing call. No code clutter, no mess, nothing - just works.
I am using WCF as a client for a java web service. I have not control over the server side.
In the response I get from the web service there is no xmlns attribute on the first element inside the soap headers. Because of this WCF returns null as the result of web service call.
Apart from the missing xmlns the response is perfect and if I add the xmlns using fiddler then everything works as expected. I don't know enough about SOAP to know if the xmlns attribute is really required.
Is there a way to avoid this problem, either getting WCF to ignore the missing xmlns attribute or even a hook that would allow me to manually munge the response before it gets to WCF?
This appears to be a pretty old question, so I'm not sure if you ever addressed this. If you are working with a WCF client for a Java Axis service, you will find that you will need to get used to using MessageInspectors to override the behavior of the request and response.
Using the AfterReceiveReply method you should be able to copy the original message and alter the headers. Also check out Step 5 from this MSDN article.
You can't alter the response headers directly in this method as far as I can see, because they are read-only, therefore copying and then replacing the reply with a doctored version is the only way I can think of to correct the missing namespace.
I have a VB.NET web service that calls a third party web service. How can I view the SOAP message generated by .NET before it is sent to the third party web service and how can I see the SOAP response before it is serialized by .NET.
When creating a standalone EXE, I see the Reference.vb file that is automatically generated, but don't see a similar file when my project is a web service. I have found lots of C# code to do this, but none in VB.NET.
Edit - Fiddler and TCP loggers are great, but will not work for my purposes. I need to be able to access the raw SOAP messages from within the application so I can log them or modify them. I need to do more than just see the messages going back and forth.
You can use fiddler or a tcp sniffer to filter and identify all outgoing and incoming traffic on your host.
This is if you want to see the xml request and response.
How about using an extension to allow you to examine the SOAP message?
Accessing Raw SOAP Messages in ASP.NET Web Services
http://msdn.microsoft.com/en-us/magazine/cc188761.aspx
I was trying to do the same thing and this seems to work for me:
Dim message As String = OperationContext.Current.RequestContext.RequestMessage.ToString()
I didn't think it would be that easy since most of the time ToString() returns the name of the class, but I tried it out and low and behold.
I know you asked this back in January so if since then you've figured out a better way let me know.
Please note that if you're catching the exception in a class that implements IErrorHandler then you have to perform this operation from within the ProvideFault() method instead of the HandleError() method because the context is closed before it gets to call the HandleError() method.
Hope this helps.