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.
Related
Can I listen to a WCF event from a web client? Is this possible? I am not talking about call backs, I want the WCF service to raise and event and the web client to be able to listen. Is there a good example of this in C#?
There are no events in WCF. If you want mimic event you still have to call some operation exposed on all clients = you must call WCF service or callback exposed on client.
What do you mean by web client? Do you mean javascript code running in web browser? In such case no you can't achieve that with WCF. You can only use AJAX calls from borowser and continuously poll the service for possible "event".
If you mean ASP.NET application then the answer is theoretically yes, practiacally it will be pretty hard. The reason is that in ASP.NET you handle only current HTTP request by some handler - for example Page. The lifetime of the handler is only for serving the single request. Due to that using duplex service doesn't make to much sense because for receiving callbacks by duplex service your client proxy must live. If you open the proxy in Page it will die after serving the request. If you open the proxy in separate thread you must somehow corelate incomming callbacks to actual client but the client still have to poll the web server to be notified about callbacks. Similar situation will be with exposing the service on ASP.NET application.
Difference between asynchronnous and duplex calls is big. In asynchronnous pattern single request always have single response. Resonse is not sent without request. In duplex pattern you can make single request and receive thousands callback from server.
Is it possible to post to a WCF service hosted in IIS? I know that that this is possible using REST but I really need the WSDL generation and SOAP headers. I need to transition an existing ASMX web services to WCF but I need to also allow my clients to continue to utilize the service via http posts (xml http request via javascript). Is REST my only option?
No, with a SOAP service, you need to use the SOAP methods and actions - you cannot use HTTP POST to "dump" some data on a SOAP service.
If you need HTTP POST, then REST is the way to go.
You can also use REST style WCF
http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
I want to create a create a WCF Service which is invoked on the button click of MS Access Form.
You CAN consume WCF services through MS Access, but not via standard WCF mechanisms. You'll need to consume the service via GET requests, POST requests, or SOAP requests.
One way to accomplish this for SOAP requests on the Access side is using the SOAP toolkit:
http://msdn.microsoft.com/en-us/library/aa140260%28office.10%29.aspx
Another way that would work for GET, POST or SOAP requests is using XMLHTTP (if you go the SOAP route, you'll need to make your own SOAP envelope in the XML):
http://www.codemaker.co.uk/it/tips/ado_conn.htm (search for XMLHTTP)
On the WCF side you have a couple of choices:
Host a WebHttpBinding service. This gives you options to expose GET and POST endpoints for your services. See http://www.windowsitpro.com/article/net-framework2/exposing-classic-http-endpoints-with-wcf-in-net-3-5.aspx.
Host a BasicHttpBinding service that exposes a SOAP endpoint (this is the default WCF endpoint if you create a new service in Visual Studio). If you go this route, you probably want to set it to use legacy XML serialization and WSDL for compatibility if you go with option 1 on the access end (see http://msdn.microsoft.com/en-us/library/system.servicemodel.xmlserializerformatattribute.aspx).
One other thing to note: If you create a BasicHttpBinding WCF Service with XmlSerializerFormatAttribute, you are basically getting (from a data exchange standpoint) the same thing as if you were to write a legacy asmx service.
You cannot consume a WCF directly with MS Access.
If you own the WCF service, you would have to change it to a web service using HTTP bindings.
If you don't own it, you will have to write your own web service that is basically a wrapper around the WCF.
Then you can consume it as a web service in MS Access.
Folks,
I'm building a pretty standard workflow that I want exposed via a WCF endpoint - I'm using the "WCF Service Application" project template and I've got a .xamlx service. This is a very simple document interchange workflow service - I want consumers to POST me a blob of XML as the body of an HTTP post (with HTTP headers containing authentication tokens). In response, these consumers will get a blob of XML containing the reply. 2 goals for me using REST/POX here are the document/message-based nature of the interaction AND I want to make client development easy for non-.NET environments (especially limited environments like Silverlight and iPhone).
I don't really see how to make this possible using out of the box features (unless I'm missing something). Does anybody know how to create a RESTful (or even REST-ish, I'm not picky) endpoint for a WF4 service-hosted workflow? Any info leading in the right direction here would be great.
There is an unreleased item on CodePlex to cover this, which includes source code. Also see this SO answer which contains another idea for achieving this.
If you'd like to see the CodePlex activity released, please up-vote the UserVoice request.
Using a REST Pass-Through Service
As #Maurice mentions, you can also treat the WF service as a back-end service and expose a REST service that simply calls through to the WF service.
This method is a bit clumsy, but has the advantage that it doesn't use anything unreleased or really complicated.
If the back-end service runs on the same machine as the REST service (which is probably what you'd do), you should expose the WF service using the named pipes binding. This binding is fast, but only works when the caller and callee are on the same box.
A further thought: your REST pass-through service is blocked while the back-end service is being called. If your WF service is not very fast, you'd benefit from making your REST service asynchronous so it doesn't block a thread pool thread while the WF service is being called.
There are no out of the box activities that will allow you to use REST with WF, the Receice is pure SOAP.
You can either build a custom REST Receive activity and use that with your workflow. Depending on your needs this is going to be quite a handful to a lot of work. The easy option is use use a standard REST WCF endpoint and convert the REST data to SOAP, pass rhe request on to the workflow, and do the reverse on the result message.
I have a WCF service which would like to support basicHttpBinding and webHttpBinding. When the client successfully login, server will generate a token for client to pass to server on all the request make later. Question is how the client can pass the token to server? I don't want to add an extra parameter on every web method to hold the token.
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 token 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