Moving from Websphere 8.5.5.7 to Tomcat
Hey all,
Components in our current Pega Infastructure are reaching end of support (our version of RHEL) and as such as we're reviewing the stack to understand the options available to us.
It seems that we've come down to two options:
- Pega 7.3.1 and Websphere 9 (RHEL 7)
- Pega 7.1.9 and Tomcat 8.0 (RHEL 7)
Either one of these choices introduces additional complexity to the upgrade in one form or another.
We're currently on Websphere Proprietary information hidden.
We have enough information to explain a Pega upgrade to the client at a high level, but my first question is around moving to Tomcat 8.
What changes would we likely need to make to the Pega application as part of the move from a more complex application server (Websphere) to a more lightweight web server (Tomcat)? Key points we've noted are:
Hey all,
Components in our current Pega Infastructure are reaching end of support (our version of RHEL) and as such as we're reviewing the stack to understand the options available to us.
It seems that we've come down to two options:
- Pega 7.3.1 and Websphere 9 (RHEL 7)
- Pega 7.1.9 and Tomcat 8.0 (RHEL 7)
Either one of these choices introduces additional complexity to the upgrade in one form or another.
We're currently on Websphere Proprietary information hidden.
We have enough information to explain a Pega upgrade to the client at a high level, but my first question is around moving to Tomcat 8.
What changes would we likely need to make to the Pega application as part of the move from a more complex application server (Websphere) to a more lightweight web server (Tomcat)? Key points we've noted are:
- We use JMS MDB Listeners for Message Queue monitoring
- In addition to the PEGA_DATA and PEGA_RULES schema, we have an addition PEGA_WORK schema which is often updated within the same transaction as the PEGA_DATA schema. As far as I understand this required distributed transactions which are currently managed by WebSphere?
Question #2 - In a complex banking environment is there a preferred choice between Websphere and Tomcat, based on the above information (or does it not generally matter)?
Question #3 - Again based on all the above information, would the Pega 7.3.1 / Websphere 9 combo be advisable, or the Pega 7.1.9 / Tomcat 8 with a future Pega upgrade?
With thanks,
Ben
Pegasystems Inc.
US
Ben,
Let me list some of the pros and cons of the two stacks - you make the call (this is a not just a technical decision)
WAS:
Pros: full JEE stack, support MDB, app server level transaction management, etc. (IBM has a
more light-weight solution liberty which starts with war deployment and can be customized to
support full ear deployment).
Cons: expensive license, normally need trained WAS admin to manage the environments.
Tomcat
Pros: Free, vibrant and ever growing community, production proven
(in fact almost all current Pegacloud envs run on
Tomcat, including some financial institutions). Much easier to manage (no WAS admin role),
rarely do you need a "Tomcat admin".
Cons: Normally only support war deployment, so no MDB (alternative is JMS listener)
SiXworks Limited
GB
Hey, thank you for the useful feedback.
Do you know whether the below point would be a concern?
- In addition to the PEGA_DATA and PEGA_RULES schema, we have an addition PEGA_WORK schema which is often updated within the same transaction as the PEGA_DATA schema. As far as I understand this required distributed transactions which are currently managed by WebSphere?
Pegasystems Inc.
US
The Apache Tomcat JDBC Pool documentation does claim support for XA connection support (distibuted connections) providing implementation via javax.sql.XADataSource. Refer to Apache tomcat documentation - https://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html
UBS
GB
Hi KevinZheng,
1) We have JMS services and JMS listeners - would they work if we move from WebSphere Proprietary information hidden to Tomcat 9.x. We have JMS listeners by the way
2) We also multiple schemas like data and work schemas. Would it work with Tomcat 9.x as we commit to both databases in a single transaction (for example: Worklist/Workbasket data into data schema, and case data into work schema).
Thanks,
Vijay
Pegasystems Inc.
US
1) We have JMS services and JMS listeners - would they work if we move from WebSphere Proprietary information hidden to Tomcat 9.x. We have JMS listeners by the way
JMS Listeners and JMS Services will work just fine in Tomcat WAR deployment.
When your system is deployed as a Web application, the listener runs as a Java thread, created when the system starts. The listener waits for incoming messages on the JMS destination (queue or topic). At regular intervals (as specified on the listener form), the listener checks to see the system issued a request for it to stop running. If your system is deployed as a Web application, configure JMS listeners with this JMS Listener form.
Pegasystems Inc.
US
You will need to weave in a JMS messaging engine into Tomcat and use JMS Listeners instead of JMS MDB Listeners that you have with the Websphere setup.
See following articles which have steps to embed ActiveMQ with Tomcat.
http://fabien.carrion.free.fr/tomcat/jndi-jms-examples-howto.xml