My question is about a search of appropriate way of implementation.
I have an application and I need to make it to check for updates. Actually we shouldn't pay attention for the reason of sending the message. It may not be a message about updates but something else. What is the best way to implement it?
Now it asks my REST service while starting but what if the application is working a long time and I need to inform the user about updates? Maybe message bus can help or there is any best practice?
Thanks!
UPDATE
Just to clarify:
My client application asks service (REST) to check if there is any updates but I want to make the service to inform my client. So the question is what is the best way to send a message from the service to my client to inform about new application update.
For your szenario I'd use a REST server and send a request every few hours. If you want your server to notify your client, SignalR should be a good choice.
https://learn.microsoft.com/en-us/aspnet/signalr/
Related
After much research and bumping into the wall a couple of times, it's time to ask some questions.
I'm developing a project which is going to send a message from a web client to a server, then the server should notify multiple clients about the update, which should be done in seconds.
First I thought of using GCM notifications, but the user then have to push the notification in order for some code to run on the client (turning on gps and stuff) but my clients don't have time for clicking the notification when it arrives. So it has to be done without user interaction.
Next thing I thought about was if the android client could listen to the c# server and run code when the server had a new message, but I haven't found a working torturial yet. I was looking into GCM again without push, just messages back and forward, but it's getting difficult to get to work. Also sockets was a option, but it also seems really difficult to get to work and I'm not sure if those options are the way to go.
So I was thinking to just let the android have a background service which is polling either a database or a method on my c# server.
Can anybody give me an idea of what is the right option and maybe a link to a tutorial which is a nice step by step thing.
It could be nice if I had the option to also use it on IOS at a later point.
If i understand correctly, what you are trying to do can be easily done by one of the following or more ways:
1)Use GCM messages with a Payload! When the mobile client receives the Notification it gets the Payload and proceeds on specific actions. http://developer.android.com/google/gcm/adv.html - http://developer.android.com/training/cloudsync/gcm.html#react
2)Use a SyncAdapter and make your app use an AlarmManager which will periodically tell to the app to poll the server through the SyncAdapter and check for new content. Another way of triggering the SyncAdapter is sending a GCM notification like in the first step. http://developer.android.com/training/sync-adapters/creating-sync-adapter.html
I need a way for clients (C# applications) of a ASP.NET Web API to be notified of certain changes via the Web API. They don't even need to know what the changes are, just need to get a notification that something changed (at that point it's up to the client to call the API to get any specific data they may need after getting the notification). I'm not sure what a good way of accomplishing this would look like.
I'm thinking one way might be to create events and somehow have the client subscribe to those events, but I don't know how to do that through Web API.
I found some mentions of SignalR on Google, but this seems like a lot of work to implement and seems to do a lot more than I need.
All I need is for the Web API to be able to tell the client "something changed, come and get it". However, I want to avoid polling. What is the fastest/easiest way to do accomplish this?
You really have only two options:
Use SignalR or any kind of Websocket framework.
Have the client apps poll the API to look for changes.
Web API is stateless by design. The API doesn't maintain any kind of connection or state information with any of the client applications. Therefore there's really no way to implement anything like a traditional C# event.
SignalR would be the coolest way to do it ;)
But the simplest thing to do is just poll server once every X and ask 'Did anything change?'.
3 years later..and there is one more option that looks very promising which is WebHooks
Polling
SignalR (Server<->Server, Server<->Browser)
WebHooks (Server<->Server)
Difference between SignalR and WebHooks
I think that SignalR is for bidirectional communication between client and server. For an SSE (Server sent Event) use PushStreamContent instead. https://techblog.dorogin.com/server-sent-event-aspnet-core-a42dc9b9ffa9
Google firebase can also be used for this. You can write firebase code in your client application(javascript or mobile app etc.) which can be triggered whenever any change occurs on firebase.
So whenever something happens on your server hit the firebase url and that will raise the event which can be caught on the client side.
May be it can help.
We are currently trying to implement workflow functionality in our product (.NET 4.5). For this we consider using Microsoft Workflow Foundation 4.5. However in this early stage we bumped into a technical problem of something that seems very doable.
Simply put this is what we want to achieve in our client/server setup:
Based on a specific event the server starts a workflow
The workflow executes some actions until it comes to an activity that requires human interaction. It should then wait for a message from a client.
One client (there are multiple clients) becomes the owner and therefore should send its unique id or address to the workflow
The workflow sends a message to that client indicating that it requires information to continue (e.g. e-mail parameters like recipient, subject and body)
After several minutes (could be a few minutes to a few hours) the client sends the information to the workflow so that it can continue (e.g. send the e-mail message)
If another human interaction is required, the server sends a request message to the client again so that it knows it should ask the user for information and then the client sends a message to the workflow again (like above)
For what I understood a 'normal' workflow does not have an endpoint to receive messages. A workflow service on the other hand does, but with WF services the workflow instances would be created based on the incoming requests rather than having the server be in control of the creation of workflows (right?).
At this moment it appears to me that we need a combination of a workflow and a workflow service.
I've been struggling with this for a while now and searched high and low but cannot find useful information about it.
I think we have two options:
Workflow services;
If we would use workflow services, we could have a Receive activity at the beginning of the workflow that starts the workflow. However, then how can clients communicatate with that specific workflow? A workflow service has one specific URL.
Workflows;
A normal workflow that is hosted by a server application seems the most natural path to choose. However, then we need a way to send data to it. So, is it possible to upgrade a normal workflow so that the Receive activity can be used? And if so, how? And how do messages end up in the right workflow instance?
My questions are:
Does anybody have some useful guidance or information on how to solve the above problem?
Are there interesting alternatives (not using WF?) to accomplish this?
Does anybody have documentation about how WCF messages are routed to the correct workflow instance in WF?
PS: We have a WCF service available on the client. A workflow can communicate with that. For short running requests that isn't a problem, but the thing is that requests can take a long time before the client 'answers' them. Also, the client can only request the information if the user clicks on a continue button (the users should not get a popup just in the middle of something because the server wants information)
Yes, the Workflow Service with AppFabric is ideal and should just work out of the box if I understand your problem correctly.
For your question "However, then how can clients communicatate with that specific workflow?" the answer is correlation and you can easily set that up in the first Receive. You just add a CorrelationHandle variable and set the Receive's CorrelatesOn for an incoming parameter (ownerid?) and CorrelatesWith to that handle. Do the same for all other receives and the incoming messages will always be routed to the right instance.
AppFabric will help in that your WF service will be unloaded from memory and persisted when it's idle for too long, woken up when the new receive comes and etc. It will also help in that you can set autostart on your IIS app pool. WAS will activate your workflow service on incoming request.
If you need further specific details just let me know.
This might look a question where you can read the answer on MSDN, but I still want to ask about the scenario, as I want to solve the business problem.
I have a service hosted on a server, and a client makes service calls. It currently uses netTCP binding. Everything works fine when the service is available, when the server is up and running. Now, I need to handle the server down scenario. I use the local cache file on the client to serve the client requests in case of server down scenario. Now I want to cache all the requests made while server down and want to make service calls once server is up and running.
I am thinking about using the netMsmqBinding, because all I've read suggests that it works well in the disconnected scenario.
Q.1 Can I use the netMsmq to handle this scenario?
Q.2 If not then what could be another approach with which I can follow to solve this problem?
Q.3 Can I use WS-Discovery in case of server down to find that the client calls won't be able to contact the service?
EDIT : The scenario is Client-Server. But i do need to give response on every call to the client. The client is also developed and maintained by me only so i am in a good position to implement the best suitable solution.
Please guide me as I'm not too good with WCF.
Yes, you can use netMsmqBinding for this purpose. We are doing that for services running over a satellite link that can be down often.
One important limitation you need to take into account is that all calls must be one way, being a queue-based transport. If you need to get the results of a request, you'll have to provide a separate response mechanism (it can be a similar queue in the opposite direction)
Ad question 1: using MSMQ is excellent for a scenario where the service may not always be up and running. Note that the server that hosts the message queue must be up and reachable to receive the messages. However, you haven't told us anything else about your scenario, particularly why you currently have NetTCP. The reason that's important, is because there are some things you can not do with MSMQ, for example duplex communication won't work out of the box.
Ad question 2: an alternative may be to implement logic in the client (it's unclear from the question if you're the owner of the client software) to have a local queue and retry messages later if a service is (temporarily) offline. I guess you may even have a proxy MSMQ service on the client, relaying the messages to the main service once it's up.
Ad question 3: yes, you can use Discovery for this. The service will have to announce to the clients when it goes online or offline. The simplest example is using the UdpAnnouncementEndpoint. In the clients you can use the AnnouncementService class to listen to the service coming online or offline, and keep a local list of available services. Alternatively (for example when UDP broadcasts aren't feasible) you can create a discovery proxy service at a well known location that listens to announcements, which the clients can access for instant-knowledge on whether the service they need is online
I have an application built that hits a third party company's web service in order to create an email account after a customer clicks a button. However, sometimes the web service takes longer than 1 minute to respond, which is way to long for my customers to be sitting there waiting for a response.
I need to devise a way to set up some sort of queuing service external from the web site. This way I can add the web service action to the queue and advise the customer it may take up to 2 minutes to create the account.
I'm curious of the best way to achieve this. My initial thought is to request the actions via a database table which will be checked on a regular basis by a Console app which is run via Windows Scheduled tasks.
Any issues with that method?
Is there a better method you can think of?
I would use MSMQ, it may be an older technology but it is perfect for the scenario you describe.
Create a WCF service to manage the queue and it's actions. On the service expose a method to add an action to the queue.
This way the queue is completely independent of your website.
What if you use a combination of AJAX and a Windows Service?
On the website side: When the person chooses to create an e-mail account, you add the request to a database table. If they want to wait, provide a web page that uses AJAX to check every so often (10 seconds?) whether their account has been created or not. If it's an application-style website, you could let them continue working and pop up a message once the account is created. If they don't want to wait, they close the page or browse to another and maybe get an e-mail once it's done.
On the processing side: Create a Windows service that checks the table for new requests. Once it's done with a request it has to somehow communicate back to the user, maybe by setting a status flag on the request. This is what the AJAX call would look for. You could send an e-mail at this point too.
If you use a scheduled task with a console app instead of a Windows service, you risk having multiple instances running at the same time. You would have to implement some sort of locking mechanism (at the app or request level) to prevent processing the same thing twice.
What about the Queue Class or Generic Queue Class?
Unfortunetally, your question is too vague to answer with any real detail. If this is something you want managed outside the primary application then a Windows Service would be a little more appropriate then creating a Console... From an integration and lifecycle management perspective this provides a nice foudation for adding other features (e.g. Performance Counters, Hosted Management Services in WCF, Remoting, etc...). MSMQ is great although there is a bit more involved in deployment. If you are willing to invest the time, there are a lot of advantanges to using MSMQ. If you really want to create your own point to point queue, then there are a ton of examples online that can serve as an example. Here is one, http://www.smelser.net/blog/page/SmellyQueue-(Durable-Queue).aspx.