WebSphere Liberty has now ‘grown-up’ to provide the full Java EE 7 platform. Combining that API set with operational capabilities that have been rapidly expanded over the past three years, Liberty is now a great deployment choice for many Java applications. WAS traditional remains fully strategic, however, and will evolve to the Java EE 7 standards itself in time, so how do you choose between the two?

This article will introduce some of the aspects that you should consider when choosing between traditional WAS and WebSphere Liberty.  For a deeper dive into these aspects, please read the full white paper (PDF).

Programming Model (API)

The first aspect to consider in placing your application is which programming models (APIs) it requires.  Liberty now provides the full Java EE 7 platform, as well as many of the related open standards and proprietary WAS APIs that are available in traditional WAS.  There are only a few strategic APIs that are not available with Liberty, including some of the OSGi Application support (although that gap has continued to close with each quarterly delivery), and some of the Java EE standards beyond the Platform specification, including Portlets and SIP servlets.  Less strategic programming models that are not available with Liberty fall roughly into four categories: APIs deprecated by the Java EE specification, WebSphere extension APIs that have been superceded by Java EE capabilities, APIs used mostly by extending products, and some other WAS APIs that have low use among customers.

There are tools available to examine your application code and to identify the use of any of these APIs.

 

Administration and Topology Choices

There are key differences in the administration and underlying configuration models of the two profiles.  If you have extensive investment in automation scripts for traditional WAS that cannot be used with Liberty, you may choose to stay with traditional WAS for the time being.  However, the radically simpler configuration and more flexible administration choices for Liberty are also compelling reasons for some to move.  If you are starting from scratch, or building a next-generation application infrastructure, Liberty provides a simpler, more flexible administration model that fits very well with modern dev-ops flows and tools.

There are some hybrid management options which allow Liberty servers to be managed in existing traditional WAS cell topologies. These models may allow a more rapid integration of Liberty servers through using familiar tools, but will generally still require new scripts to be written for automation.

Both profiles provide a web admin GUI. Traditional WAS has a mature Administration Console which allows fine-grained configuration updates, provides many wizards to accomplish common tasks, and allows deployment of applications as well as most other administrative actions.  Liberty has a more modern Admin Center feature, which provides a highly scalable view of the Liberty topology with more focus on monitoring than fine-grained control, in keeping with the general trend towards automated dev-ops flows.

 

Other considerations

Management of HTTP traffic is very similar for both profiles, as are options for session distribution. There is no failover provided in Liberty for stateful web service or remote EJB requests. There are still some differences in the provision of security services, including SAML and programmatic access to users and groups in security repositories.

As alluded to above, server start time and memory footprint are generally much lower for Liberty, but because of the extensive sharing of code for transports, containers and application services, the production throughput performance of both profiles is very similar.

Version migration is simplified on Liberty; user configuration does not need to be modified for use with new versions of the runtime, and the continued support of existing API features means that applications don’t need to be migrated either; this could be a significant cost-saving going forward.

General advice

Reasons to choose traditional WAS

  • It costs nothing to move (if you’re already there and it does what you need)
  • Still has more function than Liberty
    • Full API, full admin console, security options
    • Some applications can’t move or would take too much effort
  • Uses existing admin skills and assets
    • plus larger existing body of knowledge/information
    • more training courses available
  • Integrated with more products for management/production
  • Common stack for key Portfolio products
    • Portal server, BPM

Reasons to choose Liberty

  • Smaller, simpler, faster to set up
    • easier to have common development and production runtimes
  • More flexible to install, update and manage
    • packaged server ‘master image’ deployments are popular
  • Composable, right-sized runtimes
  • More choice of deployment environments
    • Bluemix, other PaaS, containers
  • Liberty on z/OS has higher throughput, lower resource use
  • Servers of any edition can be centrally managed (although not clustered)
  • Greater management scale with collectives than cells
  • Earlier support of new technology through continuous delivery
  • Easier version to version migration once using Liberty

Summary

