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.
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 trying to create a feedback system which all messages get posted to then published back to the correct subsystem. We are using queues quiet heavily and i want to make the subscriber code as clean as possible. I want to switch based off the message id i get into the feedback system and publish to its specific subscriber. i don't want to make a service for each subscriber to listen for messages.. i was thinking i could set up a queue for each subscriber and trigger to invoke a com+ component.. but i'm looking for a more modern way..
I was looking into NServiceBus but it seems i'd need to make a service/executable/webservice for each listening system ( its a little less work to make a C# dll and invoke a method) and i'm not sure if NServiceBus can handle dynamic endpoints based off a preloaded config ( loaded from a db ). WCF is also a choice.. it can handle dynamic endpoints for sure..
what do you think is the best solution for the lease amount of code/ scalable for new systems to subscribe?
Thanks
In case you are ok with online solutions you could take a look at the latest .NET Services SDK for Windows Azure which has queue service bus http://www.microsoft.com/azure/netservices.mspx It relies on WCF messages and supports routing etc. Some blog posts about this here http://vasters.com/clemensv/default.aspx
Another framework you could try is MassTransit http://code.google.com/p/masstransit/
It seems you're looking for a service host, rather than a message broker. If so, Microsoft's recommended way is to host your WCF services in IIS. They can still use MSMQ as transport, but the services themselves will be managed by IIS. IIS has evolved significantly since its early days as HTTP server, now it's closer to an application server, with its choice of transports (TCP, MSMQ, HTTP), pooling, activation, lifetime policies etc.
Although I find WCF+MSMQ+IIS somewhat overcomplicated this is the price you pay to play on the Microsoft field.
For nice and simple message broker, you can use Active MQ instead of MSMQ, it will give you message brokering as well as pub/sub. It's quite easy to work with in .NET, check this link out: http://activemq.apache.org/nms/
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
I have an application that is built as a Windows Service and a c# library assembly (.dll.) In order to manage and maintain this service, I'd like to add the ability to run a command-line application that tells the last time the service archived files, the next time it's scheduled to do so, the status of the last run, and the location of a file created by the service.
What's the best architecture for writing a service and library that can share data with another application? I'm using .net 2.0.
The way that inter-process communication happens in .net is through remoting (even if both processes are on the same machine). Other responses have suggested alternatives to inter-process communication which would not require remoting.
The best architecture is probably to make your service be a "server" that can report on it's status (and whatever information you want). Using WCF for this like ocdecio suggested would make it pretty simple.
I use WCF for that and create a contract definition for the commands/events I want to support.
Options that spring to mind that I've applied in the past:
Save the information to a database
(if you have one to hand)
Implement a
"status monitor" type thread on the
service that the client can connect
to and query via TCP/IP etc.
A fairly simple approach is to store that information in either a local config / text file which both apps have access to. Or even to place it in a registry key.
+1 for just having the service provide that (and any other data) when it is queried (simple tcp, RPC, web service, or whatever)
I'd make it pretty generic - like
QueryInfo(some identifier)
with a response as some string and a return value or other indicator that the service does not know what you are talking about, cannot get the info, or give back the info