Is there any use to work in MVC web service instead of asmx and WCF web service. Can anyone please tell the difference between the three?
About WCF web services and ASPNET Web Services (ASMX), You can find side by side comparision from MSDN : Comparing ASP.NET Web Services to WCF Based on Development
If you are making MVC Application you can use both ASMX and WCF web services, But I strongly recommend to use WCF Web service for any new development.
For information, I think the more suitable Blog regarding comparison is : ASMX Vs WCF
WCF vs. ASMX
Protocols Support
WCF
HTTP
TCP
Named pipes
MSMQ
Custom
UDP
ASMX
HTTP only
Hosting
ASMX
Can be hosted only with HttpRuntime on IIS.
WCF
A WCF component can be hosted in any kind of environment in .NET 3.0, such as a console application, Windows application, or IIS.
WCF services are known as 'services' as opposed to web services because you can host services without a web server.
Self-hosting the services gives you the flexibility to use transports other than HTTP.
WCF Backwards Compatibility
The purpose of WCF is to provide a unified programming model for distributed applications.
Backwards compatibility
WCF takes all the capabilities of the existing technology stacks while not relying upon any of them.
Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed.
Existing applications are able to upgrade with WCF
New WCF transacted application will work with existing transaction application built on System.Transactions
WCF & ASMX Integration
WCF can use WS-* or HTTP bindings to communicate with ASMX pages
Limitations of ASMX:
An ASMX page doesn’t tell you how to deliver it over the transports and to use a specific type of security. This is something that WCF enhances quite significantly.
ASMX has a tight coupling with the HTTP runtime and the dependence on IIS to host it. WCF can be hosted by any Windows process that is able to host the .NET Framework 3.0.
ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call.
ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.
I can't top the other post on here regarding the merits of WCF over ASMX, it is from the source (microsoft), what I would add to that post as it fails to mention the MVC Web API, is this... your question really depends on the problem you are trying to solve. If you are trying to do messaging, message queues, or lower level tcp/ip it will still be WCF..
I'm a modern world programmer, as lazy as they come.. both ASMX and WCF technologies are starting to feel a bit dated to me, for example a typical WCF implementation will probably have a hefty XML configuration associated to it, if this is the way you are used to working then it will probably feel natural.
I like type safety and hate magic strings and further hate digging around in large XML, to my mind this is the path of the runtime error.
If you have used the MVC framework to create a web application then there is pretty much a zero learning curve to using the mvc webapi.
All the standard things like routes, models and controllers still apply in exactly the same way, all the HTTP verbs are there to be used...
With minimal effort all your routes and controllers can be used in a completely type safe way (no strings), so if it is broken then it probably doesn't compile....
Also it is much easier to write a unit test to exercise a controller than it is to unit test a ServiceContract
I'm not certain but I'd expect the MVC route to lend itself to IoC/DI better than WCF for the same reason above, but I'm prepared to be wrong on that.
Can you tell I'm biased.
This is a subjective question and with regards to the difference between the 3; WCF is more suited to communication between layers, asmx is basically what we used before wcf came along and due to the flexibility of mvc, it can be used in a number of senarios. WCF is however great for implementing OData services.
I personally use MVC to implement the web service on the client tier for AJAX interactions and have done so on several projects. The advantages are that I do not have a separate project and as such the front end stack is light weight and DRY, more efficient and organising code in this way makes more logical sense to me.
IMHO wcf has too large an overhead and is overly complex for simple JSON serialization. I personally think there is a case for using MVC in an n-tier architectural site instead of WCF.
This article looks at using this in the infamous NerdDinnerd project nerd dinner rest
There are several frameworks such as OpenRasta, but I find that the standard mvc.net tools are more than sufficient.
Also, a good article by haacked here: haacked.com
I'm on the core team that maintains ServiceStack - another very popular choice to build REST-based services on .NET / Mono.
Supports REST, SOAP and MQ based services
In addition to REST-based services you can re-use your same services to Support both SOAP and REST-based endpoints. ServiceStack also includes the .NET's fastest JSON, JSV and CSV text serializers. Here's an earlier answer comparing its advantages over WCF and WebApi.
Succinct, Typed, End-to-end API
ServiceStack also includes typed generic ServiceClients in all the major supported formats including: JSON, XML, JSV, SOAP 1.1/1.2 as well as the super fast binary ProtoBuf and MessagePack formats.
ServiceStack's generic service clients offer the most succinct, typed end-to-end client/server API without any code-gen.
ServiceStack Overview slides
The ServiceStack Overview Talk at this years MonkeySpace has a good intro into ServiceStack and its advantages.
Related
I have a standard nteir setup :-
Web server -> App server -> DB server
I have an MVC 5 web application sitting on the web server with controllers calling a WCF services project sitting on the App server. WCF services project uses EF6 to marshal data on the DB server.
I am wondering if WCF is overkill? Is there is an easier way to achieve this same architecture? I am thinking I should have gone with Web API on the app server and then just call the web API from the controllers with the HTTPClient?
Or, I could even just use a plain MVC project on the App server returning JSONResults to the MVC controller on the web server?
It depends...
You have to understand what are the benefits of each set up. This is not exhaustive, just a quick brain dump. This should give you some hints to look further as in the wild world there might be many more reasons for choosing one or another solution.
Why WCF. Are you going to have different clients to your backend ? You need some entreprisy security between clients and you backend ? With WCF you could configure Http, TCP endpoints, set message or transport security and a lot more. It could be needed for example if your doing an intranet application and you would like not only to have your UI (MVC application) but other systems going to it. If this is not needed WCF seems overkill here.
Web Api is also agreat choice if you would like to built more REST oriented api, enabling content-negotiation for different clients (different media-types). Building REST is not about issuing JSON, it's much more and this would be too long to explain it here. If your client is not only your MVC app, but you could have a need for a api for other mobile devices, OAuth authentication and the so, this could be a good way to do.
Plain MVC app would also fit if you don't have any special needs, go for it. No overhead needed. Keep It Simple And Stupid.
I hope this helps
I would not change this.
WCF is a good choice for communication between Web Tier and App Tier. I would never put my App Tier exposed to outside world, so if there is any communication to my app from outside world, it would be through Web tier only and if there is a need to support multiple clients, I would create a WebAPI on web tier and expose that.
I would keep App tier only available to Organization internal and with WCF I would have flexibility to write service code and contracts which can then be exposed over various bindings (transport, security, etc.).If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF is indeed a good choice.
I have a multilayer asp.net mvc application consisting of the following levels:
Database (with stored procedures, views and tables)
WCF service (containing business logic and connection to the database through Entity Framework)
Asp.net mvc application communicating with the WCF service and generating html
Browser
The end-users are authenticated in the asp.net mvc layer using Identity 2.0.
The web server is the only client for the WCF service.
Are there any best-practices for this scenario?
The web server and the WCF service might be running in different locations so we cannot use the intranet protocols.
Since we control both the web server and the WCF service we know that the communication will be point-to-point. This means we can use transport security to avoid the extra overhead with message security.
According to this, Improving Web Services Security: Scenarios and Implementation Guidance for WCF, there are two choices for transport security over internet:
Basic authentication with basicHttpBinding
Certificate authentication with wsHttpBinding
Which one would be best suited to this scenario where there basically is only one client for the WCF service?
Due to the stateless nature of http for each new request to the web server a new service-proxy is instantiated.
Is there a way to cache the authentication info from the WCF service on the calling web server to better performance?
You can set up certificate authentication between your WCF and MVC servers using BasicHTTPBinding ... I've done it. But I'm not sure why you use BasicHTTPBinding when, from your description, all the backend services (WCF and MVC) are Microsoft based.
BasicHTTPBinding is a generic WCF protocol that will accept any properly formatted HTTP request (Gets/Post), whether the request comes from a Windows machine or the JAVA/PHP world. It's also, as you say, stateless. That makes BasicHTTPBinding good for interop situations, but more complex (than say wsHTTPBinding) when setting communication between two MS-centric systems.
By default, for instance, NONE is the default encryption for BasicHttpBinding. Adding Transport takes programming and lot of trial and error to get running, from my experience. BasicHttpBinding, also, doesn't support transactions or sessions while WSHttpBinding does. So, based on your description, WSHttpBinding will be simpler and easier to setup and maintain in the long run. But you might also consider NetTCPBinding since you're going server-to-server.
Below you'll find a great MS site explaining all the different WCF protocols, including to pros and cons of each approach.
http://msdn.microsoft.com/en-us/library/ms730879.aspx
In the last few years, I have seen the rise of many Web APIs - services exposed over plain HTTP rather than through a more formal service contract (like SOAP or WS*). Microsoft has just launched a new framework called "ASP.NET Web API" hat makes it easy to build HTTP services that reach a broad range of clients. Event if I am a .net fan, it is another communication framework (after asmx, wcf, ria, ...). Now, working as an happy architect, I have to take decision over technologies.
Is Asp.net Web Api really a good choice for a new architecture? Remember Linq2Sql, I do not want to invest in a "disposable" api.
Is there still a use for WebBindings in WCF?
The problem with this question, in terms of it being a stack overflow question, is that it's basically subjective. As a result, I'm pretty sure it'll be closed - but I'm going to stick my 2 pence (it's more like £2 actually) anyway and if it gets closed so be it.
First Linq2Sql isn't 'disposable' - it's still there and not going to go away. It's not being developed - that's another matter entirely.
Anyway - The Asp.Net Web API is a formalization of REST web service support by many people from the same team that work(ed) on Asp.Net MVC and uses a very similar approach to extensibility, pipelining, cross-cutting concerns (e.g. authentication, logging, validation) and such. Whether you use it or not is entirely down to whether you are intending to develop RESTful web services. If you are, and you're on .Net 4+, then, in my opinion, you'd be mad not to.
The overall architecture in the Web API is very good and you can extend most of it without too much effort at all. In particular, the way that they have handled content negotiation is very very nice, making it trivial to, for example, support JSON requests but returning XML responses just because a client sends Content-Type:application/json and Accepts:application/xml.
As a server technology it's also very very fast; partly because it's entirely asynchronous (increasing scalability) but also because the stack between a request coming in, to your code being called, is very shallow.
Not only that but you can host it in both IIS and in any .Net application also - which increases your hosting options but also makes it a candidate for intra-network communications within a common network (i.e. non-internet) environment.
If, however, you want to write a SOAP or WS-HTTP service then, no, the Web API is not for you - you'd stick with WCF.
In short - you need to think of the Asp.Net Web API purely as a server and client technology running on .Net as opposed to a protocol or web architecture. It enables you to build RESTful web services - you can also do that in MVC, WebForms (if you really wanted to), .ashx handlers, or by writing your own HttpListener.
Which of those you choose is entirely up to you to decide.
We can call ASP.NET Web API a replacer of WCF Web API.
It will support more platform oriented service.
I am developing an ASP.NET web application (C#.NET 4) in a scenario where I need to consume WCF SOAP Services (VB.NET 4) provided by another development team as the model.
Services are hosted on IIS using AppFabric. The WCF implementation is created to support the following scenario:
A shared data service layer that is language/platform independent. A requirement is also that services should provide a black-box when front-end development is outsourced to external developers. WCF SOAP services are used to provide the common web based API. Consumers of the services are both web applications and desktop software that are internal and external.
My question is about my current web application architecture. The application is developed using ASP.NET MVC 2 and jQuery UI. From what I have read this far it seems that using WCF SOAP Services as the model is ok. My plan is also to use ViewModels and AutoMapper based on this post:
Using SOAP web service object as a model in ASP.NET MVC 2
What are the pitfalls if any?
How should I develop the communication with services?
Are there overheads in term of communication with this kind of architecture?
Any Best Practices?
(Re-engineering the service layer to OData is not an option at this stage)
If you think about your web services as a "remote database" you can just follow the same practices that you would when developing an MVC application against a database. But be prepared for far more disconnection problems that you would otherwise.
I would suggest you create your model to wrap the calls to the web services and provide any error handling logic that you will need (which will be probably a lot if the web services will be remote.) Remember that network connectivity on a WAN is not guaranteed and hiccups are not unusual.
A Guide to Designing and Building RESTful Web Services with WCF 3.5, this article explains the foundations of REST and how it relates to WCF. MVC uses REST as the architectural model. I am guessing one can use the .NET MVC to create web applications that have both a front end and an API point, but I am not sure if the safe way of building the API is to build it with WCF and then use it in the MVC as a controller.
Please comment if the question is not clear, I will add or modify the text.
Theres actually a third option, ADO.NET Data Servies. Anyway, here how I see them.
MVC REST: Gives you full control over how to expose your data, you have to write all the code to get it up an running tho, e.g. serialization, deserialization, all the CRUD methods etc etc. Worht metioning that this being an MVC site means you are limited to exposing your service via IIS over HTTP(S)
WCF REST: More automation than MVC, a much more solid frameowkr than MVC REST, i.e. caching, security, error handling etc (basically all the stff you'd have to write yourself using plain MVC). Being WCF, you can host this in a variety of ways (e.g WS-, TCP) etc.
ADO.NET DATA SERVICES: The quickest way to get up an running with everthing ready to use, all you need todo is configure the global.asax, however you have to use an Entity Data Model, which you many not want to.
Personally, I would use either ADO.NET DATA SERVICES or WCF REST to build an API, consue that API in MVC site and then expose that API either directly, or by passing it through another layer.
ASP.NET MVC can serve as a REST endpoint for light services work, so I guess the answer to your question depends on how you define "safe."
Clearly WCF is designed specifically for creating REST endpoints, with all of the security implications that are implied thereof, whereas ASP.NET MVC is designed to create REST endpoints which can be used by ASP.NET MVC itself.
The following article shows how to create a web service using an ASP.NET MVC controller:
Create REST API using ASP.NET MVC that speaks both Json and plain Xml
http://msmvps.com/blogs/omar/archive/2008/10/03/create-rest-api-using-asp-net-mvc-that-speaks-both-json-and-plain-xml.aspx
See also the following article from Phil Haack, which discusses an SDK the WCF team put together for users of ASP.NET MVC:
Rest For ASP.NET MVC SDK and Sample
http://haacked.com/archive/2009/08/17/rest-for-mvc.aspx
They are two different sets of technologies, only related by being built on .net
MVC is used to create websites and provides a model where URLs are routed to controllers and controllers deliver views to the user as the user interface.
WCF is a set of libraries in .net that are used to abstract the type of service (is it hosted in a windows service, as a webservice in IIS etc.) as well as the protocol (HTTP, TCP, MSMQ etc.) from the client and server which are communicating.
An MVC website may use WCF to connect to a web service, but that is just one of many options.