I have plain old SOAP "REST" service written in WCF which is hosted on Azure as WebRole. I am currently writing website which will consume this service and show some nice GUI for it. WebSite will be hosted as WebRole too and is written in ASP MVC 5.
Now i am looking for some Synchronization Framework i can implement into both sides (website and service). There will be more clients than web-site (Store app, Desktop client, android etc.)
Now i came to SignalR and XSockets.net but. Can these frameworks be scaled to more instances automaticaly and how that exactly work? For signalR i found it uses ServiceBus as background does Xsockets have simmilar? For Xsockets i found some issue page which look kinda new, but there is not a word about scalability.
By default XSockets scale over sockets and not SQL or redis. If you want to scale over something else just write your own plugin.
https://github.com/XSockets/XSockets.NET-4.0
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'm developing with Azure Mobile Services (using SQL Azure) to provide a backend for both IOS and Android mobile apps and a PHP website.
My question is now that now custom apis have been introduced is it considered best practice to wrap everything up in custom api calls rather than e.g. using the CRUD table operation scripts directly from apps or websites?
Additionally for data access from a website should you lock down access to stored procedures and only exec via custom apis, to enforce a consistent approach no matter who the consumer is?
While I appreciate that custom apis and the table scripts are restful it still isn't clear how to architect a solution in the most efficient, reliable way that can enforce business rules in only place allowing each process only one entry point e.g. you have a stored procedure exec'd by an api called from the mobile apps. If the website calls that stored procedure directly without going via the api it could have unwanted side effects because other logic steps will have been missed.
I'm relatively new to Azure so forgive me if I have just missed something fundamental here. I've read many blogs and tutorials but they rapidly go out of date.
Many thanks
In my opinion the great feature of azure mobile services is the push notifications (to ios, android, wp). If you are not going to use that, there's no great advantage to use WAMS
(Windows Azure Mobile Services).
But it's a good choice using Windows Azure as backend since it's easy to scale up /down. In this case, you could create a Webapi and host in a Web Role. As it works with http, you can easily create Restful services and call them from your apps (ios / android).
Can i have mechinism to have push notification to .NET MVC application once user comes online? Like facebook and gmail? I am going to deploy my app in 3 part.
1) MVC application
2) WCF Service
3) Azure SQL
Everything would in Windows Azure.
Thanks.
If I understand your question correctly, then you might be interested in SignalR. Here is the link http://signalr.net. SignalR allows you to push content from the server to the client. It comes with client side js library and also server side component. SignalR is very easy to implement and provides a very powerful set of abstractions that otherwise would be very difficult to program.
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 have a winform application that controls some transmitters and sound cards. There is a requirement to be able to provide a web interface for controlling those devices.
Currently I use WCF to communicate from the controllers in my asp.net MVC site to the winform app. That works well, but there is now a desire to move the hardware to another machine when needed and that means that IIS has to be installed and set-up on that machine.
I know it isn't that hard, but I won't be the one actually doing the moving. It will be the users. If I could host the site from the winform app them it would basically be portable besides the hardware drivers need for a usb to serial converter we use.
Can you use a windows service? The whole winforms app as a service doesn't seem right to me. It assumes that the app is always running. I would create a windows service and expose WCF endpoints from that.
You will need to install IIS or Cassini to host the MVC web site. There's no way around that.
Huh, I would go with Greg's answers.
Also, making your app IIS dependant is not that bad. Or Cassini dependant. You don't want to end up writing your own webserver, which could easily happen when you continue to add features to the app.
I don't know about you but it just feels you are taking all the load on yourself, you are going to spend possibly dozens of hours to implement it to spare an hour or two for someone who doesn't want to install real webserver.
if you want to host MVC under winforms then i would look into the upcoming .netcore 3 version which should allow this combination.
though you'll have to wait until 2019 Q1
https://github.com/dotnet/core/blob/master/roadmap.md
otherwise i've mostly hosted simper stuff using nhttp library if i want it in a winform app.
(NHTTP is a library that gives you very simple crude http request functionality so no mvc sadly but it works for simnpler stuff)