I have a WCF service. When it gets called I would like to append a unique ID of a particular call to the log.
Is there some built in way to get a unique id or GUID for a specific call to a WCF service. It is hosted in IIS, if that makes any difference.
The OperationContext.Current.SessionId only works in situations where the binding supports it, in my case I am using a basic http binding, so its a no go.
Thanks in advance
FWIW, if you enable end-to-end tracing in WCF, it will add an Activity ID SOAP header to the message.
Related
We have developed the wcf service with the existing web service code. the existing customer wants to consume that service only changing the new url. They do not want to replace the proxy class. is it possible in any case.
The customer is able to consume the same with replacing the proxy and config. but he does not want to replace the proxy. please share ur comments whether it is possible or not.
You may be able to do this by configuring an endpoint using basicHttpBinding. I believe you will also need to force the use of the XML Serializer, and I don't know how to do that offhand, so someone else will have to help you with that. I'm concerned that there could still be small differences that would cause errors using the same proxy class.
On the other hand, if performance isn't the top consideration, you could create an ASMX service using the original class and method attributes from the old service. This ASMX service would then call the WCF service.
BTW, the ASMX service could call the WCF service on a fast endpoint. If they were running on the same server, they could use netNamedPipesBinding, for instance, but in any case could use netTcpBinding, which uses binary over TCP/IP. That would mitigate the performance difference from the extra hop.
The goal I'm working toward is having a WCF routing service that can receive messages from clients, persist them to some type of data store, and then process/send them to their destination WCF services.
Things to consider:
You can create a routing service by using the ClientViaBehavior (outlined here and here)
The ClientViaBehavior will not work with basicHttpBinding, so I need to use wsHttpBinding (basicHttpBinding doesn't set the "To" header on the message, found out the hard way)
The WCF Message object itself is sent to the Routing Service, where it can be persisted as a serialized string
I don't want the Routing Service to know what's in the message - consequently, the service will not have a reference to the Data Contracts involved
When the time comes to route the Message to its destination, I need to be able to create a channel between the Routing Service and the Destination Service
It is not desirable for the Routing Service to be aware of each destination service - ideally, WCF could create the proper channel dynamically based on the content/headers of the message being processed.
Is this too much to ask of WCF? (I have a feeling it might be...)
Any advice on how to accomplish something like this would be appreciated.
If you're on .NET 4 (or can move to it), WCF 4.0 has introduced a RoutingService infrastructure of its own.
Check it out, before you re-invent the wheel!
See A Developer's Introduction to Windows Communication Foundation 4 for a great general intro to the new features (including RoutingService) in WCF 4
Yes, you can make your routing service accepts any message.
This link should help you: Building a WCF Router, Part 1
I am developing a wcf service (basicHttpBinding) that should also be consumed by non .net clients (e.g. Java clients). But now I wonder how the client can define his client config file. Or is this file only needed for .net-clients? (I am thinking of configurations like maxReceivedMessageSize or maxItemsInObjectGraph for example).
Each development platform (call it as you want: SOAP stack, Framework, API) has its own way to configure communication. You don't need to bother with it. You just need to expose correct WSDL and client's developer will be responsible for configuring the client application based on his needs.
If you want to extend documentation of your service in WSDL you can use wsdl:documentation. WCF doesn't offer it by default but you can use this technology sample to extend WCF. You can use such documentation for example to describe that service operation can return large amount of data. Another approach to add wsdl:documentation is using WCF Extras.
From the sound of it, the client shouldn't have access to those configuration options. For instance, why should a client to the WCF service be able to specify the maxReceivedMessageSize?
What you probably want to do is define these configuration options on the server-side. If a client makes a call and there is a conflict with one of your options (i.e. the client exceeds maxReceivedMessageSize), you'll want to throw a SoapException back to the client.
If you want to let the client have access to the configuration settings before he or she sends a request, you can always implement a simple web service method that sends back the values.
Is there any way to enforce that a method call in soap based wcf is called as an HTTP get? I'm not sure if this would be handled on the client or server side. We wanted to have the wcf call process as a get vs. post for cacheability, etc.
I'm also not sure how to monitor a wcf service to determine if calls are doing gets or posts (or if it always does one or the other). Can I use fiddler for this?
I would imagine I could use a restful wcf service to wrap the call, but I wasn't sure if there was a way to do it straight in a soap based service.
Out of the box WCF functionality does not support SOAP HTTP GET. But WCF is extensible so you can try to develop custom binding (with cutom channel or behavior) supporting this feature.
Caching is supported in WCF 4 REST services. REST services allow all basic HTTP methods.
You can use Fiddler to monitor the gets and posts.
Check out this post about calling a WCF service with an HTTP GET.
I need to upgrade our web services to use WCF instead of ASMX. If the signatures of the web services stays the same, will existing clients that already call the ASMX service have to change anything on their end? Is there anyway to still use WCF but not force them to change anything?
Option 1 :
Using the current ASMX's WSDL, generate the client using svcutil.exe
Grab the generated interface and create a WCF service based on this interface
Output : One new WCF endpoint configured with basicHttpBinding. Clients need to update the URL at which they're sending the messages.
Option 2 :
Refactor your ASMX code. Move all the logic into a separate DLL.
Create a WCF service and use the logic in the refactored DLL.
Output : 2 endpoints, one for ASMX and another one for WCF
If you use the BasicHttpBinding for your new WCF service, and implement the same methods with the same message structure, existing callers should be able to call into this new WCF service without any change on their part.
There's also an AspNetCompatibilityRequirements attribute in order to get around some potential compatibility issue - see the MSDN documentation on it.
Marc