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
Related
I heard that rest services are moved from wcf to asp.net web api frame work.
Our web application is built on vs 2010 (asp.Net 3.5) .So still i can use wcf rest services in my web application?
Please suggest some alternatives if it is not possible.
WCF can still be used to build RESTful services1, many services are already built with it and it's not going away. What you heard is that most of the new developments in terms of new functionality in the area by Microsoft will be made in the ASP.NET Web API framework, not in WCF. But as all the services out there can attest, WCF for building web services is still a valid alternative, if it does all you need.
1 The official name is actually "WCF Web HTTP Services"; REST is a well-defined set of constraints which need to be implemented, which would give the service some useful properties. There are some people who argue that people should stop using the term REST for all HTTP-based, non-SOAP services.
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.
I'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
I have a .net application running on server. Now I want to comunicate between my ASp.NET website and the server application.
Currently I use database, server writes info to the db and site uses it etc. However adding new fields to echange and exchanging complex object is a pain.
Is remoting the way out? If yes, what are the common things to keep in mind while doing this.
both server and asp.net site is on the same server
both is under my control
is there any other better way than using remoting?
It is .NET 2.0
The purists will say that remoting is an old, dead technology, and the way to do it now is to use WCF.
If you're attempting to have some SOA thing, the best thing is to a web service for your server application and access it from your ASP.net website application. It's the best way to do.
However I don't really understand what the purpose of the "server" is? Couldn't your ASP.net website - as you say - be your front-end of the server application?? Your "server" would then simply be the business and data layer and there would be no need to use remoting or WCF.
I would say webservices if want to stay .net 2.0, otherwise it think you should take a look at WCF.
If you need direct interaction between assemblies (ASP.NET and some server application or service) you should use Application Domains and cross-domain calls (some good example here) or using WCF, which is better. Also you can use web services if your server application can be accessed via web without major resulting drawbacks (security issues, server deployment change, etc.).
Actually, u can deploy a WebService on that server. WebService is base on SOAP, it can exchange data object with your website.
If you can update to .Net Framwwork 3.5, you can try to use WCF instead.