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....