Divide java web app into smaller web app

Question

I've a web application that consists of 3 main technologies: JSF, jax-rs and websocket. All three are coupled together with the help of CDI injection and JPA.

That means that when a user login, he does so through a managed bean. Then he can use websocket (chat) and Rest service (to have notifications) and JSF for normal page navigation. When he uses websocket, his sessionBean is injected into the websocket instance.

I'd like to divide all this into the three applications that can run on their own. Is that doable ? If so how can I attack the problem ?

Answer 1

Using CDI injection and JPA together isn't coupling, it's just what they used for dependency injection, AoP, and persistence (JPA).

JSF (JavaServer Faces) is a Java specification for building component-based user interfaces for web applications.

jax-rs just lets you support REST as a service.

websocket is old school TCP in both directions.

You've identified 3 responsibilities that these last 3 take care of: navigation, notification, and chat. There is nothing inherent in any of the technologies you've mentioned that indicates any coupling, dependency, or even intercommunication.

The only reason to integrate these that I can think of is to make starting them together easy and provide an integrated GUI.

If neither of those are important then certainly you can separate them. Provided you haven't left out any surprises.

The way I attack problems like this is to start with the code organization. It might already have these separate responsibilities broken into different projects, or packages, or classes. If everything is all mushed together in an interconnected nightmare you have considerable work ahead of you.

Another factor is tests. If you're lucky, there are passing tests that prove what already works and what doesn't. You can use those to watch what breaks as you move stuff.

If the project is currently being developed (bug fixes and whatnot) it will complicate matters if you start parallel development, particularly if you don't do continuous integration or use source control. Far better to not fragment.

If current development is going on find a way to halt it if you can, switch, then start on the new version. Doing that only works well if you know how long the switch will take. For that, you can practice the switch to make a transition plan that gives you some idea how long it will take. This is only needed if bug fixes can't wait. If you're lucky, you can just start the switch and get it done before any more development needs to come in.

The moment you find yourself fixing the same bug in two places you're fragmented. Get out of that situation as soon as you can. It leads no where good.

Avoid fragmenting and keep the tests passing and you should be able to smoothly separate these responsibilities.