I am new to Solace MQ. My Question is,
How I can send request to Solace MQ from asp.net web application. What are the steps I need to performe to achieve this.
I have gone through the solace MQ Dev community and developer guide but it's not too clear for me. I want to understand the basic concept to send request to Solace MQ.
There's a step by step guide, with a sample application to send/receive a message over at http://dev.solacesystems.com/get-started/dotnet-tutorials/publish-subscribe_dotnet/
To summarize it, you will need to create and IContext, followed by an ISession. Then, use the ISession to send an IMessage.
Contexts act as containers in which Sessions are created and Session-related events can be handled. Sessions create a single connection to the Solace Appliance, and can be used for publishing.
Details on the Solace API concepts can be found at
http://dev.solacesystems.com/docs/core-concepts/
Related
I am currently evaluating a requirement for a project for which I am considering SignalR.
Here is a brief:
We want to have a server at our end that can send instructions to a client piece sitting somewhere in the world. The client piece then is supposed to do some local processing and send back a response that the server will show to the user.
The client piece by itself should also be executable and generate the report.
So we need some .net Code(console) at the client end(across the world) and some code at the hub end(our end).
Although this is not a ASP.net application I feel like this is a good fit for websocket communication.
I am looking for some guidance on getting a very very basic structure chalked out as I am new to SignalR.
Technologies :
.net 4.5
Follow the guides for setting up your hub and using the .Net Client.
Essentially, the console applications are clients to your hub. Think of the hub as a relay. You can google "signalr console application" and get plenty of information on how to set that up.
I'm currently fighting my way through Event Hubs and EventProcessorHost. All guidance I found so far suggests running an EventProcessor in an Azure Cloud Service worker role. Since those are very slow to deploy and update I was wondering if there is any Azure service that lets me run an EventProcessor in a more agile environment?
So far my rough architecture looks like this
Device > IoT Hub > Stream Analytics Job > Event Hub > [MyEventProcessor] > SignalR > Clients...
Or maybe there is another way of getting from Steam Analytics to fire SignalR messages?
Any recommendations are highly appreciated.
Thanks, Philipp
You may use Azure Web App service with the SignalR enabled and merge your pipeline "steps" [MyEventProcessor] and SignalR into one step.
I have done that a few times, started from the simple SignalR chat demo and added the Event Hub receiver functionality to the SignalR processing. That article is close to what i mean in terms of approach.
You may take a look at Azure WebJobs as well. Basically, it can work as a background service doing your logic. WebJobs SDK has the support of Event Hub.
You can run an EventProcessorHost in any Azure thing that will run arbitrary C# code and will keep running. The options for where you should run it end up depending on how much you want to spend and what you need. So Azure Container Service may be the new fancy deployment system, but it's minimum cost may not be suitable for you. I'm running my binaries that read data from EventHubs on normal Azure Virtual Machines with our deployment system in charge of managing them.
If your front end processes using SignalR to talk to clients have a process that stays around for a while, you could just make each one of those their own logical consumer (consumer group) and have them consume the entire stream. Or even if they don't stay around (ie you're using an Azure hosting option that turns off the process when idle) you could write your receiver to just start at the end of stream (as opposed to reprocessing older data), if that's what your scenario requires.
I'm working on getting Microsoft Orleans "Grains" to put events onto a SignalR bus. There's an example project that does this, and I've linked to SignalR integration below.
It looks to me that this sample is using meta-data from the Azure Web and Worker roles to enumerate all the web roles, and explicitly publish messages to each one. It seems to me that if SignalR's backplane is configured properly on the azure web roles that this shouldn't be necessary -- one HubConnection/HubProxy should do it. Is that right?
In fact, when I look closely at the file linked to below, and see some of the odd logic in the Hub itself, I wonder if the sample functions as a rudimentary backplane.
I'm hoping someone with deeper SignalR experience can clarify this for me.
SignalR integration example: https://orleans.codeplex.com/SourceControl/latest#src/samples/GPSTracker/GPSTracker.GrainImplementation/PushNotifierGrain.cs
The sample is a rudimentary backplane, in that it sends the message to all web roles instances present in the deployment, and therefore doesn't require a complete backplane (such as Redis). However, it won't propgate client originated messages to the other servers.
A more complete Orleans backplane for SignalR is available here: https://github.com/OrleansContrib/OrleansR
I'm working on a client and server application, in which client requests 'client-specific' data from the server. I'm planning on switching to ASP.NET WebAPI for server so that client can take advantage of available .NET APIs to query server for data.
This scenario works perfectly fine when the client initially connects and requests data from server, However, instead of client constantly polling for data, it should just establish a persistent connection and the server should be able to monitor the database for changes and push new data to the client that has stale data. I came across SignalR and found that it can be used with WebAPI, but can't figure out how to integrate it with database monitoring i.e. a thread or process that is constantly monitoring database for updates. Any solution? I'm open to other non-WebAPI based .NET technologies as well - basically anything .NET based that will cut-down on the development time.
ASP.NET Web API supports PushStreamContent. Take a look at the section "Push Content" in http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx. Here, a timer triggers content written into the stream but you can use that to poll database and write into response or build some other better mechanism
signalR could fit your requirement. You can broadcast a message to all your user or just to part of them. Your client could be a browser (with javascript) or a .net client (WPF or else).
From the server, you can call a method on the client just like that
Clients.All.MyMethodOnTheClient(param1, param2)
or
Clients.Client(connectionId).MyMethodOnTheClient(param1, param2)
The topic is too broad to answer it in 5 min. I can advise you to start here.
Then browse the server api guide, the javascript guide and the .net client guide.
Don't worry. It's quite fast to have a complete tour.
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.