Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've spent a few months trying to grasp the concepts behind WCF and recently I've developed my first WCF service application.
I've struggled quite a bit to understand all the settings in the config file.
I am not convinced about the environment but it seems that you can do amazing stuff with it.
The other day I've found out that Microsoft has come out with a new thing called ASP.NET Web API.
For what I can read it's a RESTful framework, very easy to use and implement.
Now, I am trying to figure out what are the main differences between the 2 frameworks and if I should try and convert my old WCF service application with the new API.
Could someone, please, help me to understand the differences and usage of each?
For us, WCF is used for SOAP and Web API for REST. I wish Web API supported SOAP too. We are not using advanced features of WCF. Here is comparison from MSDN:
The new ASP.NET Web API is a continuation of the previous WCF Web API project (although some of the concepts have changed).
WCF was originally created to enable SOAP-based services. For simpler RESTful or RPCish services (think clients like jQuery) ASP.NET Web API should be good choice.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
In the scenarios listed below you should go for WCF:
If you need to send data on protocols like TCP, MSMQ or MIME
If the consuming client just knows how to consume SOAP messages
WEB API is a framework for developing RESTful/HTTP services.
There are so many clients that do not understand SOAP like Browsers, HTML5, in those cases WEB APIs are a good choice.
HTTP services header specifies how to secure service, how to cache the information, type of the message body and HTTP body can specify any type of content like HTML not just XML as SOAP services.
Since using both till now, I have found many differences between WCF and Web API. Both technology stacks are suited well to different scenarios, so it is not possible to say which is better, this depends on configuration and scenario.
Properties ASP.Net Web API WCF
--------------------------------------------------------------------------------------------------
End point (mainly) Http based SOAP based
Service Type Front End Back-end
Support caching, compression, versioning No
Framework ASP.net WCF
Orientation Resource Oriented Service Oriented
Transports http http, tcp, MSMQ, Named pipe
Message pattern Request reply request Reply, one way, duplex
Configuration overhead Less Much
Security lesser than WCF (web standard security) Very high (WS-I standard)
Hosting IIS IIS, Windows Service, Self hosting
Performance Fast A bit slower than Web API
In use from .NET 4.0 .NET 3.5
Note: The data is not only my view, it is also collected from other official websites.
WCF will give you so much of out the box, it's not even comparable to anything. Unless you want to do on your own implementation of (to name a few) authentication, authorization, encryption, queuing, throttling, reliable messaging, logging, sessions and so on. WCF is not [only] web services; WCF is a development platform for SOA.
Why I'm answering:
I took huge amount of time to understand the difference between these two technologies. I'll put all those points here that I think "If I had these points at the time when I was wondering around in search of this answer, then I have decided very earlier in selecting my required technology."
Source of Information:
Microsoft® Visual Studio® 2015 Unleashed
ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3
Why ASP.NET Web API and WCF:
Before comparing the technologies of ASP.NET Web API and WCF, it is important to understand there are actually two styles/standards for creating web services: REST (Representational State Transfer) and SOAP/WSDL. The SOAP/WSDL was the original standard on which web services were built. However, it was difficult to use and had bulky message formats (like XML) that degraded performance. REST-based services quickly became the alternative. They are easier to write because they leverage the basic constructs of HTTP (GET, POST, PUT, DELETE) and typically use smaller message formats (like JSON). As a result, REST-based HTTP services are now the standard for writing services that strictly target the Web.
Let's define purpose of ASP.NET Web API
ASP.NET Web API is Microsoft’s technology for developing REST-based HTTP web services. (It long ago replaced Microsoft’s ASMX, which was based on SOAP/WSDL.) The Web API makes it easy to write robust services based on HTTP protocols that all browsers and native devices understand. This enables you to create services to support your application and call them from other web applications, tablets, mobile phones, PCs, and gaming consoles. The majority of applications written today to leverage the ever present Web connection use HTTP services in some way.
Let's now define purpose of WCF:
Communicating across the Internet is not always the most efficient means. For example, if both the client and the service exist on the same technology (or even the same machine), they can often negotiate a more efficient means to communicate (such as TCP/IP). Service developers found themselves making the same choices they were trying to avoid. They now would have to choose between creating efficient internal services and being able to have the broad access found over the Internet. And, if they had to support both, they might have to create multiple versions of their service or at least separate proxies for accessing their service. This is the problem Microsoft solved with WCF.
With WCF, you can create your service without concern for boundaries. You can then let WCF worry about running your service in the most efficient way, depending on the calling client. To manage this task, WCF uses the concept of endpoints. Your service might have multiple endpoints (configured at design time or after deployment). Each endpoint indicates how the service might support a calling client: over the Web, via remoting, through Microsoft Message Queuing (MSMQ), and more. WCF enables you to focus on creating your service functionality. It worries about how to most efficiently speak with calling clients. In this way, a single WCF service can efficiently support many different client types.
Example of WCF:
Consider the example:
The customer data is shared among the applications. Each application might be written on a different platform, and it might exist in a different location. You can extract the customer interface into a WCF service that provides common access to shared customer data. This centralizes the data, reduces duplication, eliminates synchronization, and simplifies management. In addition, by using WCF, you can configure the service endpoints to work in the way that makes sense to the calling client. Figure shows the example from before with centralized access of customer data in a WCF service.
Conclusion:
i) When to choose Web API:
There is no denying that REST-based HTTP services like those created using ASP.NET Web API have become the standard for building web services. These services offer an easy, straightforward approach for web developers building services. Web developers understand HTTP GET and POST and thus adapt well to these types of services. Therefore, if you are writing services strictly targeted to HTTP, ASP.NET Web API is the logical choice.
ii) When to choose WCF:
The WCF technology is useful when you need to support multiple service endpoints based on different protocols and message formats. Products like Microsoft BizTalk leverage WCF for creating robust services that can be used over the Web as well via different machine-to-machine configurations.If, however, you do need to write an application that communicates over TCP/IP when connected to the local network and works over HTTP when outside the network, WCF is your answer.
Be Warned:
Web developers often view WCF as more difficult and complex to develop against. Therefore, if you do not foresee the need for multiprotocol services, you would likely stick with ASP.NET Web API.
There is a comparison on MSDN about this
WCF and ASP.NET Web API
For me, the choice was about Who the clients are, and where are they located?
Within the company Network and .NET based clients : Use WCF with TCP binding (Fast communication than HTTP)
Outside the company Network, and use diverse technologies like PHP, Python etc: Use Web API with REST
Business speaking, WebApi lacks of a WSDL, so the developers should document all manually. And if, for example, the WebApi operation returns a list of objects then, the client should creates the objects manually, i.e. WebAPI is really prone to errors of definitions.
The pro of Webapi is its more lightweight than WCF.
Regarding the statement "WebApi lacks of WSDL" there are several ways to generate Rest client. One popular approach is Swagger UI / (Swashbukkle Nuget). This gives a rich interface to understand the REST end point's input and output schema and online tool to test the end points.
JSON LD (Json Linked Documents) is another emerging standard which will further improve the JSON based REST developer experience by exposing the JSON schema with better semantics.
With wcf we can configure and expose the same service support for multiple endpoints like tcp, http.if you want your service to be only http based then it will be better to go with web API. Web API has very less configuration when compared to wcf and is bit faster than wcf. Wcf also supports restful services. If you have limitation of .Net framework 3.5 then your option is wcf.
Related
I am currently in the planning stages for a fairly comprehensive rewrite of one of our core (commercial) software offerings, and I am looking for a bit of advice.
Our current software is a business management package written in Winforms (originally in .NET 2.0, but has transitioned into 4.0 so far) that communicates directly with a SQL Server backend. There is also a very simple ASP.NET Webforms website that provides some basic functionality for users on the road. Each of our customers has to expose this site (and a couple of existing ASMX web services) to the world in order to make use of it, and we're beginning to outgrow this setup.
As we rewrite this package, we have decided that it would be best if we made the package more accessible from the outside, as well as providing our customers with the option of allowing us to host their data (we haven't decided on a provider) rather than requiring them to host SQL Server, SQL Server Reporting Services, and IIS on the premises.
Right now, our plan is to rewrite the existing Winforms application using WPF, as well as provide a much richer client experience over the web. Going forward, however, our customers have expressed an interest in using tablets, so we're going to need to support iOS and Android native applications as clients, as well.
The combination of our desire to offer off-site hosting (without having to use a VPN architecture) and support clients on platforms that are outside of the .NET ecosystem has led us to the conclusion that all of our client-server communication should take place through our own service rather than using the SQL Server client (since we don't want to expose that to the world and SQL Server drivers do not exist, to my knowledge, for some of those platforms).
Right now, our options as I see them are:
Write a completely custom service that uses TCP sockets and write everything (authentication, session management, serialization, etc.) from scratch. This is what I know the most about, but my assumption is that there's something better.
Use a WCF service for transport, and either take care of authentication and/or session management myself, or use something like durable services for session management
My basic question is this:
What would be the most appropriate choice of overall architecture, as well as specific features like ASP.NET authentication or Durable Services, to provide a stateful, persistent service to WPF, ASP.NET, iOS, and Android clients?
(I am working on the assumption that by "stateful" you mean session-based).
I guess one big question is: Do you want to use SOAP in your messaging stack?
You may be loathe to, as often there is no out-of-box support for SOAP on mobile platforms (see: How to call a web service with Android). No doubt its similarly painful with iOS. Calling SOAP from a browser ("ASP.NET") can't be fun. I'm not even sure its possible!
Unfortunately if you aren't using SOAP, then that quickly rules out most of WCFs standard Bindings. Of the one that remains, "Web HTTP", sessions are not supported because obviously HTTP is a stateless protocol. You can actually add session support by hand using a solution based on Cookies.
You could use the TCP transport (it supports sessions), and build you own channel stack to support a non-SOAP encoding (for example protocol-buffers), but even then you need to be careful because the TCP transport places special 'framing' bytes in it, so that would make interop non-trivial.
What sort of state do you need to store in your sessions? Maybe there are alternative approaches?
1) consider stateful utility services using singletons, but keep the request/response pattern at the facade level stateless.
2) consider distributed caching, perhaps Windows Server AppFabric Cache.
I need to expose several WCF services, but these services have to be used from any client(WPF, Explorer,Chrome, AJAX) and the client generation tools or the aspects related to security must be applicable .
I need an architectural/technical piece of advice about what would be the best approach: tools, architecture, etc... to solve this problem.
As I know, with WCF services there are many different options to do this, but if for instance, the data is exposed in an AJAX-enabled way, I dont know the side problems or limitations that this generates on the usage of the WCF for non-AJAX clients.
any suggestions are welcome.
Thanks in advance
In my opinion, AJAX really refers to how the client application accesses data. AJAX (async javascript and XML) isn't really AJAX anymore, as it seems that JSON is the preferred format of the payload instead of XML since it's more streamlined.
I think from your WCF service perspective, you really need to decide what data format or formats you will expose your data as. Will it be XML, JSON, some other text format? I'm not really sure what you mean by data exposed in an AJAX-enabled way, but if you're going for cross-platform access to your data, you probably want to expose your services as RESTful services. Take a look at the WCF Web HTTP (REST) features in the .NET 4 Framework (MSDN documentation here) to help guide you in developing RESTful services that lend themselves to a number of AJAX-enabled client frameworks.
Probably the biggest limitation with using the WCF Web HTTP model is that you don't have the WS-* features of security and messaging that you have with SOAP-based WCF programming. Again, you have to determine what your security and other needs are for your application. But those are the two main 'chunks' of WCF programming -- SOAP/WS-* and Non-SOAP/REST. (That's a generalization and I'm sure there are probably some exceptions.)
Exposing your services as RESTful services lends itself to a number of client-side frameworks, such as jQuery, the WCF Data Services (OData) client frameworks, Silverlight/WPF, etc. Lots of options and not tied to the .NET framework.
I hope this helps. Let me know if I need to clarify some points.
Thanks!
Background
I'm primarily a .Net developer with limited experience in Java. I have a WCF web service that needs to communicate with a 3rd party Message Queue Server in order to send and receive files. The 3rd party has provided a Java API in order to access their Message Queue Server.
I've done some research into the best way to move forward and now I'd like to get some feedback from anyone with experience with a similar situation.
After some digging I determined that one option is to create a java web service in Eclipse and host it on Glassfish. This java webservice would reference:
The java api provided by the 3rd party thus allowing the 3rd party to send the xml files to us.
My existing WCF service in order to pass along the xml to be processed.
So the incoming xml file would flow as follows:
3rd party -> Java WS -> WCF WS
This incoming flow is only half the equation since my WCF web service can also initiate communiation with the third party. So I need an outgoing flow as well.
One option would be to reference the Java WS from my WCF service. However then the 2 web services would each be referencing each other. Is this considered a circular reference (bad practice) when 2 web services reference one another?
If option 1. is considered bad practice, my other option would be to have one of the web services poll the other service.
Other options?
Summary Questions
1. Any insight into the circular web reference question above?
2. Am I on the right track in general?
3. Any suggestions or personal experience you can provide?
Your insight is very much appreciated.
My first thought would be that if it's a quick RPC type call, provided you're calling a different web services for the The call back, I wouldn't be too concerned about a circular reference. Technically you're sending messages "by contract" So as a good practice put your contract definitions in a different project to your service implementation.
If the .NET processing takes a bit of time it may be worth it to use a message queue and a worker service as well.
The other consideration is to find out what MQ infrastructure they're actually using. You may be able to avoid the web services altogether as there are .NET connectors for a lot of MQ providers, like
MSMQ (obviously)
ActiveMQ http://activemq.apache.org/nms/
& WebSphere MQ http://www.redbooks.ibm.com/abstracts/sg247012.html
Just to name a few. There are also MSMQ bridges.
I'm planning a project which will consist of a Windows Server Application programmed in .Net/C# and Clients programmed in Silverlight/C#, Windows Forms/C# and a MacClient programmed in Cocoa. My Question is, which Webservice technology will be the best for the communication between the Clients and the Server and is the easiest to program in all of those technologies? I've no experience in Webservices and since Time is running short I hope to get some opinions of developers who worked in such a kind of heterogeneous project.
On the back end, you will definitely want to run Windows Communication Foundation, using the WSHttpBinding or the BasicHttpBinding depending on your needs.
This will make it easier to have Windows Forms and Silverlight clients.
Also, because using WCF with those bindings conforms to established standards, you should be able to access the services from almost any other environment - there should be tools that you can just point it to your metadata endpoint and it will generate proxies for you.
Another option is to use WCF to create a REST service (with JSON encoding most likely). WCF does help you a little bit here, but if this is the design you want to use, then you will want to look at ASP.NET MVC on the back end as well, as it makes creating these kind of services very, very easy.
However, when using REST services, there isn't a service description through something like WSDL, so you will have to generate the proxies to call your services by hand (at least, in environments outside of .NET).
The current technology used to develop web services on .NET is WCF. For interoperability with non .NET clients you should consider using basicHttpBinding endpoint. You could even expose multiple endpoints with different bindings, for example expose interoperable endpoint for non .NET clients and some fast binding for .NET clients. Here's a nice article on MSDN covering the performance of the different bindings. Given those keywords you might checkout the tutorials.
I see that there are two options that I know can be used in web services... WCF obviously, and ASP.NET Web Services. What's the difference? I just started picking up WCF recently and had a little exposure to web services in the past, but I'm certainly not an expert.
it is quite easy to know the differences.
ASP.NET Web Method is called ASMX [because of the file extension] (check 4GuysFromRolla about this, they have a good tutorial)
This technology makes you expose methods as a Web Service so you can connect it (to the WS) from everywhere and use it (the methods). But... you can't protect the data between server and client, like, you can send big files in a clear mode, etc...
[Note] you can protect the access to the web service using certificates, but it is a pain and quite complicated, normally in ASMX we use username / passsword to give access to a method (once again... in plain text!)
In WCF, you are in the different world about Web Services, and this is the best technology in .NET (so far) to expose Services (can you see the difference... Services! not Web Services), WCF does not need IIS to run, it can run as a System Service on the server, using a console ambient (like command line), in TCP/IP mode, etc, so we say that WCF is a Service, not a Web Service. Remember ASMX need IIS to run and will only run hosted in a Web Server.
With WCF you can use SSL to encrypt the communication (to do that in ASMX you need to use WSE - Web Services Enhancements) and it is quite easy to implement it, you can send big files and securely (to do that in ASMX you need to use MTOM - Message Transmission Optimization Mechanism).
you can set the transmission preferences just changing one line of code, or even, if you prefer, change the XML configuration file, the security is much higher, etc, etc :)
hope you get a better general overview with this, but there is much more.
bottom line: to expose Web Services that you do not need to protect, you can use ASMX, no problem at all, but if you need to protect the communication somehow, do it in WCF!
link: you can read here some performance comparative between the 2 services
ASP.NET web services was Microsoft's first attempt at web services.
WCF replaces ASP.NET web servies and .NET remoting. WCF provides a common programming model that enables you to do what the two older technologies where capable of and much more including support for a wide range of protocols and security models.
Go with WCF if you have the choice.
ASP.NET webservices is OKAY - but it's limited to HTTP hosted in IIS only, and has other problems.
WCF supports way more transport protocols (HTTP in various ways, TCP, MSMQ and more), has a lot richer security model (credentials, federated security), and offer options for hosting - self-hosting in a Windows app or service, in IIS or WAS and more.
In short: if you're starting now - go learn WCF by all means !
Marc