A .net desktop application will send information to a central server, there will be potentially thousands and thousands of deskop apps sending info to my server(s).
The data will be small in size.
Would .net web services be good for this scenerio or would WCF be better suited?
What are the pros/cons?
I'd go with a WCF REST-based service, because you'll be able to transmit pure data without the overhead of the SOAP header (and other envelope nonsense) that comes with the SOAP-based classic .asmx web service.
the possibilities for throttling, concurrency, etc. are far more developed within wcf.
its a little bit more work in the beginning, but i guess that it's better suited for scenarios where you need to have full control over your bindings.
WCF is a more robust approach to SOA. Microsoft is committed to making it the primary framework for building the next wave of Microsoft business applications. The functionality available already, early in its lifecycle, is superior to plain old web services. It's only going to get better. By going with WCF early, you will be able to ride the wave and take advantage of future new functionality.
In some cases depends on the type and amount of data to send.
WCF will give you more options to tweak your calls.
On the other hand, I can't think of advantages of implementing asp.net web services over WCF. In WCF you could also implement plain 'old' web services
ASMX is like remoting, it's still around because it shipped with 1.0, but you shouldn't use it anymore if you are starting a new project. WCF will give you many more features and better tooling support.
Related
I would like to use a technology that is used for communication between services and several thousands of clients. I came to know of WCF and read a little about it. While it looks attractive and has no interoperability issues, i would like to know about other leading technologies which can give me the same features as WCF ? Are there any open source technologies out there ? Also, which is the most widely used technology? I just want this information before i commit myself to WCF.
EDIT: By alternative to WCF, i mean to say that i am looking for a framework that will help me to implement a webservice in linux or any other platform. For example, the wcf simplifies the process of creating a webservice by the use of hard coded .NET applications. Similarly, i need a tool in linux. I came across mono,but found out that it is not complete and not very reliable.
I also provide an Open Source WCF alternative in ServiceStack A modern, code-first, DTO-driven, WCF replacement web services framework encouraging code and remote best-practices for creating DRY, high-perfomance, scalable REST web services.
There's no XML config, or code-gen and your one clean C# web service is enabled all JSON, XML, SOAP, JSV, CSV, HTML endpoints are enabled out-of-the-box. It includes generic sync/async service clients providing a fast, typed, client/server communication gateway end-to-end.
I don't think there is any .net framework with comparable features. But the core protocols of WCF such as WSDL/SOAP are not Microsoft specific so it's not as if you're tying yourself into a particular protocol, you're just choosing an implementation.
To put it another way if you choose to migrate away from .net in the future then I would say the WCF migration would be one of the easiest parts. But if you stay with .net WCF is almost certainly going to be the best implementation available given the investment Microsoft has in it (Azure is built on WCF for example).
at my workplace we are about to start a big project. My boss (a programmer, this is a startup) wishes to use ASMX webservices for this purpose. I do not want to start off a new program using deprecated technology and would like to show him this. I dislike WCF at this moment because it has such an extreme learning curve, but I'd rather learn it than use an unsupported technology.
The problem I'm having is that I can not find any practical list of cons and downfalls when compared to WCF so that I can convince my boss to not use them. And saying "it's not as powerful" is not an adequate explanation. What exactly can it not do that we may need it to do for a webservice that is not meant to be shared externally? (as in, we don't support third-parties using our webservices unless they are using one of our clients. )
In short:
ASMX is
limited to only HTTP as its transport
limited to only being hosted in IIS (no other alternative)
limited to very simple security
limited to SOAP 1.1
WCF is
more flexible in transports: you can use HTTP, NetTCP, MSMQ, many more
can be hosted in IIS, WAS, or self-hosted in a Windows Service, in a console app, in a Winforms or WPF app
has much more security options
supports a plethora of WS-* standards
can interoperate with SOAP 1.1 and SOAP 1.2
In short: WCF is ASMX done right - much more flexible, much more powerful, much more in every respect.
Here's another quite useful comparison of WCF and ASMX: Comparing ASMX and WCF
and last but not least, WCF is also better in terms of performance, as this quite extensive MSDN article quite nicely shows (including performance numbers and graphs): A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
I've never understood why some people think that WCF is difficult to learn. Try this: create a new WCF Service Project in Visual Studio. Now look at the code. Compare that with the same code you get from creating a new ASMX project. It's not very different.
I have three words for you: WCF. WCF. WCF.
Here are another three about why you should choose WCF: Power. Versatility. Configurability.
ASMX is great if you want to get a quick and dirty web service up and running, although to be honest it only takes maybe a few minutes more to do a WCF one.
The WS-* are really hard to implement with asmx: transactions, reliable messaging, security... etc etc.
And later the bindings: you can change the communication just by configuration, the asmx is just http.
WF exposing services and AppFabric works over wcf.
I would not have doubts, today wcf is the best option for starting a project that needs services.
I'm building a workflow app to investigate the technology. I can't decide whether to go for a web service (and a technology with which I'm basically familiar) with WebServiceInputActivity's or WCF and ReceiveActivity's (and a new technology that I'll have to learn).
Are there any major reasons to go either way?
Clarification:
Are there any major (architectural) reasons relating specifically to WF to go either way? I appreciate the input of the respondants, so far, but they focus on WCF rather than what the implications are for my workflow and its lifetime, maintainability, performance, expandability, etc. if I choose WebServices or WCF.
WF and WCF are very much hand in hand in .net 4. I'd definitely suggest the latter.
No doubt, it is WCF. Migrating ASP.NET Web Services to WCF
SUMMARY: Windows Communication
Foundation (WCF) provides a unified
framework for rapidly building
service-oriented applications that
makes it easy to build and consume
secure, reliable, and transacted Web
services. WCF’s single programming
model unifies the capabilities in
ASMX, WSE, Remoting, COM+, and MSMQ;
therefore developers need to learn
only one programming model.
Agree with the others here that you should go with WCF.
Just thought to add one more point, that just because you use WCF does not mean that you cannot access existing web services. You can use a WCF client with basichttpbinding, to access existing non WCF web services.
You are making a mistake to call ASMX web services "web services" and suggesting that WCF can't be used to make web services. A WCF service using basicHttpBinding is exactly like an old ASMX service.
The best reason to use WCF instead of ASMX is that Microsoft has now stated that ASMX is a "legacy technology", and that they will not be fixing bugs in it.
I need some direction related to this topic; maybe I am missing the obvious.
I dont see a contrast between WCF bound to HTTP and strongly typed web service. Why would this be any different?? I agree there are some development nuances especially related to XmlSerializer in ASMX vs WCF and a plethora of Microsoft jargons. Short of these; i only see parallels
DataContract=WSDL Type
ServiceContract=WSDL (aka service definition)
OperationContract=WebMethod
Operationally, I understand the binding can be numerous with WCF instead of getting locked down to HTTP, which can involve heavy construct and tear down. But for loose coupling it will all be web services.
Are there other operational differences??
Can someone show me the light and put me out of my misery?? :))
Well, if you reduce your discussion to only HTTP, then there's still a slew of advantages that WCF has over ASMX:
more and better security settings (ability to use either transport or message security)
much more flexibility - a lot more can be configured and tweaked in WCF, either in configuration files or code
ASMX web services can only exist inside IIS - IIS is a must-have requirement; you can self-host your WCF services in a console app or Windows NT Service
the clear focus on using Service and Data Contracts in WCF makes for a much cleaner interface and a much better separation of concern (better code, in the end)
support for things like reliable messaging and transaction support (even over HTTP)
In short: even though the differences might be smaller when you restrain WCF to just HTTP, I still think it's superior and if you have the choice to start something new today, by all means, use WCF instead of ASMX!
Rick Strahl puts it very nicely in his blog post:
I would argue that using WCF for any new services is probably a good idea even if you stick with pure HTTP and SOAP because by creating your service with WCF you can decide later on to publish this same service using WAS and also provide the more high performance TCP/IP transport. Or you might be asked to provide some of the advanced features of WS- protocols like transactions, attachments, session management, encryption etc. By using WCF you are building your service with a view to the future so you can easily move up to other protocols-some of which may not even exist today. Certainly new technologies will come along in the future and WCF protects you somewhat through its abstraction layer and common API.*
Marc
Another point for the consumers of the ASMX web service, which ever platforms will consume the web service will have to implement a SOAP stack. If you're goal is for wide reaching consumption, WCF is preferable and will allow you to expose the WS in more universal ways.
The other big distinction between the two technologies is that Microsoft now considers both ASMX web services and XML Serializer to be "legacy technology", and is no longer fixing bugs in them.
Recently I made the switch from using asmx web services to using wcf services, the transition is nearly finished, but I know I'm in for a lot of error checking and testing to make sure everything ported as expected.
My question is - so far I can only think of 1 good benefit to using wcf, and that is you get an easy way to implement a singleton web service.
Besides that I have to tell you, configuring a WCF Application seems way overly complicated, and I'll forever miss how easy it was to test asmx web services.
What other benefits are there to using WCF over ASMX web services?
more protocol options; ASMX is IIS and HTTP only - WCF gives you HTTP, NetTcp, MSMQ, IPC - you name it
you can write your service once, and expose it on multiple endpoints
self-hosting: you can host your WCF service in a console app, a Winforms app, a WPF app, or let it be handled by IIS/WAS - but you don't have to
a lot more options like reliable sessions, lot more security options
you don't have to deal with as much "plumbing goo" in WCF as you do in ASMX - you can concentrate on your business problem, and let the config and attributes handle all the gooey stuff you don't want to deal with
to name just a few.....
Search Google or Bing for "WCF vs ASMX" and I'm sure you'll find plenty more article, blog posts and comparisons.
ASMX has passed its time - WCF is the present and the future. It can do a lot more - therefore it's a bit more to learn.
But if you check out the right sources, like these two Dotnet Rocks TV shows (Keith Elder Demystifies WCF and Miguel Castro on Extreme WCF), I'm sure you'll get a quick and hopefully painless start into WCF!
Marc
WCF allows you detach service from the physical layout and protocols. For example, you can write one service and deploy it as either REST or SOAP, or whatever that may happen in the future. ASMX is great, but it's pretty much hardcoded to SOAP. Also the idea is that you can plug-in existing features like throttling just by changing preferences, which I haven't seen much benefit of.