I am reading on internet about the difference between ASP.NET web service and WCF and have found that ASP.NET does not support any other protocol except http .
Can anyone please explain me the reason why ASP.NET web service don't support other transport protocols ?
It supports SOAP and other over-HTTP protocols. It is a design limitation, rectified with WCF.
ASMX web services are the original web service platform created as part of .NET 1.0. They are quite old, and the architecture is inflexible. In particular, they use the ASP.NET pipeline, which is focused on HTTP, not on multiple protocols.
They were replaced by WCF, which does not have these problems.
Related
Is an HTTP framework and a web framework the same?
For example:
Sometimes I read that CherryPy is an HTTP framework and sometimes it is called web framework
(look at this post or under the Basic Frameworks on the python.org site).
CherryPy calls itself an HTTP framework because it focuses on providing an API for managing HTTP. Frameworks which call themselves "web frameworks" typically ship with additional API's for managing databases, HTML/XML templating, javascript generation, RPC protocols and media types, and other components which are deemed useful for web development. CherryPy does not ship such components or API's, and therefore does not call itself a "web framework", although third parties may understandably do so when comparing CherryPy to other frameworks.
HTTP is a web protocol; there are other web protocols in use. An HTTP framework is a type of web framework.
CherryPy now calls itself a web framework. I guess HTTP framework that it used to be named was simply a poor name choice, probably influenced by the fact it incorporates a pretty advanced HTTP server.
Some time ago, about 2 years ago, I was working on web portal that was developed in .NET 2.0. and had plenty of asmx pages.
The other day, one of my coleagues that was more adept at ASP .NET said: "ASMX is old and ugly, we shoud rewrite it". So we did it, as far as I remember we moved to ashx handler.
But now, as I'm preparing to pass 70-515, I came across one some materials that still suggest to learn asmx services (with respect to AJAX). So is that approach still valid in new ASP .NET 3.5/4.0 web projects? If so, then when & where should I use it?
Or perhaps 2 years ago, I was soo ignorant, that we used some kind of old version of asmx and we moved to new asmx.
P.S. As I was entering tag "asmx" I saw a message: "asmx is obsolete" : https://stackoverflow.com/tags/asmx/info
If you can work with WCF then yes the ASMX services are obsolete because the WCF can fully replace them with more performance and flexibility (multiple binding), functionality. If you can write a WCF service then if you will be requested to create an ASMX service for some reason there will be no problem for you to do it.
And moving from ASMX to ASHX was not a smart move because they are not for replacing each other.
Oddly we moved from ASMX to WCF and then back to ASMX. WCF has quite a few downsides, most of all is cross-platform compatibility issues. If everyone consuming your service is on .NET this isn't an issue, but not all other frameworks have supported the full stack, and frequently they just can't do what WCF produces. We also found that dealing with security and testing was a pain in WCF. If your webservice is marked secure, it has to be secure in WCF, even in your testing environment, which means getting actual SSL certs for each developer. A tremendous pain to be sure.
ASMX and WCF are technologies to build web services in .NET. WCF was introduced in .NET 3.0. Its goal is to provide a standard abstraction over all communication technologies and is a recommended way of implementing web services in .NET.
What are the differences between WCF and ASMX web services?
ASHX is a way to write HTTPHandlers in .NET. For more information on what are HTTPHandler
http://forums.asp.net/t/1166701.aspx/1
ASMX services are supported in .NET. However migrating to WCF is recommended. Also, you should write all new services in WCF.
Yes, asmx is obsolute with WCF service. you can use asmx when you are working with < 4.0 aspx.
ashx will not be exact replace of asmx.
If you have coding format issue / standard / plenty of code then you can go with MVC Web API 2 (4.0 itself). but compare to WCF you must ensure what will be the recipient's response expectation
("WCF is the evolution of the web service(ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ. but Web api only for HTTP(s)").
I have an application that I'm building and for the moment, I built some web services using ASMX. In the end, the application will be deployed on azure. The web services are really simple in that all they do is call a class in the AppCode folder that handles all the work.
Is it going to be better/easier/faster/more performant to move my web services to WCF or to Web API?
Thanks for your suggestions.
PS: I want to add that the web services will need to work in HTTPS. At the moment, they're on HTTP because I'm in development mode.
One-liner: if you have already got a working code and it is risky to move it to another technology stay with the working code.
Depends who is answering.
Web API embraces HTTP and gives you flexibilities not possible with ASMX and WCF. If you care about HTTP, content-negotiation, media types and you need your service to be called from any client (including AJAX) then Web API.
If you need to be able to use WS* security standards (e.g. using X509 certificates, ADFS, etc), possibly change your binding, serve to different clients using different bindings, extensibility, etc use WCF.
If you already have a working code, and all you care about is RPC and your clients are always going to use ASMX then stick with ASMX.
Performance
No benchmark but my gut feeling, in descending order: Web API, ASMX, WCF
Easier
In descending order: ASMX (since you know it), Web API, WCF
Faster development
If you know them all, Web API and ASMX then WCF
PS: it is good to pick up new technologies. The way things are going (and since you are already moving to Azure) it is important to invest on new technologies.
Most web browsers support only HTTP methods like GET and POST and do not support PUT and DELETE.
If so, does web servers like IIS and Apache support it? Why should them support if the web browsers don't supports them? Those methods can be used for something else?
Web servers support these verbs because they are part of the HTTP specification and because browsers are not the only clients of web servers especially in the Web 2.0 era. There are more and more RESTful APIs today.
I need to make a change to an ASP.NET web service written a couple years ago on 2.0. I call this web service from an old 1.1 web site. I need to make some changes to the web service, so am thinking, should I rewrite this into a WCF service and if so, will I still be able to use it from my 1.1 web site?
Yes this will work. Your service will need to be at least .net 3.0, but as long as you use a basicHttpBinding or wsHttpBinding, you can consume it like any other webservice.
You can make a WCF service act and behave just like a traditional 1.1 ASMX web service, but is that what you want?
I think you need to ask yourself what featires of WCF are motivating you to upgrade.
Do you want to also expose the service as a REST-ful service? Do you need to implement message level security?
If it's just to go to the latest technology for the sake of the latest technology, I'd say stick with ASMX web services if your requirements for message and protocol security aren't that high and you're working with mostly microsoft technologies.
Writing a WCF service is regrettably more difficult than a plain-old asmx web service.
yes you can... make sure to choose the correct bindings and authentication methods