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.
Related
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 make the web-application using Spring MVC and there is a posibility of users to send messages to each other. How can I realize such feature: when the user is on his messages page and he gets the message from someone else, this message adds to his messages list without refreshing the page. Some kind of push notifications, but I can't come up with the right idea, how to realize it.
there's two pieces to consider in this; the 'messaging' framework, and the client-side notification.
typically, the 'messaging' framework would be designed/constructed to be independant of the view layer (Spring MVC piece) and might consist of either a reliable messaging platform (JMS, AMQP, etc.) or some service that allows events to be pushed into the framework. this allows for users to be 'connected' to a JVM instance independant of each other (say a clustered Tomcat environment or some such).
a simpler - old school solution to this was to use a shared database and write/read messages to a shared table with a user identifier; something like from=userA,to=userB,message=... the you could use a polling mechanism to retrieve the messages.
on the client-side, there are a number of patterns including long polling, ajax, websockets etc. that are intended to solve this design question. to marry into the polling solution, an AJAX timed poller (coupled with event) would allow you to continually update a section of your page by requesting from a service "do i (userB) have any new messages?"
the polling solution is "old school" and there are many more options than this. have a dig on topics such as websockets that were developed with this exact challenge in mind. (and have a look at Tomcat8's websocket support too)
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/
I want to make my web application able to work offline and as soon as it becomes online or gets connected again, then it should be able to transfer the modifications made by user in offline mode.
I have seen Google Gears as an ideal solution for my problem, which is not recommended to be used as it is now deprecated.
What is a good way to make my application work offline, both in terms of technology to use and application design?
Gears is deprecated because the HTML5 standard allows for equivalent features to be present in compliant browsers.
With respect to your current problem at hand of handling offline web application access, you can look into the support offered by HTML5 for offline web applications via support for client-side SQL database access, and the client-side application HTTP cache.
The features will have to be used in conjunction, as the client-side database access will allow for storage of data (generated when the application is offline) in a structured format, while the offline application cache will allow for caching of HTTP responses from the server; you should not be caching responses that are dynamic in nature which depend on any user-provided inputs.
The details of the proposed APIs can be found in the W3C HTML5 specification, which is in draft at the moment, although it appears that certain user-agents have already implemented this feature.
Firstly, you will need some form of offline storage. HTML5's capabilities are the successor to Google Gears, as stated on the google gears developer blog; essentially, the purpose of Google Gears was just to push the development & subsequent adoption of HTML 5 features.
Specifically you should be looking at the HTML5 offline (here's a tutorial) APIs, and the Storage APIs may also come in handy (relevant tutorial).
With regards to design, you will essentially need to maintain your complete web application state client side, and then send over the differences (i.e. update the server-side state) as soon as the connection to the server is available again.
Off the top of my head, there's 2 simple ways to design this:
Explicitly maintain separate application states for the client and server. Essentially, when the user takes an action, it's applied to the client application state first, and then at specified intervals (and/or triggers, e.g. the user clicks the save button), the client sends over the differences between the last known state of the server and the current state of the client. This is probably best suited to highly interactive web applications, and I suspect Google Docs works on this kind of design. Depending on your application (if "conflicting changes" can occur), you'll need to also account for merging application state: do you override with the last received client state, or do you intelligently try to merge? (you'll have to decide which makes more sense for your particular application.)
Record user actions while offline, and replay them once the connection becomes available again. You essentially implement the Command design pattern, and have both your client-side code and server-side code able to handle each command. The client-side code always handles each command, and while the connection to the server is available, your client side code also sends off the commands to the server. You'll probably want to implement some batching, to avoid continual requests to the server, and also some roll-back functionality when requests to the server fail (e.g. conflicting changes). This ends up looking more or less like GMail's main email managment user interface, where you can undo operations.
This has not much to do with J2EE, but rather how you code your web-client. One possible solution would be to use a javascript client that does save the data in the local storage introduced with html5 (see http://diveintohtml5.ep.io/storage.html ). That is also basically the reason why google gears was stopped ...
I have an application solution which is made up of a web app written in Python (using Django framework) and a Java application which runs on the server.
The web application receives data and stores it into a database queue. The Java application is then to process the received data and also store the results in a database.
My question is how can the Java application be notified that there is new data in the database? Right now, it seems like I will have to regularly poll the database for new data. Is there any way around this?
PS. I have considered running the web app using Jython and using the Observer pattern but my host does not support Servlets.
Unless the database specifically supports it, polling is the only option I know of.
However, if your concern is load on the Java server, you could have another server that does nothing but polls for changes and then notifies your Java server when changes have occurred. I don't know if that is any better than doing a simple polling from the Java server (not knowing your specific problem space and hardware constraints).
Hope that helps.
Edit: after reading your statement again, it seems like you are already doing a messaging like framework (with the queue in the java application) so the database change could simply be another message that goes into the queue. If it needs priority, you could give the messages priority marks so that they get processed when they need to be processed.