I am currently working on a point of sale application.
we have a existing system based on java which uses javapos to integrate with the devices (such as receipt printer, cash drawer , MSR etc).
now we are trying to port the java based thick client to service enable , so it is set to become a web app backed by html5 and spring webservice
my problem is to integrate the devices to the web ie browser so that the cashier can access the point of sale application from the browser .
how do i integrate the devices to the web app now. one option i have is deploying a java component in the register and make it communicate it to browser via websocket.
browser<-> websocket <-> java device component in local system
Is there any better way to do this? i need the technology which enable me to do the same.
i have considered the applet as well but the problem is the local java component is kinda huge and it will have different device drivers for each system.
JavaFX offers a pretty decent web browser component, that allows easy communication between the Javascript code that runs in the page and the Java code outside. You could port your application so that:
It uses JavaFX, openning a window with just a browser component and pointing it to your web application
Implement the web app as normal - it will display in the browser component
Move the device-specific Java code in the JavaFX app, expose its methods to the browser; now the Javascript code will call Java and (hopefully) you will be able to reuse most of your existing code, excluding UI code of course
A "Hybrid" JavaFX/HTML application example is iBreed (it is a framework that you can use actually).
I think you can make it work, but you will need one more piece of software.
Webserver (hosting the HTML-files and API)
Client PC (runnning the HTML-frontend in a browser) woth conected devices
new service running on the client PC, with a Web-API for the connected devices
I think, this is exactly the same approach as you mentioned with websockets. (Ony for older browser).
Take a look at atmosphere. This may help you to get the websocket stuff done:
https://github.com/Atmosphere/atmosphere
Related
I have an application implemented in JavaFX and it will be migrated to the web platform, but it will take some time for that.
Meanwhile, I am struggling with some problems regarding its uses. Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database.
My doubt is whether running the jar from the allowed network drive will solve this problem. In addition, can JNLP be a solution for this ?
I'd appreciate any help about this.
Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database. My doubt is whether running the jar from the allowed network drive will solve this problem.
It won't work directly.
JavaFX is a client technology, it runs on a client PC. If the client PC does not have direct access to a database, then neither does a JavaFX application running on that client PC.
In addition, can JNLP be a solution for this ?
No, not for direct access to the database from the client if this isn't permitted in your network architecture, you would need a middle tier in addition to the JNLP based client to accomplish this.
Discussion of some solutions to this problem
Typically, the architecture of what you are describing would be built as a multi-tier app.
A client tier, which is the the JavaFX application or HTML javascript application running on a client machine.
An application server tier which handles server logic.
A database tier which hosts the DBMS.
There is a reasonable high level overview of such an architecture here.
Often, nowadays, the application server will serve REST APIs of JSON data, which a HTML based JavaScript web application can easily consume. Such APIs are also easily consumed using JavaFX applications which embed a REST client. An application server services the REST APIs and communicates with a database over JPA or JDBC as appropriate. However, than are many alternate technologies for client/server communication, and you can choose whatever you feel is a good fit for your application, development style and organization.
Spring product specific discussion
As you state your preference to use Spring, consider a JavaFX SpringBoot application.
Spring also includes a technology called spring remoting for facilitating client/server access. Spring remoting provides for multiple communication technologies. I'd advise sticking to the straight HTTP REST based technologies rather than other techniques such as RMI or AMQP as a HTTP REST based back-end can also serve as the backend for a standard HTML/JavaScript webapp which you also mention may be an eventual target client for your application.
If using Spring on client and server, checkout Spring's AsyncRestTemplate, and invoke JavaFX's Platform.runLater API inside the success and failure callbacks of the rest template. Or, use a Spring RestTemplate and control calls to the server via JavaFX concurrency mechanisms. Not sure which would be best for you, possibly the standard RestTemplate wrapped in a JavaFX Task.
Doing this in the correct manner will allow your application UI to remain responsive while it performs network activity (not block the UI thread) and also ensure that you don't violate JavaFX thread rules (don't access controls or modify data bound to JavaFX scene controls off of the JavaFX application thread).
After several months of searching & reading, now i need your help, taking in consideration the following:
- My Application Developed using Java Swing.
- MySQL has been used as database.
- JDBC has been used to make the communication between the application & database.
- The application will run on network environment with multiple client will connect to database.
- The application use Financial transactions, Posting, Billing ... etc.
** now i want to develop a server side that will work as middle-ware, this server side will do the following:
- Connecting to the database to retrieve data as client request.
- Business logic will be on the server side.
- Client will not know about the database.
- Queries Syntax will be on the server side.
- The Client will View,Save,Edit, Cancel ... etc, sending these actions to the server side & server will response.
--- I have read about JFC, J2EE, EJB ... etc, but i don't want to run my application from browser, it will be kept as desktop application only due to the complexity of the application.
--- So i will do it using Sockets.
Any ideas, or tutorials that i can follow?
I suggest using a web-based approach to writing the back-end (e.g. a web service, either SOAP or Rest), and then communicating between the swing app and the back-end app via HTTP / HTTPS.
This is how mobile apps are typically written, and your swing desktop app is no different from a mobile app in this respect.
As far as frameworks for the back end, both Spring MVC and Grails make this pretty easy. Do yourself a huge favor and stay away from EJB unless you really need.it and understand why.
When you have 1-2 hours left, it might be worth to look at the Scout framework.
Scout seems to be a pretty good fit to your application context. Scout applications consist of a Scout server that handles access to web services (currently including support for JAX-WS) and database access over JDBC. The Scout client communicates via HTTP(S) with the Scout server and is available in the form of desktop clients (either supporting Swing or SWT) and as web application (currently based on Eclipse RAP). The web client also supports different renderings to optimize the application to desktop browser or mobile devices with touch support.
I have to set up a desktop Java client that will communicate with a .NET desktop application. The .NET application exposes its services through a webserver of its own. Rather than have my Java app frequently poll it for data changes, it was suggested that the .NET app contact my Java desktop app via a webservice or similar technique. I am not familiar with web services, but as I understand you would need some sort of web app container such as Tomcat to host it.
Is there a way to set up a listening socket in my app as a webservice end point without effectively rewriting a webserver from scratch?
Alternately, are there other or better ways for a .NET desktop application to talk to a Java Swing desktop application?
If you are using JRE 6 then you can use the Endpoint.publish() method to create an in-app server and expose a service.
Refer the simple tutorial in the link to see an example of the same.
How the Endpoint.publish() works is it internally creates a light weight server and makes the SOAP service available on that location.
We are trying to play audio on the client machine. It is a web application based on Java EE, wherein due to some event happening at server side, the client should ring a bell or something of that sort.
I am not aware of any such thing. Alternative is to use
Html5
, but then it's become browser dependent that the browser should be Html5 compatible. I cannot enforce this requirement onto the client.
I went through
Red5
but found it not very useful..
Please advise
There are two parts to the problem:
playing sound in a browser
the browser being notified of events on the server
For playing sounds, and to support a wide range of browsers, you have a number of options. HTML5 <audio> tag and Plugins (Flash, Java applet). You could also use a Javascript library such as Yahoo Media Player to make this easier. A starter is here.
The second problem is how to notify clients when an event on the server occurs. This could be done with AJAX calls polling the server. Since you are using Java EE, this could be made a bit more efficient using Asynchronous Servlets. You could also go down the WebSocket path with this as well, though there can be issues through proxy servers with this.
I'm interested in having a desktop application send messages to a web app. Specifically, the desktop app, written in Java, needs to send messages to a Javascript function that will be running in a browser. The messages only need to be sent one way. Also, both programs will be running on the same local machine. I can set up a local development server if necessary.
I'm new to networking and web development and I have no idea how to approach this problem. Can anyone offer any suggestions?
I think the appropriate way to do that (if not the only way) would be to go through a server both apps talks to
The enterprise architecture way I recommend you do is:
Put the common information into a webservice.
The website sends information, possibly via ajax or by navigating to a different URL or doing a form POST to the webservice.
The desktop app will start up and will subscribe to the webservice. The webservice will notify the desktop app once it has an update. (note that the desktop app, might need to poll for updates).
That approach is how services such as flikr, twitter etc use.
The light weight (ie smaller architecture) way of hacking this is to make your website have an RSS feed that your desktop app subscribes to. The desktop app gets updated via the RSS feed.
That approach is how services such as news websites will send updates to readers. See google reader as an example RSS client. RSS has an adavantage of supporting generic rss consumers like MS outlook or google reader from the start, where as webservices are likely to be more flexible and cleaner in the long run.
why does the desktop app need to talk to javascript? What is it you are actually trying to do? Send or receive data to or from a database? Run some business logic on the web app? These things are typically done from a desktop app to a website using soap or rest.
is the browser embedded somehow in the desktop app? Or could is it just running as a separate process? It seems like audio processing should really run in the desktop app.
However, assuming that the browser is running as a separate app, you should be able to send messages to the browser through the query string. The desktop app could fire up the browser, point it to a url and pass some parameters to it. THen javascript can process those parameters. Google whether jquery can process query string parameters.
Embed a simple container like jetty then use Jersey or a Simple Servlet