We have a problem in integrating a wcf service in a web service firewall.
Because the wsdl of the service does not contain the operations for ws-trust (requestsecuritytoken, ..).
How can I force WCF to include all details in its wsdl?
Or do I have to construct the wsdl myself?
Details:
Binding: WSFederationHttpBinding
MessageVersion: Soap12
Maybe it's because WCF produces multiple files by default and that is not always supported by things other than WCF clients.
Try this blog post about making WCF producing single wsdl. Maybe it will help.
Related
This is not a question about addressing.
I have an ASMX service, defined the usual way with WebService(), WebServiceBinding() and WebMethod() attributes.
Now, I'd like to use WCF to deliver this functionality, via self-hosted solution.
I've tried using ServiceContract() and OperationContract() attributes with equivalent Namespace parameters to what is in the ASMX service and even though the WSDL generated looks similar, when a client designed to work with the ASMX service posts to the WCF version, I don't see the methods being invoked.
How can I achieve what I'm trying to do?
I have created a WCF service and hosted it through self hosting. This service doesn't have any metada published.
First Question
Can I consume it through Visual Studio, Add Service Reference? Hopefully not.
Can I consume it by creating manual proxy, i.e. ChannelFactory<ServiceContract>....?Hopefully yes.
Now in the second scenario, the client must be .Net, right?
So it implies that, to consume a wcf service on a non-.net platform, we have to expose its metadata?
Can't a WCF service without metadata, consume by Ajax client, or say Java client??
There are 3 options to consume a WCF Service:
If the service exposes a WSDL use "add service reference" from VS (or an equivalent from another platform). Note that if you do not want to expose the WSDL you could expose it just temporarly, save the WSDL in a file, and then send it to user in any platform to generate proxy from it. You can turn off the WSDL immediately after you save it. Also note that even if the WSDL is not exposed still you need to protect the web service from unauthorized access.
If this is a .Net client it can compile with the same Service Contract assembly and use ChannelFactory etc.
Any platform can send raw soap message (e.g. XML) to the service. Of course they need to know what is the right format. A WSDL can help but even without it if they have a working sample they can imitate it.
WCF provides REST (Representational State Transfer) support to consume it by non .NET client like JavaScript (AJAX), java, Objective C, web browser, etc...
Basically WCF REST is exposes methods and transferring data over the HTTP protocol and it supports all HTTP operations (GET, POST, PUT, and DELETE). This feature is making it platform independent as well as it doesn’t require metadata exposed.
Please refere below links to get more about WCF REST:
An Introduction To RESTful Services With WCF
WCF REST Programming Model Overview
WCF Rest vs. WCF SOAP
Create RESTful WCF Service API: Step By Step Guide
I'm having an issue with a net.tcp WCF windows service int .NET 4.0 where it looks like my mex for a particular endpoint is too large. There is no problem at all connecting directly to the endpoint. I created a WCF RoutingService to allow someone outside our private network to connect to my internal WCF service. Getting the mex information through the RoutingService fails.
My WCF service has about 7 endpoints, and the WCF RoutingService is routing all of them, but only the large one (with 17 methods) is having the problem.
I found this link below which explains how to fix the problem when failing to connect directly to the mex endpoint
http://blogs.msdn.com/b/distributedservices/archive/2009/05/07/too-many-operations-or-methods-in-wcf-service-causes-the-metadataexchange-fail.aspx
But it talks about creating an endpoint in svcutil.exe.config with a contract of IMetadataExchange. The RoutingService endpoint I'm having a problem with is using the contract System.ServiceModel.Routing.IRequestReplyRouter, so I don't know if I need to configure the svcutil.exe.config file slightly differently. I've tried all sorts of combinations but couldn't get anything to work. I'm not even sure where I need to put the svcutil.exe.config file for the RoutingService WCF service to pick it up, or even if it needs one.
Does anybody know of a better solution, or a link which might provide help for when a RoutingService is involved?
As the question suggests, is providing the WSDL really necessary, or is it more of a "nice to have" feature? I have written a RESTful service, using .Net 4.0. I see now that WSDL isn't automatically generated by adding ?wsdl... and I can't get it to either after trying various suggestions :-/
I have written several ASMX services in the past - all well and good as the WSDL is accessible automatically. I want to move away from SOAP. I would prefer to provide potential users with a Class (C#, Java versions etc..) and sample code. Is that an equally viable option? Or am I being lazy in suggesting all that?
Thanks for your opinions.
WSDL = SOAP;
REST != WSDL;
For a REST Service, WSDL is not a nice-to-have it is a cannot-have.
If you are exposing a RESTful service then WSDL does not mean anything - WSDL means you have a SOAP web service.
You can expose a SOAP web service in addition to your REST service but the WSDL would be for that service.
here is my question: Is there any tool to generate one service client proxy when the service is Rest/Json? the service is WCF, and one of the clients is WPF and i need this in order to create the tests with similar code than I test the classic Soap WCF services.
If not What is the best way to achieve this?
Thanks in advance
No, there isn't simply because there is no metadata with RESTful protocols such as you get the WSDL from SOAP.
If the service is WCF, you can use the svcutil.exe util to create a client even if you're using JSON or REST as the binding.
This thread has information on it:
Client configuration to consume WCF JSON web service