0

I have a Client Server Application which is Java based with Spring for the server.

Now I have to replace the Java client with a web client.

I have three different achitectur concepts for implementing the webserver and linking it to the appliation server. But I'm not sure which I should use. I'm not really firm with web applications, but I think this is not a pure decision by the web client. Can someone please give me some pros and cons for the different concepts or please tell me if my concepts have mistakes.

These are the concepts:

  1. Useage of an embedded web server in my application server. Pro: I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests. Cons: The customer must decide if an application server is allowed to start their own web server. And I'm not sure if it is a good style to mix the web ui logic with the business logic of the application server

  2. Embedd the business logic with the web ui in a war for a stand alone web server. Pro: Basic Security stuf like https handling will be done by the web server. Maybe more accepteable for the customer regarding the deployment. I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests. Cons: The application server has a lot of memory and cpu useage. The is maybe a problem for the web server.

  3. Embedd the web ui in a web server and link it to the application server via socket connection. Pro: strict separation between ui and business logic. The application server must not be changed, because the socket connection between web server and application server can use the existing socket connection for the fat client. Cons: The handling of user sessions must be handled two time. First the web session and second the session to the application server. Furthermore the web server must set up his own storeages for data and must keep them in sync with the storeages in the application server.

My first thougt was to take the first concept because I have every thing in one application. But my second thougt to use the third concept because of the strict separation and the benefits of a real web server. But here my problem is the handling of two sessions for each user. Or are there better concepts?

Thank you for giving me input!

Jürgen
  • 146
  • 12

1 Answers1

0

Your 3rd approach is better. Keeping application server separate will better serve different clients like Java clients, web clients etc. It will separate 2 different concerns. If there is a UI related issue , then you can bring down the UI server and fix it. But your other Java clients will work fine. Moreover it will be better from development perspective as well.

Rahul Vedpathak
  • 1,346
  • 3
  • 16
  • 30
  • Thank you for your answer. But how I should handle the user sessions? Must I handle a session for each user between the web server and the application server? If yes, must have every web session a sperate socket session to the application server? If not, what are better concepts for the authentication and controll of the access to different functions? – Jürgen May 10 '18 at 16:54
  • Keep user session at the web application only and design your backend application in stateless way. If you want to maintain stateful sessions on backend as well then you can expose your services via EJB for example. – Rahul Vedpathak May 10 '18 at 17:08