All Things WebSphere

Scenario :  

Following is a comparison of Liberty vs a homegrown Tomcat "kitchen sink" type  server.

Server provisioning:
- Liberty, by design,  allows you to include only the features you need for your applications .
- Liberty  "minify" will subset the runtime for you, based on the configuration of the server
- produces a deployable binary server
- Homegrown is monolithic, will require significant manual effort and testing to figure out how to get back to "right-sized" server environment
-Or customer will need  to always deploy the 60MB homegrown server

- Liberty - configuration changes are dynamic - don't require server restart (i.e. jms, jdbc, vips)
- Homegrown - configuration changes will probably require restart

- Liberty - all the configuration goes in server.xml (or xml files included by server.xml) at customer's choice
-unique properties can be managed external to the server.xml, which allows customization per environment (Dev, FVT, Prod, ...)
- Homegrown - all the packages added to Tomcat will have their own config method/files

- Liberty log / trace files are consolidated
- Trace setting are consistent across components
- Homegrown will have logs/traces in multiple locations
- Homegrown components will NOT have trace setting suitable for production debug

Extensibility:
- Liberty runtime  can be extended by adding features in an architectural fashion, consistent with IBM developed features
-  Can create wrapper for 3rd party libraries which allows configuration of the new "feature"  consistent with IBM developed features
- Homegrown only allows  ad-hoc integrations of 3rd party jars

Dynamicity: 
- Liberty - config changes are dynamic - don't require server restart (i.e. jms, jdbc, vip settings)
- Homegrown, - config changes will probably require restart

Support
Liberty is fully supported by IBM
Homegrown?  middleware support team  + App teams + OSS communities
OSS communities (or public individuals) don't provide formal support.  Its based on best effort and interest as determined by the particular community / individual


Liberty - In the service stream Liberty has strict backward compatibility requirements
- no regressions on service releases
- new behaviors in service must be intentionally enabled by customer
Homegrown - Open Source communities don't adhere to strict backward compatibility.

Standards:
Liberty APIs are primarily based on open standards, allowing flexibility and a wider range of applications to work.
Homegrown - some APIs are based on standards but many are not. (i.e. "stax-2" is not a standard)

Licensing
- Liberty - IBM vet's all the OSS that we deliver and the code we develop.
- Homegrown - due diligence  is customers responsibility

Security differences
- Liberty supports hashing/encryption of passwords  in config, can be kept in separate property file
- Supports seamless integration with Tivoli and other authentication and authorizaton products.
- Homegrown security is likely to be a hodge podge of custom integration with different vendors.

Application Deployment
- Liberty allows automatic "drop in" of new app versions.  No server restart required.
 - Homegrown - Tomcat allows "drop in" deployment, but most likely the extensions do not

Central server management
Liberty collective will allow customer to build large administrative clusters
- i.e. start, stop, update config sent  to LibertyController which updates all servers in the collective
Homegrown - customer would need to develop management framework

Performance 
Liberty is significantly better than Tomcat