I am developing an application using C#/.NET having 2 parts: a WPF client and a Windows service.
Each of these parts are currently working independently, but I now want to connect them together as a new step of my project.
The app is using NHibernate, Autofac and Automapper (dto/models).
On the service side, I currently have only one server running it, but I will maybe create a cluster to have more computing power.
The constraints are the following:
I want to be able to send my DTOs over the wire, so WCF is out.
Moreover, I don't have the budget to get ServiceStack 4 (and v3 has no more support).
For communication between client and server, does it make sense not to have a service layer (like WCF or ServiceStack) and to only use RabbitMQ for messaging ?
The advantage is that RabbitMQ supports sending of DTOs and allows to create a cluster easily.
The limitation is that I will not be able to use my service as an api to output JSON result (but it is not the purpose of my app anyway, and I'll not need it).
I'd use Rabbit MQ if you needed reliable messaging or for things that MQ's are inherently better suited for, e.g. long-running tasks, decoupling senders/receivers, etc.
But if you're just looking to cluster normal Request/Reply Services over multiple back-end App Servers you can just use a load-balancer and configure it to load-balance requests amongst your multiple App Servers.
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.
I recently discovered SignalR, seems that it can fit into high-load projects with hundreds of concurrent connections.
But as far as I can see, it is only supports full communication type of software (real-time).
So here is the question: is it possible to create REST services with SignalR without client code & persistent connections?
Basically I just need that asynchronous high performance server side part from SignalR & HTTP request handler (if exists).
Regards.
Nope that's not SignalR's purpose, use WebApi if you want to make a streaming restful api. Take a look at push content http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx.
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!
I am on a project where I will be creating a Web service that will act as a "facade" to several stand alone systems (via APIs) and databases. The web service will be the sole method that a separate web application will use to communicate with these external resources.
I know for a fact that the communication methodology of one of the APIs that the web service must communicate with will change at some undetermined point in the future.
I expect the web service itself to abstract the details of the change in communication methodology between the Web application and the external API. My main concern is how to design the internals of the web service. What are some prescribed ways of using OO design to create an appropriate level of abstraction such that the change in communication method can be handled cleanly? Is there a recommended design pattern?
As you described, it sounds like you are already using the facade pattern here. The web service is in fact the facade to the other services. If an API between the web service and one of the external resources changes, the key is to not let this affect the API of the web service itself. Users of the web services should not need to know the internals of how the web service communicates with the external resources.
If the web service has methods doX and doY for example, none of the callers of doX and doY should care what is going on under the hood. So as long as you maintain the API between the clients of the web service and the web service, you should be set.
I've frequently faced a similar problem, where I would have a new facade (typically a Java class), and then some new "middleware" that would eventually communicate to services located somewhere else.
I would have to support multiple mediums of communication, including in-process, and via the net (often with encryption).
My usual solution is define a notion of a data packet, with its subtypes containing specific forms of data (e.g., specific responses, specific requests), etc. The important thing is that all the packets must be Serializable in some form (Java has a notion for this, I'm not sure about C++).
I then have an agent and a provider. The agent takes program-domain requests, creates packats. It moves them to a stub-skeleton that is responsible only for communicating. The remote stub takes the packet and gives it to a provider. The provider translates it back to a domain object which it then provides to the actual services. It takes the response, sends it back to the agent via the skeleton-stub, etc.
The advantage of this approach is that I create several layers of abstraction. The agent/provider are focused on domain level and its translation into packets and back. The skeleton-stub pair is responsible for marhsalling and sending packets back and forth. By swapping my skeleton-stub pair with subtypes, I can have the same program communicate in different ways (e.g., embedded in the same JVM, via something like JMS, directly via sockets, etc.)
This shouldn't affect the service you create at all (from the user's perspective). Services are about contracts - your service will provide a contract with its users - they send you a specific request and you send back a specific response. You also have a contract with this other API. If they change how they want to communicate, you can handle that internally, but as long as your contract with your users does not change they wont notice a thing.
One way to accomplish this is to not simply pass through the exact object that you get from the "real" API. You can create your own object that you send back in response. You then translate their object into your object. That way if the "real" API changes things on their end you can choose how to send that back on your end.
As the middle man you should be set up so that your end users need to know nothing about the originating API.