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.
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 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
I'm currently hosting 2 webstites (clientportal and admin), in windows azure websites.
I'm going to introduce SignalR right now, to get rid of javascript polling. What I need, is when an admin send a broadcast message on the admin site, all the active client should be receive it. Now, the clien polls the webserver all the time, when an ajax poll receives, the webserver check for new messages in the database.
What would be the best way, to notify the client webserver from the admin webserver? WebApi is ok for this? Or are there any simple way?
From the point of view of Azure Websites and SignalR, it is transparent who is the Client and who is the Admin. This is an implementation detail, and thus, there are many ways to do it.
SignalR is split in two parts: The javascript library, and the .NET library that you use to create your "Hub". One way to accomplish what you are trying to do is to implement the Hub functionality in your Admin back-end using the .NET side of SignalR and ASP.NET Web API; and use the javascript side of SignalR to subscribe and listen for notifications on the Client side.
Another way to do it is to create a third component, just for the SignalR Hub, independent of both the Client and the Admin websites. In this scenario both the Admin and the Client would subscribe to the Hub, but only the Admin would push, and the Client would listen.
You can find many working examples on the internet. This is one of them: http://msdn.microsoft.com/en-us/magazine/hh965663.aspx
I hope this answers your questions.
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.
Scenario:
I have an ASP.NET MVC 2 site using ASP.NET Forms Authentication.
The site includes a Silverlight 4 application that needs to securely call internal web services.
The web services also need to be publically exposed for third party authenticated access.
Challenges:
Securely accessing webservices from Silverlight using the current users identity without requiring the user to re-login in in the Silverlight application.
Providing a secure way for third party applications to access the same webservices the same users credentials, ideally with out using ASP.NET Forms Authentication.
Additional details and limitations:
This application is hosted in Azure.
We would rather NOT use RIA Services if at all possible.
Solutions Under Consideration:
I think that if the webservices are part of the same MVC site that hosts the Silverlight application then forms authentication should probably "just work" from Silverlight based on the users forms auth cookies. But this seems to rule out the possibility of hosting the webservices seperately (which is desirable in our scenario).
For third-party access to the web services I'm guessing that seperate endpoints with a different authenication solution is probably the right answer, but I would rather only support one version of the services if possible...
Questions:
Can anybody point me towards any sample applications that implements something like this?
How would you recommend implementing this solution?
You can extend WCF to use Membership as authencation store and reuse the FormsAuth Cookie (send by the MVC site) to the browser by the Silverlight app.
I would recommend using an STS with Windows Identity Foundation so you can have your app use claims identity and then change authentication outside the app. For third party you can use Windows Azure Access Control Service (ACS). We are updating our guidance on this and you can look at the new code to show you how to do this at our codeplex site. The original book is available at Amazon. I would focus on the updated guide because it has ACS has websites and an active client talking to WCF. The client is WPF but it would similar for Silverlight.