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
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 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 am going to make a small trade management system. I want to make a independent database service to which all the other client connect. The database will be MYSQL and I will be using Java for making the service. The client can either be a Web Application or a desktop application using Java Swing (has not decided yet). There will be another layer sit between the client and the database service to handle the business logic (I call it trade service).
The architecture is something like: Client -> Trade Service -> Database Service.
My questions is that what client/service communication technology is the best suitable one for client->Trade Service and the best suitable one for Trade service -> Database.
Shall I make it s RESTful service? SOAP? Using RPC? Or any other technologies?
Many thanks for your help. Any idea or suggestions are welcome.
Take a look at RabbitMQ, A pool messaging service
http://www.rabbitmq.com/
It's Robust, flexible, fast and scalable and you can use it to communicate in Java, PHP, or whatever technologies ou want.
Shall I make it s RESTful service? SOAP? Using RPC?
These are all very similar approaches in that they are over HTTP so - assuming that's what you want; I would recommend using RESTful. You'll have lot's of examples to work with and it will allow you flexibility in the future to do things like switching out the UI layer for a smart phone app or desktop app.
Regardless of what model you pick you should understand how it works first and build in things like security and guidelines early. Do your homework now. Trying to change the middle layer of a design like this is a pain.
There is no blanket answer to your question, there are instead options based on your skill set. Do you conceptually understand the HTTP spec completely and be able to extend it to REST, that works very closely with HTTP (common creation ancestor). Do you better understand the traditional method invocation of SOAP? Are you tied in your ecosystem to a specific language, as this can impact which tools you choose from.
If you were paying me to write a service based on the simple requirements you have given (which is nearly impossible), I would create a domain driven design service (your business layer) with a RESTful interface and Spring JDBC for data access. That is me, and what I work in most often. My partner in crime at work would probably choose SOAP and Hibernate.
I think what you're taking about is Queues, and I'm guessing you need a managed service for that. Queues can be the glue between your micro-services. Some of the vendors I know which have Queue as a Service are :
CloudBoost.io : https://www.cloudboost.io
Check out https://tutorials.cloudboost.io/en/queues/basicqueues for documentation.
Iron.io : https://www.iron.io
P.S : I work at CloudBoost
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 am about to build a system that will have its own engine, as well as a front end user interface. I would like to decouple these two as much as possible. The engine should be able to accept commands and data, be able to work on this data, and return some result. The jobs for the engine may be long, and the client should have the ability to query the engine at any time for its current status.
A decouple front-end / back-end system is new territory for me and I'm unsure of the best architecture. I want the front end to be web-based. It will send commands to the engine through forms, and will display engine output and current status, all through ajax calls. I will mot likely use a Spring-based web app inside Tomcat.
My question involves the best structure for engine component. These are the possibilities I'm considering:
Implement the engine as a set of threads and data structures within the web app. The advantages here would be a more simple implementation, and messaging between the web app front end and engine would be simple (nothing more than some shared data structures). Disadvantages would be a tight coupling between the front and back ends, reliance on the server container to manage the engine (e.g if the web server or web app crashed, so would the engine).
Implement the back end as a stand alone Java application, and expose its functionality through some service on a TCP port. I like this approach because it's decoupled from the web server. However, I'm not stoked about the amount of low-level networking / communication code required. I would prefer some higher level of message passing that abstracts Sockets etc.
Use an OSGi container like Spring DM server to host both the web app and engine. This approach is nice because the networking code is nonexistent. The engine exposes services to the OSGI container for the web app to consume. The downside here is the learning curve and overhead of a new technology: OSGi. Also, the front and back end remain coupled again which I dont really want. In other words, I couldn't deploy the front end on any old servlet container, it would have to be in the same OSGi container as the engine.
I have a feeling RMI is the way to go here, but again that's a new area of technology for me, and it still doesn't explain how to design the architecture of the underlying systems. What about JMS?
Thank you for any advice.
If you really want to decouple web app and engine,you can also deploy the engine in a different server and expose the API as web service calls (WS-* or REST).
If it's going to be a Web app, there's no need to decouple the processes like there would be if you had a desktop app front end and a server back end. So keep it simple.
The basis I would use (and am using for a project I'm working on currently as it turns out) is this kind of stack:
Spring 3
Web container
Application deployed as a Web application (WAR);
For persistence, either Ibatis (my preferred option) or JPA/Hibernate (if you prefer a more object persistence approach);
Your preferred choice of Web framework. There's no easy answer here and there are dozens to choose from, from the straight templating to the more componentized (JSF, Seam, etc). Tapestry/Wicket look interesting but I'm no expert in either.
A Spring container is entirely capable of launching a series of threads and it's quite common to do so. So what you'll need is a series of components that will simply be your engine. Unless you have a good reason to do otherwise, Spring beans within a Web application context is simple, flexible and powerful.
On the front end it depends on what you want. Straight HTML can be done with any Web framework. Even if decorated by some Javascript. I use jQuery for that kind of thing.
It only gets a little different if you want the front end to look like a desktop app (a so-called "rich" UI). For this you either need to use the Google Web Toolkit ("GWT"), possibly a component Web framework like JSF (although I tend to think these get real messy real fast) or a Javascript framework like ExtJS, SmartClient, YUI or the fairly new Uki.
You'll decouple your UI if you write your back end as services, and establish an XML or JSON message format to pass between client and services.
All the rest of cletus's comments can hold true for the back end, but the client can be blissfully unaware of it. It can even be a .NET implementation for all it cares. The focus is on the use cases and the messages, not the back end implementation.
This can also be useful in those instances when you use a non-HTML based UI (e.g., Flex).