1

I'd like to create a decoupled frontend (vaadin) and backend (spring). Both should run on the same tomcat application server, but each is a single war so I can redeploy the frontend without having to restart the backend.

I want to minimize the remoting code between both applications to exchange data. Therefore I thought I could maybe inject the service beans from backend into the frontend war. But it that possible? How would I share the service declaration between both war files / java projects?

And what type of remoting would be apropriate here? Ideally I could imagine to have a mechanism where I could just "use" the backend service classes also in frontend, and spring clues the proxies together. But how?

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
membersound
  • 81,582
  • 193
  • 585
  • 1,120

4 Answers4

1

You want to decouple the backend and the frontend, nice till there. You want to put them in separate wars on same tomcat, still possible but it has implications.

But now you want to inject beans from backend into frontend. If they are in separate wars it is no longer possible. Even on same same tomcat, each war if fully independant of the other and they should only communicate through the network (normally through web services).

You have two decoupling levels available :

  • one single war for both. The frontend would here consist on the view and controller layers, the backend of service and persistence layer. The coupling is provided by the service interfaces that you inject in your controllers. This is a single web application
  • each in its own war as 2 separate web applications. The frontend will have same view and controller layers than in previous case, and a thin service layer that would send REST requests to the backend. And the backend will have same service and persistence layer that in previous case, no view layer and REST controllers to process requests from the frontend.

For low to medium load, first solution will use a little less ressources, but under really huge load, the second one would be more scalable with farms of servers for frontend and backend (not speaking of reverse proxies before frontend and database servers behind backend)

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
0

If I understood your question correct, you want to separate your front end code from your back end.

What you could do, is create a .jar file of your back end implementation and in your front end instantiate the beans from an XML or Java application context.

If you don't want to redeploy your app for each change in the configuration I would prefer to use XML configuration.

In your front end code you have to include your back end jar and you can call these services in the regular Spring way.

Adriaan Koster
  • 15,870
  • 5
  • 45
  • 60
questionaire
  • 2,475
  • 2
  • 14
  • 28
0

yes you can load an external spring-context.xml from a jar / war in order to get the beans, check this answer here

Community
  • 1
  • 1
AntJavaDev
  • 1,204
  • 1
  • 18
  • 24
0

You can bind your spring beans to JNDI and receive this objects in your frontend.
http://docs.spring.io/autorepo/docs/spring/3.2.3.RELEASE/javadoc-api/org/springframework/jndi/JndiTemplate.html#bind%28java.lang.String,%20java.lang.Object%29

But in this solution the decoupling of both wars is not really succeeded. I didn't see any benefit to separate frontend and backend in two war files when this must be deployed in the same container.

I would prefer to deploy one war file or communicate with REST between frontend and backend.

Matthias
  • 1,378
  • 10
  • 23