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/
Related
I am using a web application as a client to invoke WCF methods using proxy.
For each request being made by client object, I need to populate few properties (declared inside request class)
Is it possible to hook a method, just before making the actual web service call.
I can't modify service code right now, Can WCF extensibility points could be leveraged in this case?
Thanks for your help.
If you want to change the properties of the method parameters, you can use an IParameterInspector to do that, since at that point you'll get an array with all parameters to be sent to the server.
If you need to change other parts of the request (such as transport or SOAP headers), an IClientMessageInspector may be the best way to go.
For more information on many extensibility points at the client side, you can check the blog series at http://blogs.msdn.com/b/carlosfigueira/archive/2011/03/14/wcf-extensibility.aspx.
What's the use of action/reply action for service operation in WCF. So far, what I've understood is; action is used by WSDL to identify the service operation to which the message from the client belongs and in return reply action is used by service operation to identify the caller to which reply message belong --> Please correct me if I am wrong with this!
Now, I want to understand; what's the real use (apart from handling anonymous messages by using aster ix [*]), I mean this could well be handled internally by WCF instead of exposing it to the developer.
Also, why is action and replyaction required at all? I mean, we already have a name property for the service operation to identify the method and when I call Proxy.SomeMethod() then somemethod is already mapped to the Name property and it should be enough to identify the destination method for the message and similarly the replyaction. Please clarify.
Can I please get a simple real world scenario/or link to that to understand Action/ReplyAction in real life.
Many Thanks.
Actions are part of the various SOAP and WS-* specifcations.
So the first point is that this is not something unique to WCF it is a standard part of the specification you need to support if you want to have interoperable web services. They are used for message routing and other message handling functions.
Second, WCF DOES manage these by default. You only need to specify them yourself if you wish to customise or manage them in some other way. E.g. WCF will automatically generate them into the WSDL for you. WCF will also use them by default when it is selecting which operation to invoke for an incoming message. Again, WCF provides extension points to customise this behavior if you require.
I have a WCF Service that exposes two endpoints. One with a WebHttpBinding (acting as a REST service for mobile clients) and one with a NetTcpBinding (used for desktop .NET clients)
Let's say that a client accesses the service method GetData. If there is no data I will return ´null´ (or false or ´0´ depending on what has been called). If the client is a mobile client accessing the WebHttpBinding-endpoint, I would like to change the HttpStatusCode to something other than OK.
Is there a way of doing this and still keeping my service implementation general (not putting any http-specific code there)? I know that I can use IDispatchMessageInspector to intercept the message and change the status code, and only do this for the WebHttpBinding-endpoint, but then I wouldn't really know what to change the status code to...
Is there anyone who has a suggestion as to how I can solve this?
Update:
I'm starting to think that there really is no way to do this in a nice way, since the only place I actually really know what when wrong is in the service implementation.
Edit: the nice way: Seperation of concerns (SoC). The REST implementation only adds REST concerns to the service and inherits the base implementation which does the whole business logic.
I need to provide non repudiation in my WCF services and want to store all my incomming SOAP requests into a SQL server DB with signature/security data and all the envelope stuff.
This way, when a problem occurs, we can tell to the client "Hi, THIS is your signed message" exactly as you wrote it.
To do this, I need to store a relationship between the SOAP envelope XML's and my persisted bussiness objects/transactions.
Example: THIS is the SOAP Envelope used to add Customer ID=4567 to my Customers datables.
I need to establish a link between SOAP envelope and the bussiness transaction performed by my app. Storing ##identity of the logged message could be a solution. But, where do I put it? In the SOAP Body? Keep it in memmory?
I've reading about logging in WCF and wrote a Database Logger that inserts into tables the log info instead a text file, but i don't know how to link this data with the parsed/deserialized bussines datacontract object that arrives to my WCF service's method.
I don't even know if this is the rigth approach!
Any pattern/tip/hint/tool/help would be appreciated.
Thanks.
If you have enabled the message logging feature of WCF (http://msdn.microsoft.com/en-us/library/ms730064.aspx), you can write a custom listener, and there add all the logic you need. To write a custom listener you only have to implement the TraceListener interface (fairly simple) and then configure WCF to use it, adding it to the listeners section inside the system.diagnostics, replacing the default listener.
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.