I have two different web applications that need to communicate with each others (which I can currently accomplish by using Silverlight Duplex but that doesn't scale very well). After reading about SignalR, I'd like to give this a try but failed to find much documentation on how to do this. Any advice on ho to get started would be greatly appreciated.
Thanks!
More specific Info:
Example:
Application A (Bidding Interface) - A web page to allow multiple end-users to place bids on certain items.
Application B (Managing Interface) - A web page to allow a user (or could potentially be multiple users) to monitor/control the actions from Bidding Interface.
So when a user from Application A place a bid on a piece, I'll need a way to alert Application B that a bid has been placed. Then from Application B, should the user choose to accept the bid, I need to send an alert back to Application A (to update current price, increase bid etc...)
In all honesty, in might just be simpler to have each application push the notifications to each other via standard service calls (WCF, ASMX, HTTP handler endpoints, MVC controllers, whatever). SignalR is useful in browser to server communications because there isn't a consistent way to do push from the server to a connected browser. But from web app to web app pushing is simple; Application A just calls a service endpoint on Application B to notify it of something happening.
Assuming that what you want is something like ...
User (browser) --- Application A --- Application B --- User (Browser)
Realtime communication can be done by doing the following ...
This isn't the job of signalR however something like NServiceBus would fit this very well.
you reference a bus dll file and hubs can both raise and respond to events.
In your case you would have both SignalR and your Service Bus technology work together to allow the cross application sync.
So the process is something like ...
User in application A fires up browser and requests page.
Application A creates Hub instance which internally subscribes to Service Bus events
User in application B fires up browser and requests page.
Application B creates Hub instance which internally subscribes to Service Bus events
User on either application does some action resulting in SignalR picking up a message.
SignalR raises bus event to say "This user did something" on the service bus.
Other Hub on other Application through subscribription to the event gets notified of the event and takes any action to inform its connected users of it.
Lesson to be learnt here ...
Don't try and make a technology do something beyond its purpose ... use the right tool for the job.
This entire solution can be done with little more than about 20 lines of code after getting the core framework setup.
NServiceBus can be found here:
http://particular.net/nservicebus
Disclaimer: There may be other solutions but this one suggestion don't assume this is the only way this can be solved, and the only technologies that be used in this manner.
I am not affiliated in any way with Particular or the NServiceBus product.
Related
i have a bit theoretical question.
When creating web applications, there is difference to desktop applications with working and active connection to database. So im curious if there is some solution, which can provide more desktop-like access to database e.g. transactions on asynchronous requests from client (web browser)?
edit:
So i figured out, that there can be a transaction process of asynchronous request, from client. Is there solution, which can provide it in web apps?
e.g I have assynchronou ajax call, which consist of multiple operations, and i wana to process them as transaction. If everything is okay, operations will be all done. But if one of them fail, just rollback it. Like its in DB. Is it possible?
edit2: maybe im wrong and the issue is not about ajax, but about whole web applications, but i dont think there is a way how to make a asynchronnous request from web client.
Transaction need continuous connection to database. To make it work with web application you need a platform which allow the application to run continuously independent of client request. Java servlet is best fit, php is a no-no. So I asume you will use java servlet.
In java servlet, you can create a db transaction, create an id for it, and then store them in a static variable or in the provided application-wide object, context. Then, return the id to the client.
When the client want to send another request, make it send the id. The application then can locate the transaction variable based on the id. As long as the application doesn't restarted between the two requests, the transaction is still there and active.
Because web application don't know when the user leave the application, you must create a mechanism to check the transactions periodically, and then rollback it if the user leave them for a specified time period.
The database has no knowledge of who is connected outside of authentication.
I am trying to craft a facebook-like notification system in our ASP.NET MVC website
In a scenario, the notification system works like this
User1 follow User2 by clicking the follow button in the MVC site
the MVC site send a NotificationItem to the NotificationManager via API request.
POST api/notifications/send
NotificationManager then process this notificationItem and then save it to Azure Table Storage
class NotificationManager {
void SaveNotification(NotificationItem item) {
// save it to azure table storage
}
}
After saving item, the Client (User2) then subscribe to the notificationEvent via the NotificationHub (SignalR hub)
NotificationHub then notify User2 along with the processed notification data.
class NotificationHub: Hub {
async Task NotifyUser(string recipientId) {
// query data from storage and then process it
var notificationData= await _repo.GetProcessedNotificationDataAsync(recipientId);
Clients.Group(recipientId).notifyUser(notificationData);
}
}
I tried to illustrate the CURRENT process and the architecture on this image
Now, the one that bothers me is this line of code in step number 5
var notificationData= await _repo.GetProcessedNotificationDataAsync(recipientId);
What it does behind is query the notificationItem from storage, process it to user readable notification (ei. "User1 is now following you"), then update the status of the notificationItem (IsSent, DateSent) behind.
Needless to say, it performs somehow "heavy" operation. And it will be triggered in real-time every time there is a new NotificationItem to be delivered or broadcast to each subscriber.
Obviously, im talking about performance and scalability issue here. So I researched some possible technology or approach that can solve this problem. And seems like using Azure Service Bus backplane approach is a viable option
SignalR Scaleout with Azure Service Bus
Introduction to Scaleout in SignalR
One particular paragraph explains some limitations on this approach
Server broadcast (e.g., stock ticker): Backplanes work well for this
scenario, because the server controls the rate at which messages are
sent.
Client-to-client (e.g., chat): In this scenario, the backplane might
be a bottleneck if the number of messages scales with the number of
clients; that is, if the rate of messages grows proportionally as more
clients join
High-frequency realtime (e.g., real-time games): A backplane is not
recommended for this scenario.
Now - this one got me thinking, as in my case. Server Broadcast and Client to Client (and something in between) is applicable to what I am trying to achieve.
These are the notification event scenarios that I am currently working on (and its acceptance criteria)
Notify user for new followers (real-time or near-real-time notification)
Chat Messaging (real-time, will see if the chatter is currently typing)
Post a Status (real time or near real time)
Comment in a Post (real-time, will see if the chatter is currently typing)
After hours of thinking - What's in my mind right now (as a result of my lack of experience) is a
notification system something like this
As you will notice, this is very different from our current design. The current design only uses 1 Azure webrole.
In this, theres a webrole for the website, webrole for the hub, and a worker role to process the notification data. Therefore - distributing the "load" to 3 different roles as well as opening the possibility for scaling-out.
Now - this is my questions in my head right now.
Is this architecture right for what I am trying to achieve?
Since the notification is in the queue - can we achieve "Real-time" notification update on this?
Since we separate the SignalR hub in another web role - how we will handle authorization?
Service Bus Queue or Azure Queue?
Any help will be appreciated.
Note: I intend to only use Azure technologies as this project is really an Azure and .NET oriented.
Yes, your architecture looks like it should do the job, for a load balanced scenario.
If you use ServiceBus Queue it should be, you can integrate pretty easily (use the nuget package SignalRChat Microsoft.AspNet.SignalR.ServiceBus)
Auth will be fine also assuming your application is stateless and auth cookie will still be valid for both roles, assuming they are behind a load balanced scenario.
Service Bus. Here is some more info on how its done. http://www.asp.net/signalr/overview/performance/scaleout-with-windows-azure-service-bus
We have a asp.net webform application (3.5) & a wcf service hosted via windows service (a service library which is activated when service is started). Both are deployed in same server.
WCF service is used for few long running task.
Now a client want some customized report which is gonna take significant time.
My idea is to show a progress of the task in the UI, but I am struggling with the correct way to do it.
Is it possible in the following way,
On request from page , service starts the processing asynchronously and report the status to some variable. (I don't want to write to database)
A asynchronous polling from client page, which intern communicate with another operation of wcf service to retrieve the the variable value.
Ajax client can communicate with the wcf service but it looks like the service need to be hosted as web application (don't understand much here)
Any Other thoughts? any option on using wcf callback (duplex communication)? too much confused.
We achieved something similar a year back.
1) We created a WCF Server with Singleton InstanceMode which processes the request and at the same time keep status as well. Another method e.g. GetStatus returns status to client. It also provides error details, in case of any error. However we also persisted the processing details.
2) On web page we async hit getstatus once request is initialized and showed a progress bar on web page.
This worked great for us.
You could look into using something like SignalR to push responses from your web application to your client (among other benefits, this uses the comet technique and so reduces the amount of polling you have to do).
To get a response from your WCF service to your web app, you can either use an async request to the service, or use a messaging solution such as Windows Azure Service Bus.
We use Client > JQuery > MVC > WCF > Service Bus > MVC > SignalR > Client as a pipeline and it works very well for long-running processes.
I am trying to find the right approach for an application, that I am trying to develop.
Situation:
ASP.Net Website. User can make a request on a page. The request must result in an item in a qeue on the server. The qeue targeted is specific for each customer.
WPF client at customer site. The WPF client has a local qeue. The qeue gets filled by either polling the qeue on the webserver or getting a message from the web server. The WPF client uses the qeue to display items as specified in the qeue.
Each WPF client user has it's own account and can only access the qeue that is meant for him.
I dont have any constraints yet as to which solution to use, as long as it is .Net technology and the customer only requires my deployment package and the .Net framework. I can't hassle customers to install something like MSMQ.
I think a database on the webserver containing all the requests could do the trick, but I am wondering if there are any other slick methods that could be better.
Cheers, Momoski
You are going to want to have your clients pull from the web server/service and not try to push updates out to your clients. There is way to much complexity for a push solution unless you have complete control over all systems involved (i.e. network, firewalls, etc...).
Suppose I have either an ASP.NET displaying my results, or a Silverlight client. And I'd like to show the current status of my server, or embedded device. (pretend the device reads temperature and humidity stats)
How should I send the status information from my device to the front end? Should I poll the device and save the results to SQL, Azure Table, or the like? (Azure is a technology that fits with this project for other reasons. That's why I mention it)
Or should I create a WCF service that polls the device directly and returns the current status.
What makes more sense?
In either ASP.NET or Silverlight you are going to have to poll from the client (web page or Silverlight app) to the backend to get the current status. In ASP.NET I'd look into doing this via an AJAX poll to a service using Javascipt (look at using Jquery or something similar to make this easier).
In silverlight you will need to have some sort of service configured to return the results and poll it using the Timer control running on a seperate thread.
You can also using a "push" binding within your silverlight app. Basically instead of you manually polling the server, the server will send you a push notification anytime it deems it necessary to let the client know of any change.