• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

JavaFX Design Question: (front-end) and (backend)

 
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

I have a design question.

Let's say that my desktop application needs to do a lot of backend operations: reading and writing towards DB or web services, sending emails, execute scheduled operations, etc.

Most of these operations shall be controlled through the JaxaFX GUI.

Now the design questions: how do you recommend to wire the front-end with the backend?

1) split the desktop application in two separate components: backend (local) server, and JavaFX front-end and have the two communicate through (local) HTTP calls (integrating for example an HTTP client in the JavaFX GUI)
2) use only JavaFX for both the GUI and its Task/Service concurrent classes to trigger the (spring) services that implement the "backend operations"

Coming from years of Web Development, I tend to think as 1) :-) Especially because I think that if one day I have to write a Web GUI for the same functionalities, I would have a huge chunk of the work already done...

I hope the situation is clear and that it triggers your curiosity :-)

Any thought is very much appreciated!

I look forward to hearing from you.

Cheers,
Giovanni
 
Rancher
Posts: 387
30
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Either way will work.

I'd choose:

1) split the desktop application in two separate components: backend (local) server, and JavaFX front-end and have the two communicate through (local) HTTP calls (integrating for example an HTTP client in the JavaFX GUI)

It is going to be more work to building separate client/server apps than a monolithic JavaFX client app, but you will end with a more flexible architecture.

For performing the communication there a couple of examples on the web.
http://www.zenjava.com/series/building-jee-applications-in-javafx-2-0/ series (all articles) outlines various options.
If you have wide experience with Spring and would like to use it, then maybe this article on JavaFX + Spring Remoting may help:
http://www.zenjava.com/2012/02/25/going-remote-javafx-and-spring-remoting/
This JavaFX + Hessian integration is incredibly elegant, but probably wouldn't be appropriate if you seriously think you might need to communicate to your backend service directly from a web browser one day:
http://www.zenjava.com/2011/11/03/client-server-with-javafx-2-and-hessian-guice-fxml/
Oracle published an article on JavaFX + WebSockets:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/BinaryWebSocket/binaryWebSocket.html
I also created a small trial application for JavaFX + WebSockets:
https://github.com/jewelsea/javafx-websocket-test
Akka is a very promising communication mechanism (IMO) and I think there are also browser based akka clients, so that is also an option:
http://akka.io
I think if you were developing based on Scala/ScalaFX then akka would probably be a good choice there (though it should work quite well with regular Java code in Java 8 as well). The only real issue with it is that I haven't yet seen anybody integrate akka+JavaFX and it is not as widely used a mechanism as HTTP Rest based clients, so you might not get as much support.

Use an automated translation system for the client/server messages/protocol buffers (e.g. Jackson Java->Json/Gson mapping, likely triggered automatically by your Rest/Akka/Spring Remote communication libraries).

Probably the simplest thing is to reuse a bunch of the technologies you are familiar with rather than throw in a kitchen sink of new stuff.

So if you are already familiar with Spring, but not with JavaFX, then develop your backend in Spring - there will be plenty of interesting new things and techniques to learn for your JavaFX client, so you won't get bored.

Use Spring Remoting or a Rest library (e.g. Restlet/RestEasy/Jersey or whatever the Spring implementation for the Java Rest JSR is) for your communication (I wouldn't use basic Apache HTTP Client Components - there are better, higher level options).

For the JavaFX client application portion, you could make it dependent on the full Spring library, but I would tend to make it more lightweight than that. I'd use CSS/FXML to separate style/view/controller logic together with the afterburner.fx framework (http://afterburner.adam-bien.com) to get lightweight dependency injection (similar to what you are probably already used to with Spring). For the build system, make use of the JavaFX maven plugin: http://zenjava.com/javafx/maven/ (or the gradle plugin if you prefer gradle: https://bitbucket.org/shemnon/javafx-gradle).

Also take a good look at javafxdata.org, whose tagline is "The best way to get real-world data into your JavaFX application"
http://www.javafxdata.org

Have fun....
 
Giovanni De Stefano
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello John,

Thank you so much for your detailed reply!

I will certainly investigate all the options you proposed :-) I have a long weekend ahead of me :-)

Cheers,
Giovanni
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic