I'm currently adapting a desktop swing application for the web.
I'm migrating the front end to an Angular.js app, and leaving the majority of the back end business logic as is (the goal is to be minimally invasive and keep things working for our first iteration). I will interact with the back end service primarily through REST calls. In theory, this should work.
However, I have one little hiccup. The application in its current form relies on numerous prompts to the user before continuing or adjusting the processing of its task. These being done through a desktop swing app, are handled through synchronous alerts (all isolated in a single class, thankfully), the resulting response affecting the application flow.
For example, something like parsing field strings to numbers might be handled through an alert:
if (Alert.convertStringsToNumbers()) { // blocking call. Response is boolean value
// continue processing
} else {
// abort
}
In order to keep the web-app version performant, and without resorting to long-polling, the idea is to swap out the synchronous alerts with websocket communications. However, with sockets being asynchronous, I'm not sure how to pause processing of the task until the user responds to the dialog.
Note, I've spent my last 5 years doing primarily JS work, so I'm assuming there's some extremely simple way I can do this which I'm just not familiar with in Java.
If it helps, I'll be using Tomcat 7 with their catalina implementation of websockets, rather than the standard Java EE 7 version (finally supported in Tomcat 8).
Is it something as simple as wrapping an alert in a runnable, and waiting for a response before returning control to the rest of the application? Or is something more complex required?
Update Per the comment below, and to clarify:
The point of the exercise is to push the majority of the app to the server as a service. The front end will be entirely browser based, using Angular.js. To get this version out the door quickly, I want to make the minimally invasive changes to the synchronous api to allow for wrapped, asynchronous communications over websockets.
Related
I'm implementing a multiplayer option for a chess game I made, but I'm starting from zero to do both client and server. A friend said to me to make the game happen in the server, and the client only gets the data and shows in the GUI. Does this means that I have to implement the game in the server (without GUI); and in the client project, just the GUI, actionListeners and stuff, so that, for example, when I click on a piece and then click where I want it to go, the server will "make" the move (set new position etc) and then send this information back to the client so that it can print? Is this the best approach?
By the way, my server can (will) host several games (each time 2 sockets connect it creates a game thread). Oh and also, after finishing the game, I want to implement a little chat in-game. Don't know if this information changes something...
Longer answer is that you really have a lot of flexibility in how you want to do this. The "traditional" way of doing this is the model-view-controller pattern, where you separate the model (game state) from the view (what the board looks like), and a controller (your server code) handles interaction between the two.
The question is where to place each section of code.
One option is to place have the client do the heavy lifting with the server acting as a middleman between clients and communicating updates. This has the advantage that servers don't need to do as much work, but results in a client that can be easily modified for cheating.
The other option is to place most of the important code on the server and simply have each client be a "dummy" display that just shows whatever the server sends and just send the bare minimum amount of information to the server for the server to determine what was done. This is more hackproof, but places greater load on the server.
You can also do a hybrid model where the both the client and the server share the load of sanity checking, so the load on either isn't quite as severe. I think that this is a pretty good option, even though it violates the "pure" MVC pattern.
What works "best" for you might depend on the kind of load you expect on your server. For a small number of connections, "pure" MVC with "dumb" clients might work. Client makes move, server verifies that the move is valid, and if so, sends updates to both clients. If your framework starts to get overwhelmed you might want to consider putting some checking code in the client though.
None of this affects having multiple pairs of clients or a chat. You should be able to implement each of those parts separately, and if done correctly piecing the modules together shouldn't be bad.
I'm working on porting a desktop application (WinForm) to a web application (Java/Spring/JPA). The problems are many and I'm struggling a bit...
Now the problem is threading!
In the original application, that performs the export of certain data from the DB, there is a progress-bar indicating the progress of the process.
I want to port this progress-bar in the new web application. To do this I thought of using AJAX and use a separate thread to run the data export.
The main concerns are:
Am I following the right approach? Are there problems using multi-threading in web applications?
If during the export process F5 or refresh button are pressed what exactly happens? How can I stop the process?
How do I update the progress bar periodically? Do I have to make calls via ajax to the server?
I'm primarily an ASP.Net developer but from what I know of the HTTP protocol this just isn't the way to go about it. I've seen a lot of fairly clever solutions for this but in the end what becomes clear is that the HTTP protocol simply isn't designed to work like this.
Obviously you're aware that a flash or silverlight app would be able to do this but that comes with it's own set of issues.
Myself I prefer to keep all the weirdness on the server. In the past I've had to come up with a way to deliver several thousand emails through a web application and update the user on how it's coming along. I designed a set of tables to act as a queue. The web application would simply place any delivery requests in this queue and the progress bar would be determined by a request that checks the status of the items in the queue. Running in the background was a windows service which would also check this queue and was actually responsible for delivering the mail and setting the status of each item as it completed or failed.
It was a bit difficult to develop since windows services can be tricky but once it was up and running it was extremely smooth and reliable. Depending on your circumstances perhaps a simple scheduled task set to run every few minutes would do the trick for you.
I wouldn't necessarily jump straight to running a separate thread explicitly for the export. While it would be ideal to do this, the capability of the web container to do this is going to be a limiting factor. Your traditional Java EE app server generally discourages spawning threads for this (though you can hook up to a thread pool for this). Some containers are great at freeing up the threads from blocking until the work is done (Karaf with Jetty and Camel, for instance) so that they can service other web requests while the export is occurring. But my guess is that you're probably okay with the "start export" thread blocking until it receives a response.
How long does this export take? A couple of seconds, or are we talking closer to minutes here? If it's shorter, I'd think that just putting a little "Waiting" icon with the little circular spinner on it (using your favorite Ajax library, whatever that is) would be sufficient.
If you really want a true status bar that periodically refreshes itself, then yes you'd have to poll for it at some frequency. Presumably that could be a simple request that would load some kind of progress for the job from a database table for that job ID.
Find my answers Inline
I am following the right approach? Are there problem in using multi-threading in web applications?
-Yes you are on correct path. No there is no such problem in multi-threading in web application and its as easy as you do it in WinForm. Instead of using Dispatcher to update the UI, you would be making AJAX calls and with javascript DOM manipulation would take place.
If during the export process F5 or refresh button are pressed what exactly happens? How an I stop the process?
-Unfortunately there is no easy way. The standard way is, when such kind of processing is done and the user hits F5, you would show a dialog(with help of javascript) and inform user that the job is still running. If the user still wants to refresh then you have make another request to the server for cancelling the task.(You need to store thread id or cancellation token some where to cancel the task)
How do I update the progress bar periodically? Do I have to make calls via ajax to the server?
-The standard way is, generally you show show a loading image. IF you want to show a context senstive progress bar, it would mean you have to do polling. Here is an example by Dino Espito. Though its in ASP.NET, you could understand the underlying principle
Dino Espito
I'm looking for a elegant way to create a queue for serving up batch compiled applets.
I have hacked together a SQL and PHP script to handle this but it chokes under mild loads.
is there an existing system that can handle taking a list in SQL and serve the applets in descending order each time it is requested. I'm also trying to handle this all server side as well.
The trick would be getting file001, then file002 ++ ect. to get served each time a web page is loaded. I'm batch creating applets that has a slightly modified background and I'm trying to serve a never been used applet waiting in the queue to load each time the a page is requested.
Is there a applet server I can tweak or does look like something that needs to be built?
No, I have never heard of a "batch compile applet server".
Could you maybe explain in more detail why you feel this is necessary?
Why don't you just use the same class and pass parameters to it?
That said, you can do compilation on demand quite well with e.g. ant and / or CruiseControl. You could put the pre-compiled applets into a directory. Then your PHP frontend just needs to keep track of what applet it delivered last, and fetch the next one the next time.
Still, this sounds rather complicated to me; so maybe you could explain your motivation.
In particular, why do you want a new applet on every reload? Would that not be rather confusing? Why not offer a link for each variant, so the user can choose?
I'm trying to implement a Cometd/Bayeux server on Android using iJetty. The Jetty implementation itself works just fine serving static pages along with servlets. I am trying to up the ante a bit and create a Bayeux application on the phone but I'm having some trouble. I can hit the page that has the dojo cometd scripts on it, but I am unable to subscribe to the channel. When I view firebug/chome developer tools, I see a series of posts/gets that last a couple of milliseconds (~14). However, when I run a cometd application on a normal machine, the posts/gets last several seconds (~14 seconds) before timing out and reopening the connection. This second scenario makes sense to me with my understanding of how continuation in HTTP works. So I'm thinking that something is not allowing those connections to hang open and prematurely returning a value and consequently closing the connection. I would post my source but I'm not sure what to post short of posting everything...(it is open source though so if you want to have a look it's at http://webtext-android.googlecode.com).
So my question is, does anybody think that there could be some underlying limitation imposed by the Android system that is preventing these servlets from working? Are there assumptions that are made by the Jetty Bayeux implementation with regards to the underlying system? Or is it more likely that somehow I have a bad implementation of the ContinuationCometdServelt? I should note that all of the posts/gets from the client return 200 OK messages so I'm not inclined to think that the Android system is simply terminating the connection.
I know this is a bit off the wall and I'm definitely trying to do something a bit out of the ordinary but any suggestions or tips would be greatly appreciated.
In case anybody discovers this and has similar problems (this applies to all cometd implementations regardless of host), I discovered that the issue was with using the Google js library. For some reason, the dojo scripts I was loading from Google (1.4) didn't have a valid implementation of cometd. I switched my dojo script to the one that was used by the jetty-1.6.23 example and it works perfectly.
I am working on an application in Linux which will interfaces with hardware. One of the requirements is to create the GUI in Web-browser . the application will be c++ based. I m not familiar with web realted stuff so i want to know Is it possible to do such a thing (currently it's a console application take input from txt file/cmd line). gui will be simple using button and showing output messages on browser from the application. i want to know which technologies/languages are involved and how can it be done. some of the idea i read but havn't found anything concrete yet. if u have any idea about these or a better suggestion please share
run the app in background and communicate with browser ?
call library functions directly from browser ?
any other idea ?
I would start by setting up a regular HTTP server, like lighttp or Apache httpd.
You say you already have a command line program that does the actual work - As a first step, I would reuse that, and configure the web server to call your program using CGI - see forexample http://httpd.apache.org/docs/2.2/howto/cgi.html for apache
Finally, I'd pick some javascript framework like jQuery or YUI with Ajax capabilities to do requests to the server to call the CGI script from within a webpage. You could also create a form-based web application without ajax or any framework, but that would require you to stuff all kinds of logic in your program to generate HTML pages. By using Ajax, you can leave the command line application as is, and parse any responses it gives with javascript, and then use that to dynamically change the webpage in a way that would make sense to the user.
If this all works, then I would try to figure out how to package all these components. Perhaps you just want to create a simple archive with all the programs inside, or maybe you want to go as far as actually embedding the webserver in your program. Alternatively, you may want to do it the other way around and rewrite your program as an ISAPI module that you can plug into your webserver. Or if that's not integrated enough still you could write your own (partial) HTTP server. That's really up to you (I'd probably spend time and energy on searching for the leanest, meanest existing open source http serverr and use that instead)
At any rate, the prior steps won't be lost work. Most likely, developing the web page is going form a substantial part of the work, so I would probably create a quick and dirty working solution first using the age-old CGI trick, and then develop the webpage to my satisfaction. At that point you can already have an acceptable distributable solution by simply putting all programs in a single archive (of course you would have to tweak the webserver's configuration too, like changing the default port so it won't interfere with existing webservers.) Only after that I would spend time on creating a more integrated fancy solution.
I ended up using Wt though I'd update for future reference.
These are how I thought of doing this, in order of complexity for me:
Create a simple server-side-language (PHP/Python) website that can communicate with (ie launch and process the return of) your application
Modify your application to have a built-in webserver that just punched out HTML (command line parameters taken through the URL)
Modify the app to publish JSON and use javascript on a simple HTML page to pull it in.
You could write a Java applet (as you've tagged this thread) but I think you'd be wasting time. This can be quite simple if you're willing to spend 10 minutes looking up a few simple commands.
After 12 years, web browser-based GUI started to appear, WebUI is one of them.