I need to create a user facing web interface (perhaps with HTML5 and Javascript) that allows a user to draw lines using a mouse. The interaction would involve mouse drag, clicks, etc. I need to send these inputs to a Java application on a remote machine and get back some result and update the web page the user's drawing on. So this would require a two way communication.
Since this is a proof of concept prototype, I need a solution that's easy and simple, and hopefully fast since the user would like to see the update quickly. What technology do you recommend to allow the communication between the web interface and java application? I was thinking about writing a simple server in Java and talk to the remote application using JMS... not sure this is the right direction.
Thank you for your insights.
Any servlet container, such as Tomcat, JBoss, Jetty, GlassFish or WebSphere would do.
I'm not sure JMS is a good fit here.
The browser would communicate with the server the way all web-apps do, via http requests. So, on the server you would use servlets, or some frameworks that builds on top of servlets, running in the container of your choice. You webapp would periodically send an xml http request (XHR/AJAX) to update the state of the drawing. Or it would do it when the user wanted to save their design.
Keep in mind what you are describing is a Web Application. This means that an application is running in the browser, so it can maintain its own state independent of the server. It just needs to sync up every now and again. You don't need to continuously send requests to the server.
it can be done also using RIA: actionscript3/flash+xml socket+java server. You can handle events via actionscript3 and then send parameters to server and after receive answer. There is lot of source for as3 drawing api after you can modify for socket connection.
have you tried this ? Look at the demo section on the shared canvas.
http://jwebsocket.org/
Related
I have a requirement where a Groovy Application is supposed to send event notifications to another Java Web Application Which will than display that data on
web interface.
I don't want to use Queues like ActiveMQ or RabbitMQ because this will introduce an extra layer and will be used if no other solution exists.
An idea have been shared with me that I should expose a web-service from my Java application, which will be consumed by the first application, and the data
sent to the web-service will be then received in second application and somehow displayed on it's web interface.
I am not sure how this will work i.e how the data which is received in web-service of second application will be displayed on its web interface.
Kindly help me to figure out the right solution for this task.
Your problem actually is "how to send notifications from server to browser/mobile client issued by another application".
If you have very strict requirements for latency, then I would suggest to use https://github.com/OpenHFT/Chronicle-Queue
It was created by HFT guys to process 6 millions of messages per second in a single thread.
To display events on user's screen please consider using mechanisms like WebSockets, Server Sent Events, Push Notifications, Long polling, whatsoever depending on your requirements ( like browser support ).
Actually in most cases it doesn't matter what transport are you using. Unless you have super strict non-functional requirements like sub microsecond latency you're free to choose any mechanism, e.g. HTTP, JMS.
Try not to over engineer and design your software based on your actual requirements - not on stackoverflow answers.
Cheers!
I would suggest you create an XML representation of the data you wish to transfer to the java web app. On the java web app if using simple servlets, create a new servlet to which you can post this xml. The servlet could then persist this to a database. This can then be retrieved when a user logs in to the web app at some point.
Let me know if you need any more help. I could only answer only so much based on the question. Some more light on the framework the java web app is using and the data you wish to transfer, might make it easier to add more info.
I'm not really sure how to describe the design issue I'm having so the title is very vague and possibly just totally wrong.
Basically, I have a web application which uses a number of different payment gateways, depending upon which one the user prefers.
Obviously the communication between the application and the gateway endpoint is going to be different for each. I need the way for my application to react to the response of the gateway by the means of a javascript alert (for now). The gateways might have different return url's back to the application, and it needs to work between browser sessions.
Any ideas or pointers to technology that will help with this?
If it helps the technology stack im using: Java, Spring, Struts
Thanks,
I would recommend a dedicated messaging layer with Redis, Socket.io or Rabbit.mq. I had the same issue with a medical app. If you want to stick to Java i would recommend an Observer pattern to pass event messages between classes but you still need a way to distribute notifications to the presentation layer handlers (Javascript) and thats were I recommend a socket server of sorts
I'm starting to study GWT now, and have a very general question, I could maybe teach myself with a little more experience, but I don't want to start it wrong, so I decided to ask you.
I always develop using JSF, having separate packages for beans, controllers and managedbeans.
However, as the GWT uses RPC, I will not have managedbeans, right?
So, GWT automatically handles user session for me, or do I have to do it myself?
What is the best package structure for the project?
It is best to use RPC, or create a webservice and access the webservice in GWT?
It's hard to host the application on a tomcat server?
Is there a test saying which server is faster for GWT?
Thank you.
However, as the GWT uses RPC, I will not have managedbeans, right?
True, GWT RPC uses POJOs.
So, GWT automatically handles user session for me, or do I have to do it myself?
GWT is pure AJAX APP - client code (normally) runs in one browser window (similar to gmail) and does not reload the web page. This means that the application state is always there - no need for sessions (as a means of saving state). You still might need sessions for user authentication, but this is usually handled by servlet container.
What is the best package structure for the project?
Three packages: client, server and shared. Client for GWT client code, server for server (also RPC) code and shared for POJOs that are used by both client and server.
It is best to use RPC, or create a webservice and access the webservice in GWT?
Go with GWT-RPC or (better, newer) with RequestFactory.
It's hard to host the application on a tomcat server?
It's straightforward: GWT client code is compiled to JS/html and is hosted as any static content. RPC server code is just Servlets - normal web.xml registration.
Is there a test saying which server is faster for GWT?
No clue, but IMHO does not matter, because most of the latency will come from database and network.
Also have a look at http://code.google.com/p/gwt-platform/
This framework is really great and follow all suggested best practices(e.g. MVP) by google and give you as well great support for gin, gwt dispatcher, website crawling, history with tokens, code splitting via gwt async etc.
If you want to set up a good project structure try to use the maven gwt plugin(http://mojo.codehaus.org/gwt-maven-plugin/) it helps you a lot with setting up an initial structure and manage your build process.
I'm really new to JSF but what I need to do is a webpage which can connect via JSF to database and show some statistics for given user and I know that JSF will do for such purpose.
What I'm worried about is that I need to write game server for turn-based game and my question is if this is common/good approach to include such server in JSF? Clients will be android devices so I will probably have to include some socket logic under whole JSF which will exchange XML messages.
At least thats how I see it.
Please let me know if my concept is valid or tell me what other tools I will need.
Yes, this is possible. JSF is great for building the web based admin or statistics pages.
But do note that the socket connections from the Android client to the Java EE server do not go via JSF. If it's simple turn based game, you could consider using REST calls to JAX-RS resources. These are very easy to create in Java EE (no config needed, just a simple annotation on a pojo).
So basically, your question is not phrased correctly. The game server is not build in or on JSF, but JSF makes use of some of the same backend resources.
Java Server Faces is only the framework for a web frontend and the communication or interaction to the backend. It's absolutely possible to write a little game server for android games with java ee.
As I understood your text the architecture is really simple: You've a client/server architecture and the server use the framework JSF for administration.
I think it's a good idea to write the server first and add the administration (JSF Part) later as component to the server.
I am working on a server application that does the following:
Read data from a measuring device that is being addressed via a serial interface (javax.comm, RXTX) or sockets.
Exchange data (read and write) with another server application using sockets.
Insert data from (1) and (2) into a database using JDBC.
Offer the data from steps (1) to (3) to a JavaScript-based web app.
My current prototype is a stand-alone Java application and implements task (4) by writing the data to an XML file that is being delivered to the client via a web server (Apache), but I consider this to be a hack, not a clean solution.
This server application needs to start up and work also without any web clients being present.
I would like to integrate this server application into a Java application server, but I do not have much experience with these technologies and don't know where to start. I have tried some simple examples for TomCat and GlassFish, but that did not bring me any further because they are all built around serving web requests synchronously and stop where it would be getting interesting for me.
Is this possible to run such an app within TomCat or GlassFish?
If yes, where would be a good point to start (examples, which base classes, ...)?
Would it make any sense to split the application and implement only task (4) in a servlet, the rest in an ordinary application, communication via sockets, etc.?
Would other servers, e.g JBoss, be a better choice and if yes, why?
Edit:
The reasons I want to use a Java EE container are:
I would like to have a clean external interface for step (4).
On the long run, the application will need to scale to a huge number of simultaneous clients (at least several 10.000), so a want a standard way of scalability and application management.
In general, it's not a good idea to implement all of this in a servlet container such as Tomcat.
A servlet container is designed to service requests from a client. It sounds like you have a process which will be running all the time or at least periodically. You can do this in Tomcat, but it's probably easier to do it outside. Leave Tomcat to do what it's good at, servicing requests from browsers. It's happiest when the requests are short lived.
So I would do as you suggest, and only have step 4 in the container. You can easily interrogate the database populated in step 3, so there is no need to create web services to populate the servlet container.
For step 4, you will need to expose some services from Tomcat, either through rest, soap, whatever you like. The javascript clients can then interrogate these services. This is all completely doable with Tomcat.
For scalability, there shouldn't be a problem using Tomcat. If all it's doing is pumping data from the database to the client, there probably isn't a reason to choose a J2EE container. If you don't have need of complex transaction management or security, try using something open source. It sounds like you can get what you want from Tomcat (& hibernate & spring security if necessary). If you start to have performance problems, then the fix will probably be the same for JBoss & Tomcat: you need more servers.
My advice: stick to the simple open source solutions and move to an application server only if you find it to be necessary.
I would loosely couple the solution and not try to do everything on the Java EE/Servlet container as exchanging data using sockets (managed by the application itself) is not something you typically want to do from a Java EE/Servlet container.
Running this on a Java EE container might also be overkill as this doesn't sound like a typical enterprise application where stuff like security and transaction management is important and the app could benefit from services provided by the Java EE/Servlet container.