I have 6 WCF web services in my web application.
On visiting any page on my MVC3 site I may call up to 4 or so of these WCF services.
In my live environment (as in all my environments) I have all my web services hosted on the same machine (each front end server has these services).
My issue is that the site I'm working on runs very slowly and as part of the performance improvements to the site I wanted to reduce the overhead of all these http requests to these various WCF services.
My question is, is it possible to call these web services in a 'non-http-overheady' way since they are living on the same machine anyway?
Thumb rules in choosing endpoint' binding of WCF
If you require your service to be consumed by clients compatible with
SOAP 1.1, use basicHttpBinding for interoperability
If you require your service to be consumed within the corporate
network, use netTCPBinding for performance
If you require your service to be consumed over the internet and the
client is a WCF compatible, use wsHttpBinding to reap full benefits
of WS* specifications
If you require your service to be accessible only in the same machine, use netNamedPipeBinding
If you require your service to be queue messages, use netMsmqBinding
If you require your service to act as server as well as client in a
peer to peer environment, utilise netPeerTcpBinding setting
Related
I am working on an ASP.NET MVC 5 application (based on nopCommerce). I want to use MassTransit to communicate with another application that is used for inventory management, billing, etc. It would be easier if I could add receive endpoints directly into the web application and not have to create a Windows service for that. But the MassTransit documentation says it is not recommended and there is no explanation as to why that is.
MassTransit in a web application
Configuring a bus in a web site is typically done to publish events,
send commands, as well as engage in request/response conversations.
Hosting receive endpoints and persistent consumers is not recommended
(use a service as shown above).
Does anyone know the reasoning behind it? Is it not safe to add receive endpoints in a web application? Will they not work properly?
Hosting endpoints in a web application is not recommended because web applications often restart for various reasons. These reasons are typically outside the control of the application itself.
While using a standalone Windows service is highly recommended, as long as the bus is properly started and stopped using the Application_Start and Application_End methods, it can be okay if you have no other options available.
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
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
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.