Question

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 8.5.5.7.

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

Comments

Keep up to date on this post and subscribe to comments

March 27, 2019 - 8:32am

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)

     

         

          

March 29, 2019 - 7:02am
Response to KevinZheng_GCS

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?

November 15, 2019 - 3:10am
Response to BenjaminH

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

 

November 14, 2019 - 3:21pm

Hi KevinZheng,

1) We have JMS services and JMS listeners - would they work if we move from WebSphere 8.5.5.7 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

November 15, 2019 - 4:20am
Response to VijayM12

1) We have JMS services and JMS listeners - would they work if we move from WebSphere 8.5.5.7 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.

November 15, 2019 - 8:42am
Response to @nkur.das_GCS

Thanks Ankur.

We are using JMS MDB listeners instead. If we move from Websphere to Tomcat and if we start using JMS listeners - would there be any issues?

 

November 15, 2019 - 7:37pm
Response to VijayM12

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

https://itexpertsconsultant.wordpress.com/2016/01/25/how-to-implement-jms-with-tomcat-durable-subscription-example/

 

November 15, 2019 - 5:02am

Thanks Ankur for your quick response.