I have a jobcard System where jobcards will be delivered between employees. Each Employee will have their screens open. I want to make a site which will give them notification when they will get a new job card. How may i start building it?
Ajax and some real time server thing. Read more on "pull" and "push." This is a little bit of complicated topic. There is no clear cut answer. Read on "push" technology on Ajax. Or timely polling.
I would go for polling. I.e. having an client-side timer that periodically asynchrony calls a server function that checks for new notifications and displays them to the end-user.
Another option would be something called HTTP server push, but from what I read this could be rather tricky to work on every browser and also could consume more server resources.
Related
I have an endpoint which returns the response containing hotels and a flag which shows more results are available, the client needs to call this endpoint recursively till the time the server returns more results flag as false. What is the better way to implement this? Could anyone help me on this?
First Option: Avoid It If Possible
Please try to avoid calls on HTTP APIs so as to avoid network latency.
This is very important if you want to make multiple calls from a client which is supposed to be responsive.
e.g. if you are developing a web application / WPF application and you want user to click on something which triggers 10-20 calls to API, the operation may not complete quickly may result in poor user experience.
If it is a background job, then probably it multiple calls would make more sense.
Second Option: Optimize HTTP Calls From Client
If you still want to make multiple calls over HTTP, then you will have to somehow optimize the code in such a way that at least you avoid the network latency.
For avoiding network latency, you can bring all the data or major chunk of the data in one call on the client side. Then client can iterate over this set of data.
Even if you reduce half of the calls you buy much more time for client processing.
Another Option
You can also try to think if this can be a disconnected operation - client sending just one notification to server and then server performing all iterations.
Client can read status somewhere from database to know if this operation is complete.
That way your client UI would still say responsive and you will be able to offload all heavy processing to Server.
You will have to think and which of these options suits High Level Design of your product/project.
Hope I have given enough food for thoughts (although this may not be solving your issue directly).
Consider a web application that implemented every database action except querying (i.e. add, update, remove) as a NServiceBus message, so that whenever a user calls a web API, in the back-end it will be mapped to await endpointInstance.Request method to return the response in the same HTTP request connection.
The challenge is when a message handler needs to send some other messages and wait for their response to finish its job. NServiceBus does not allow to call Request inside a message handler.
I ended up using Saga to implement message handlers that are relied on some other message handler responses. But the problem with Saga is that I can't send back the result in the same HTTP request, because Saga uses publish/subscribe pattern.
All our web APIs need to be responded in the same HTTP request (connection should be kept open until the result is received or a timeout exception occurred).
Is there any clean solution (preferably without using Saga)?
An example scenario:
user call http://test.com/purchase?itemId=5&paymentId=133
web server calls await endpointInstance.Request<PurchaseResult>(new PurchaseMessage(itemId, paymentId));
PurchaseMessage handler should call await endpointInstance.Request<AddPaymentResult>(new AddPaymentMessage(paymentId));
if the AddPaymentResult was successfull, store the purchase details in the database and return true as PurchaseResult, otherwise return false
You're trying to achieve something that we (at Particular Software) are trying to actively prevent. Let me explain.
With Remote Procedure Calls (RPC) you call another component out-of-process. That what makes the procedure call 'remote'. Where with regular programming you do everything in-process and it is blazing fast, with RPC you have the overhead of serialization, latency and more. Basically, you have to deal with the fallacies of distributed computing.
Still, people do it for various reasons. Sometimes because you want to use a WebAPI (or 'old fashioned' web service) because it offers the functionality you don't want to develop. Oldest example in the book is searching for an address by postal code. Or deducting money from someone's bank account. If you're building a CRM, you can use these remote components. These days a lot of people build distributed monoliths because they are taught at conferences that this is a good thing. In an architecture diagram, it looks really nice, but there's still temporal coupling that can provide a lot of headaches.
Some of these headaches come from the fact that you're trying to do stuff in an atomic action. Back in the days, with in-process calling of code/classes/etc this was easy and fast. Until you hit limitations, like tons of locks on a database.
A solution to this is asynchronous communication. You send some information via fire-and-forget. This solves temporal coupling. Instead of having a database that is getting dozens and dozens of requests to update data, etc. and as a result, your website is grinding to a halt, you have various options to make sure this doesn't happen. This is a really good thing, because instead of a single atomic operation, you have various smaller operations and many ways to distributed work, scale your system, etc, etc.
It also brings additional challenges, because not everyone is able to work with fire-and-forget. Some systems that were already built, try to introduce asynchronous communication via messaging (and hopefully NServiceBus). Some parts can work flawlessly with this. But others parts can't. Mainly the user-interface (UI). Because it was built to get an immediate result. So when you send a message from the UI, you expect a result!
With NServiceBus we've built a package called "Client-Side Callbacks" to make exactly this a possibility. We highly recommend our customers not to use it, except for this specific scenario that I just described. It is much better to migrate your entire UI to be able to deal with the fact that you don't receive an immediate answer, but we understand this is so much work, that not many will be able to achieve this.
However once that first message was sent and the UI received a result, there is no need to use callbacks anymore. As a result I'd like to propose this scenario:
use call http://test.com/purchase?itemId=5&paymentId=133
web server calls await endpointInstance.Request<PurchaseResult>();
PurchaseMessage handler retrieves info it needs and sends or publishes a message to (an)other component(s) and then replies back to the web server with an answer.
The next handler works with the send/published message and continues the process
Let us know if you need more information. You can always contact us by sending an email to support#particular.net
I have an c# asp.net management system with a button that calls a SQL Server Query to get 90,000 strings of text in multiple languages and categorized into sections. This in turn is sorted and 150 Binary files made before saving as a .ZIP and emailing the user with the results. The total time to process this and email the results is about 6 minutes. In this time the Web Page is sat waiting for the whole process to complete. I would like to be able to press the start process button and then allow this to work away in the background while I continue using the web management system, but I am unsure what is the most efficient method for doing this. I initially created an asmx file thinking this would work but the result is the same and so I am now looking at async and await. Can anyone give me any pointers on this and let me know if I am on the right track. I am currently not getting anything back to let me know the process has completed successfully as I can handle this by emailing the user to say something went wrong. The reason for this is the user could be on any number of pages.
There are probably a few ways to go about tackling this problem. Your options will vary based on what version of .NET you are using, so I'll not post code directly; however, the you can implement the concept I describe using ASMX web services, WCF, MVC, and so on.
Start-and-poll Approach
The classic response for this kind of problem is to implement a StartSomething() method and a GetProgress() method. A very-simple example of this approach using ASMX-based web services is presented here.
In the example, one service method is used to start a process on a background thread. Myself, I would change the example by having the start method return a value to the client to identify which background process was started, as you could feasibly have several going on at a time.
The client then can call a separate method to get progress updates, and continue polling until the process is complete.
There are a number of reasons why you should prefer to do lengthy background processing in a non-IIS service. I recommend using a Windows service to protect yourself from IIS somewhat-randomly restarting your application pool in the middle of a big job.
WebSockets
Another option worth some exploration on your part is to use WebSockets, which allow the server to contact a modern browser when the process is complete. The main advantage of this approach is that the client does not need to busily poll the service for updates. Its primary disadvantage is that WebSockets are new enough that there are still plenty of browsers that could not be clients for such a service.
Good luck!
Am working on a POC for self learning in which I want to keep my user connected in LIVE pattern. For example, A game in which 4 user can play at a time , here I need to keep this user connected to my game .
M not good at Socket type of programming and love to do that in Services way.What i wana know is 'What is the best way of doing this'. According to my initial Brain Storming, I have decided that I will use SilverLight(In Browser Or Out of Browser) as Front end [I have no issue in that].
I m more concern in back end.
Either I make an handler or make a WCF service or use full duplex service and use pooling mechanism for that. As a random thought I come up with a Timer type logic that will fire every after 10 seconds at clients end and get status like
Is it now Its turn to roll a dice
Home many user left (in case if
some of them left)
What are connected user status in
game like there score/points ect and
update
game view according to this at his end
Kindly place your best answers here that will help me to learn this.
Regards and thanks in Advance
EDIT:
Starting Bounty as i need more feedback.
FH
Fasih,
Since HTTP is stateless, you cannot make 2 way communication from your code. But there is a workaround if you are using AJAX. As you said timer is a one way. Another one is called COMET or Reverse AJAX.
This simulates the two way communication without relying on timer. To accomplish this you have to make a long running AJAX calls to the server, and the call is only returned if there is a change to update. Assume simple web chat scenario. 2 users make a long AJAX calls to the server, and both are polling the common medium (say DB), if the user1 sends some text, it will get updated and the user 2's waiting AJAX call pick up the text and return. And again both users will make a long running call to listen each other.
As you already decided to go ahead with silverlight, you can use WCF duplex channel to emulate the 2 way communication. As i explained earlier, dont go with timer logic. Its not instant if you are polling the server for 10 sec (anything can happen in a game within 10 sec), and it will increase the server load if you poll for each second.
So avoid timer logic and use long running AJAX calls.
If you are looking for options other than WCF duplex channels, HTML5 web sockets and COMETs are other ways to go.
check out this post for browsers supporting web socokets.
Basically it is a question of being able to push data to the client from the server.
So I was thinking is a subscriber publisher architecture, you can create a queue(in a db table for ex) on the server for each of users that are connected, and have an ajax calling a web service that will pull data from the table.
Every message should be encapuslated as a command for the client. So you can use different messages for each operation that the client is capable of. {command:display,text:"user blah blah has logged in"} another command could look like {command:rolldice, text:"roll the dice"}
Let me know what you think...
If you've decided to go for WCF then I would suggest you to use callbacks.
More info here: WCF: Working with One-Way Calls, Callbacks, And Events
-- Pavel
Scenario
I've written a distributed application in C# using WCF.
It uses Client/Server architecture, implementing the Publisher/Subscriber design pattern for "pushing" new data to the client.
The server-side is hosted in a windows service, the client is a windows forms app.
The server-side continually loops through a series of processes and sends the results to the client.
I want to add a whole area to the application for monitoring everything that is going on server-side.
Problem
Here is where I am a bit stuck - I can't decide how I should monitor this stuff.
Thoughts
Do I create an object for storing lots of different information - logs of where the process is up to in the loop on the server-side, exceptions if any, errors etc??
I guess the real question is, how can I successfully maintain a monitoring aspect of the application that gives me relevant information?
Perhaps a central cache on the server-side that gets "snapped" at a point in time every so often and updates the client with the info?
Do you want to know what's currently going on in the server or do you also want to keep a history of what has happened?
If you only want to know what is going on at this moment, my solution would be to maintain the current server state in-memory (this shouldn't be too hard) and have the monitoring client call the server when it wants to know what is happening.
If you want to keep a history of what has happened, you need some data store where the server can write events to. The monitoring client can then read this data store to show what is happening now and what has happened in the past. Even better would be if the client did not have direct access to this data store but instead contacts the server to obtain the relevant information. This way you hide the implementation details of your monitoring history from the client.