Liberty verses WAS - whats the pros/cons
We're upgrading JAZZ from 502\tomcat to 602\Liberty. In our env in going to 602 we're having access issues to DNG in a full CLM deployment. Some have suggested to use WAS.
Not being familiar with either WAS or Liberty , I'm wondering what, if any, benefits in going to WAS. We are not using LDAP or SSO. I know WAS is problematic in changing user passwords aside from that i don't know much else. |
3 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 17 '16, 1:40 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If you are interested in improved scalability, you will want to use Liberty, because the initial support for clustering planned for 6.0.4 will be based on Liberty. (Clustering lets you scale the number of concurrent users accessing a single RTC repository, but adding multiple nodes that handle the users of that repository).
|
The general advice section of this article can give some insights: Traditional WAS or Liberty - how to choose
Elaborate some more when you say that you're having access issues. Letting your choice for WAS or Liberty depend on that seems a bit shortsighted to me. Better spend time checking on your access issues first, e.g. what LDAP can do for you. Also, download and play with CLM 6.0.2, so you at least get a feel of Liberty. Comments On our access issue, we're migration from a 502 https single clm install onto a new vlan for 602. The move in vlan is required in order to support external user access to JAZZ and as part of this capability in order to meet corporate security requirements , we're dropping https so that the firewall can scan incoming packets. To better illustrate our new topology users https -> F5 (firewall does ssl offload -> http to nginx (proxy) -> http to jazz servers. Having set up a jazz testbed using the JKE banking sample pa in this env, both CCM and RQM get good responses, DNG however does not. If using IE 11, it times out loading a page whereas FF or Chrome do return but 30+ seconds to load a page is unacceptable. We're not using LDAP or SSO due to our environment. |