EAR vs WAR
Hello,
I stumbled on this topic but I miss the basic idea. To my knowledge, unless I write custom Java activities, Pega writes all the code from my application configuration. Hence as Pega developer I don't really mind about the generated code or technology behind the scene.
If this is correct, why should I care about choosing EAR vs WAR deployment? Is there any Pega feature or functionality that only works if I decide to deploy EAR file?
I saw other posts on this subject (https://collaborate.pega.com/question/advantages-deploying-pega-war-vs-ear) where things like EJB and 2FC are mentioned, but again, unless I write a Java activity that specifically uses EJB (as an example) how this should be relevant to me as Pega developer (configuration, no code)?
Furthermore, does this apply to PegaCloud as well? Do I have the choice to decide EAR/WAR deployment?
Cheers.
Updated: 7 Feb 2020 13:41 EST
Pegasystems Inc.
US
The idea of choosing between EAR & WAR file depends on the features & integrations you are going to develop & use with Pega.
Implementing features like below not just depend on the custom code we write in java steps, but also depends on the application's capability to leverage app server components to be able to run. To facilitate this, the EAR file is packaged with additional config files that are relevant to J2EE compliant servers like Websphere, JBoss or Weblogic.
Use the EAR file only if you need one of the following EAR-only features. Else, consider WAR file deployment as a best practice irrespective of any app server.
- Java Messaging Service (JMS): Pega connectors and services
- Java Transaction API (JTA): Two-phased commits to the database
- Enterprise Java Beans (EJB): Pega connectors and services
- Java Connector Architecture (Connect JCA)
Latest PegaCloud offerings default to WAR based deployments.
Pegasystems Inc.
NZ
Hi,
Thanks for your reply, it helps but there's still something not very clear.
When you say:
"Implementing features like below not just depend on the custom code we write in java steps, but also depends on the application's capability to leverage app server components to be able to run. To facilitate this, the EAR file is packaged with additional config files that are relevant to J2EE compliant servers like Websphere, JBoss or Weblogic"
I don't understand if there's any specific PEGA feature that won't work if I chose to use WAR based deployment, or if additional capabilities provided by a full J2EE application server (EAR deployment) are exploited only in custom java code in activities.
Cheers.
Pegasystems Inc.
US
I don't understand if there's any specific PEGA feature that won't work if I chose to use WAR based deployment, or if additional capabilities provided by a full J2EE application server (EAR deployment) are exploited only in custom java code in activities
YES some of the capabilities like below(I'm aware of) won't work with WAR deployments though we exploit custom java code thru activities. It has to be understood by J2EE compliant app servers and requires certain changes in config files that are available in the EAR file when we deploy Pega as J2EE application.
JCA Resource adapter
JMS MDB Listener (This type of JMS listener is available only when PRPC is deployed as a J2EE application (EAR)) -
Service-EJB instances ... etc...
However, the usage of WAR file is recommended due to the fact that there are alternatives for most of the J2EE feature/capabilities now, as all of us are moving towards services & API based integrations which can be accomplished with WAR deployment itself.
I hope this clarifies.