Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Dividing a war file, architecture

 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I've made my first big web application that is mainly using JSF as technology but there is also some services on the side.
JSF is used to serve the page content, while websocket together with a rest service are used mainly for chatting with friends.
Everything is packed into a single WAR file that is quite big and messy. I'd like to divide that war file into independent app that can run on their own without having the others running.
Since I don't know much about application architecture I'd like some help trying to figure out what I have to do to reach my goals. Here is a little diagram I made representing how the app works.


Link: https://s32.postimg.org/7w84dbrcl/arch.png

As you can see in brown there is a CDI injection of the SessionBean. That is used so only valid and logged in users can access those service. For instance the Jax-rs service gives to the user his online friends :



Also they all use the same JPA package.


How can I divide this so I can have apps that can run independently (when others are not deployed in the web server ) ? Is it what EAR are used for ? If so do I have to create 3 war that are into one EAR ? I'm totally lost...


Thanks
 
Tim Holloway
Bartender
Posts: 18416
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
EARs don't work in Tomcat (or jeTTY), only in full-stack JEE servers.

There are several possibilities here. One, simplifying things from a maintenance standpoint would be to take the 3 parts of your app and build each of them into discrete JARs that go in the master WEB-INF/lib along with your JPA class jar(s), assorted other support libraries, and so forth.

You could isolate things further by making each of the 3 subsystems be an independent webapp. However, if you do that, you have to get creative. By default, each webapp has its own unique set of user sessions. So you'd either have to configure Tomcat for shared sessions or make the login session be a JPA object. And, incidentally, set up JPA so that cache is shared between the 3 webapps. By the way, once you reach that stage, EJBs start to look better than straight JPA, since EJBs were designed from the beginning to be shareable between webapps. But straight Tomcat doesn't support EJBs, so you might have to step up to a full-stack server.

Alternatively, you might not actually need shared J2EE sessions if the only thing in common was just letting each app know that the user had logged into the system. A Single Signon (SSO) security Realm shared between the apps would be enough for that.

If you design the 3 apps to operate as full-blown microservices, you can even deploy them on separate server machines and get all elastic-y and cloud-y!
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As always, thank you for your valuable input.

Tim Holloway wrote:EARs don't work in Tomcat (or jeTTY), only in full-stack JEE servers.




I'm definitely not using Tomcat. Maybe you thought I did because of my last post ? I'm just in the process of trying out multiple web server to find what suits me the bests. However I read a comparison where Tomcat was performing the worst, so it gave me a bad taste in the mouth.
I'm mostly hesitating between the undertow embedded API or a Full wildfly (quite the 2 extrems of the spectrum lol).


Tim Holloway wrote:
Alternatively, you might not actually need shared J2EE sessions if the only thing in common was just letting each app know that the user had logged into the system. A Single Signon (SSO) security Realm shared between the apps would be enough for that.

If you design the 3 apps to operate as full-blown microservices, you can even deploy them on separate server machines and get all elastic-y and cloud-y!


That is exactly what I was thinking about. If some of those services require more horse power I can scale them horizontally more easily this way!


Tim Holloway wrote:
There are several possibilities here. One, simplifying things from a maintenance standpoint would be to take the 3 parts of your app and build each of them into discrete JARs that go in the master WEB-INF/lib along with your JPA class jar(s), assorted other support libraries, and so forth.

I'm not a fan of that. It seems to me that doing so would make the development process a pain in the ass. Each time I make a change in one of the service, I'd have to convert it to a JAR and get it back into my WEB-INF/lib folder. Doesn't sound practical.


Tim Holloway wrote:
You could isolate things further by making each of the 3 subsystems be an independent webapp. However, if you do that, you have to get creative. By default, each webapp has its own unique set of user sessions. So you'd either have to configure Tomcat for shared sessions or make the login session be a JPA object. And, incidentally, set up JPA so that cache is shared between the 3 webapps. By the way, once you reach that stage, EJBs start to look better than straight JPA, since EJBs were designed from the beginning to be shareable between webapps. But straight Tomcat doesn't support EJBs, so you might have to step up to a full-stack server.

I'm not fully understanding this, so... I'll pass :p.


So about the single signon: I made a quick research and found out that it uses the LDAP that I kept reading here and there but know nothing about. I also read about 0Auth2 (and some security issues on wikipedia). However it's getting late, so I'm gonna do my research tomorrow. Could you be so kind and tell me a few buzzwords I can look up tomorrow to go in the right direction from the get go (the technology you would use I mean) ?

