This is a major issue for me. In earlier times, web service clients could simply use EnableDecompression = true and all was good, but why did Microsoft not add something similar to WCF?
I really NEED gzip compressed responses from my WCF services (and they need to be http... legacy issues, as usual... you know...).
Check out this blog post which basically ends up suggesting:
Conclusion
I now ditched this as we also need to
support clients that do not set the
AcceptEncoding header so I really need
the ability to read the http header in
request and set a "context" value to
(not) compress the response and I have
not found out yet how to do that per
multiple concurrent requests. I really
recommend to use the IIS http
compression and not try to do this
with WCF hacking as described here!
There's also a WCF Extensions project on Codeplex which has a WCF Compression Channel - maybe that'll be what you're looking for.
The most bang for the buck would be to use the binaryMessageEncoding in WCF instead of the textMessageEncoding (which is the default for HTTP bindings). That would require you to create a custom http based binding, and would render your service incompatible with other http-based clients other than .NET clients that are also using the same custom binding configuration.
Related
I have a third-party Java web service listening at three SOAP 1.1 WSDL endpoints. One of the endpoints is used to initiate the session and perform some high-level tasks, and the other endpoints are for subject-specific tasks reusing that initial authentication.
I'm building a C# WCF application to talk to the service, and I'd like to share the session cookie among the three client objects.
What's the VS2010 'best practices' way of sharing this cookie?
If this article is still the best answer, I can go with it, but I would appreciate some additional feedback, especially if .NET 4 introduced a simplification that I'm not finding on-line.
http://megakemp.wordpress.com/2009/02/06/managing-shared-cookies-in-wcf/
I can pretty easily create the first client and retain the session (new BasicHttpBinding myBinding; myBinding.AllowCookies = true), but I couldn't find an elegant way of saving off the cookie from the Connect response and reusing for the two auxiliary clients.
Any insights are appreciated.
I should note that I'm aware of CookieContainer and using Add Web Reference instead of Add Service Reference. That method is labeled as 'legacy' in most posts I've read, and I'd prefer to stay current...or as current as possible when working with SOAP 1.1.
The mentioned article is still valid. You have to use OperationContextScope and access message properties to get protocol specific data. This complexity is based on the fact that WCF architecture is protocol independent whereas ASMX architecture was HTTP protocol dependent.
It is true that ASMX (WebReference) is legacy technology but it is still present in .NET framework so if you know that you will never need nothing more the basic SOAP messaging without any advanced WS-* standard you can still use it and make your life little bit simple. Once you need anything more you can still refactor your code and use WCF with mentioned code to work with cookies.
I've been told that adding an HTTP RPC web service given an existing SOAP web service implemented with WCF is as simple as adding a webHttpBinding and a couple of attributes.
I'd be grateful if someone could show how to implement such an HTTP RPC web service using webHttpBinding given an existing SOAP web service that is based on WCF. It would be super helpful if the answer could show all the code for both services and even more helpful if the example is self-contained so that someone could install for testing without having to know anything about either. FYI, while I have programmed on the .NET stack it's been ~5 years and today all my work is on LAMP so I'm just not familiar enough with the latest generation .NET stack or it's current runtime environments.
My specific use-case is a set of two (2) services where one responds with an AuthToken and then a second service where I pass the AuthToken and Username, Password and another bit of information and the response back is a user object with attributes like 'first_name', 'last_name', etc. Ideally I'd be able to access those same services via two different URLs and the responses I would get back would be in JSON format.
Note I'm looking for an example to be installed by someone else who programs on the .NET stack but isn't highly motivated to do won't much extra work. I'm trying to get an HTTP-based web service I can use without having to add a SOAP client to the existing PHP framework I am using and I think if I could get a concise example of how to add such an HTTP RPC web service the .NET programmer might be happily willing to add the HTTP RPC web service for my needs. FYI, the web service in question was developed specifically for this use case and is not part of a standard set of SOAP services documented for and in use by lots of other developers.
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered #serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.
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.
I have a web service that is used by many different clients using many different languages.
I want to switch it to wcf to take advantage of the many different endpoints.
However what has been stopping me is that I am afraid that the clients will have to use a special sdk to connect (if they are using java or php or some other language) that is different then the sdk they use to connect to the existing web service.
Is this true? Or is connecting to WCF the exact same as it is for web services in other languages.
The project I am currently working on has multiple WCF configurations, some are using the default SOAP implementation, and some are using a POX (plain-old-xml) style message.
So the short answer is 'yes' you can configure WCF in such a way to work with just about anything.
However, be warned that as soon as you step outside the default little box that WCF has set up for you, it gets pretty complicated. You end up with a lot of custom message parsing and security handling if you go to a POX message format. Its easier if you stick with SOAP though.
As for needing a 'special SDK' you won't. You can communicate with WCF with simple HTTP POST messages if needed.
I have clients that are using VB.NET apps (using SOAP) and Java apps (using POX) to hit my WCF services.
A basicHttpBinding endpoint in WCF is exactly a standard SOAP endpoint, and your Java or PHP clients will not have to change in any way.