This article provided a brief overview of some of the aspects to consider when choosing between traditional WAS and Liberty for application deployment. The full white paper (PDF) provides more detailed information about the differences described here and some additional characteristics to consider when making this choice.

8 comments on"Traditional WebSphere or Liberty: how to choose?"

  1. Dear All,
    If we develope an application using Liberty and the production using WAS, do we need more configuration on production?

    Thanks

  2. LibertyEvaluator December 12, 2016

    We are currently looking at extending/upgrading our JEE application server estate (test/pre-prod/production) for a large JEE application which is currently based on WAS ND v7. The corporate technical strategy is to move away from WAS to an alternative such as JBoss EAP to reduce licencing costs but there is a risk that this could be disruptive for existing applications such as this one so I have started looking to see whether Liberty could offer us a more cost effective licencing model whilst reducing the risk of porting to a different JEE application server. The document is helpful but I’m confused by one aspect:
    “Another benefit of the Liberty collective is in the licensing options. A number of management features can be configured in the controller and the member servers, which provide varying levels of management capability. The controller feature itself is only provided by the WAS-ND product, but the basic collective member feature is included in all WAS products, including the low-end Liberty Core edition. This means that Liberty servers that are licensed for Liberty Core or WAS (base) can still be part of a collective, and can be managed from the central collective controller. In addition, Dynamic routing (see Intelligent Management) can also be used in this mixed-license configuration.”
    However, when I have read through InfoCenter it would seem that other than possibly managing the application server configurations, this model wouldn’t actually deliver even basic functionality that we would expect from the equivalent cluster in Classic ND (e.g. stopping/starting JVMs). Have I misunderstood this? Is there a table which would summarise what features are available to collective members which are not ND licensed vs those which are ND licensed?

    • AlexMulholland December 15, 2016

      Thanks for your question and your interest in Liberty. There isn’t a table showing those differences but I agree that would be a useful addition, perhaps we can get that into the next update of the paper.
      There are basically two things you can do for management of non-ND licensed servers in a Collective:
      1) Use the controller as a JMX proxy to the servers. This means you can connect to the controller (through your own client, a generic JMX client like Console, or using the Liberty Admin Center web GUI) to deploy, view and manage the servers. Manage in this sense includes stopping and starting, pushing out files (for config updates), viewing and editing the server’s configuration files, viewing the monitoring graphs etc.
      2) By adding the dynamic routing feature to the controller, you enable dynamic routing for all members of the collective – this means you don’t have to manage web server plug-in configurations for the individual app servers, and any changes to routing (adding a server/application, stopping a server/application etc) are immediately reflected in the routing of HTTP requests by the web server. It’s a very handy capability.
      Looking at it from the other side, the 3 functions that you only get for ND-licensed app servers in a collective are these:
      1) the ability to group servers into static clusters (management groups) for more convenient management as a group
      2) auto scaling of servers in a cluster (starting/stopping/provisioning in response to workload changes)
      3) health policies (automatic responses to breaches in configured parameters)
      I hope this helps
      Regards, Alex.

  3. Philippe Gregoire November 08, 2016

    Hello,
    Would there be an update to this paper now that WAS v9 is out and J2EE 7 is also supported by Classic?
    Thanks!
    PhG

  4. The DB2 automatic client reroute function can be used to failover between a local and a remote DB2 instance as described at https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.ha.doc/doc/c0011976.html?lang=en
    however, you can not mix client JDBC types as the client doesn’t change during a failover, only the logical connection to the databases. A config sample of configuring automatic client reroute for the type 4 driver can be found at http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_config_reroute_db2.html?cp=SSEQTP_8.5.5&lang=en

  5. DatapowerRookie May 10, 2016

    Is there a provision to mix local and remote DB2 instances as primary and failover options with Liberty?. If so, can we mix jdbc type 2 and 4 drivers to accomplish this?. Sample server.xml configuration would be nice to have.

    Thanks.

Join The Discussion

Your email address will not be published. Required fields are marked *