Thanks Tim !
 
Tim Holloway
Bartender
Posts: 18416
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also moderate the Tomcat forum and answer a lot of Tomcat questions, so I tend to assume unless told otherwise. Tomcat is actually quite performant, but that's partly because it doesn't have the overhead of having to support a full stack.

If you are using something like Maven and/or Jenkins to manage your projects, there's nothing outlandish about having buildable sub-projects that trigger uphill main project builds. It's actually quite common for the complex systems that I get my kicks from. In fact, it's pretty much essential to build an EAR that way.

For Wildfly, you could definitely build an EAR, containing 3 WARs and an EJB (JPA) jar if you wanted to. Or make each of the 4 components separately deployable if you want to go the micro-service route.

SSO does NOT require LDAP. LDAP is merely a repository for credentials, just as a database would be. What SSO is is a mechanism where when you login once, you are considered to automatically be logged in to all other apps participating in that SSO domain, regardless of how the credentials were stored. And thereafter, any HttpServletRequest sent to any webapp in that domain would have its pemoteUser property populated automatically.

OAuth is really nasty and it's not a single-signon mechanism so much as it is a way for you to sign on to one app and have that app vouch for your identity via behind-the-scenes channnels to other webapps. It can get very awkward when one of the authorized apps isn't a publicly visible webapp - as for example, if it's an Android app or local desktop app. OAuth2 tries to make up for some of those deficiencies, but it's a bit much for most purposes, and in cases where all the apps are under your control and on your servers, I couldn't recommend it.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.

The past few days I learned about JNDI, RMI, (LDAP very, very roughly, I don't intend to use it since I felt it was a bit complicated), POM multimodule packaging under maven and I implemented SSO via keycloak (awesome, the doc not so much). Quite a lot huh ? I'm beggining to do a massive refactoring of the app, thanks to EJB's but I'm still learning. I was using EJB annotations before but to me it was just about injection lol. Now I see how powerful it can be, especially for remote accesses. During those past few days I felt a bit overwhelmed at this whole new set of information I didn't know; I even briefly thought I should give it all up and go sell sandwiches on the beach instead since I've been programming for over a year and I still didn't know all that. Don't get me wrong, I feel like I learned a ton during that time span and I know the lifecycle of learning: think you are good, realize you know barely anything, learn, repeat.
Having said that, I think I'm beginning to understand architecture a bit, and my goal is to divide my app in a lot of individual mini-apps that can be addressed independently without breaking the whole thing. It's a whole new world for me :). Especially EJB and remote calls. Still a bit confused on the implementation but the core idea is here and I see the light at the end of the tunnel :p.


However, I'm a bit skeptical of the fact that I based my whole app around JSF. Now in retrospect I feel that it might have been a mistake and a restful app could have been better suited (I had no idea what that was when I started). Do you think JSF is a thing of the past ? Since I intend to divide my app in a lot of micro services I think restful is more suited for that. A reason for it is that I'd like to open source some of those mini app, to users who want to contribute and more people know .js than JSF. Idk, I guess I'll have to go more in depth with rest to see what I'll lose with it.

My guess: 
  - JSF templating is quite useful
  - I think pretty much anything that is done in a managed bean, and even around it with conversion and validation, can be implemented with rest. The nice thing with JSF is that everything is automatically done, the input values directly go into bean fields. But I suppose that there is also a mechanism to do that with jax-rs.
  - The biggest loss I think is the viewscope that I'm an heavy user of.
 
Tim Holloway
Bartender
Posts: 18416
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF is very well suited for functions where the user is doing a lot of work with forms, especially when the number of concurrent users will be fairly small. ReST is more appropriate where you have intelligence in the client - for example, automated remote batch processes. I have apps that use both.

One of the things that makes one a Master Architect is in knowing what tools are appropriate for the task at hand - and there's rarely a single "right" solution, just better and worse ones. When EJBs first came out, people tried to use them for inappropriate purposes and the result was that EJBs got a bad reputation. EJBs are much improved these days, but even the older, more limited forms had their utility.

LDAP can be confusing. Think of it as one of the original "NoSQL" DBMS's. I use it not only as the central security database for most of my web applications, but also to store the name and address information for my holiday card list - I have a desktop app (originally written in Perl, but now in Python) that generates the mailing labels. Others like to use it to hold hostname information for DNS, hardware inventory information, and in some cases, system configuration information.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!