All Things WebSphere

Enhancements to the Liberty profile are as follows:

• Certification to the JEE 6 Web Profile, providing the assurance that applications leverage standards-compliant programming models
• Additional programming models such as web services that enable the expansion of Liberty profile applications beyond web applications
• New messaging capabilities, including support for JMS and message-driven beans, and a new single server message provider
• Ability to add Liberty features through a new system programming interface, enabling the customization of Liberty profile capabilities to meet your business needs through insertion of custom Liberty features
• Support for the NoSQL database MongoDB, a scalable, well-performing, and easy-to-use document-style NoSQL database
• Enhancement to security support, such as federated repositories, custom user registry, trust association interceptor, password hashing, and encryption of passwords in server configurations, which improves security for Liberty application deployments
• High Performance Extensible Logging (HPEL) for Liberty servers, which enables better administration and serviceability
• New Liberty administration features
• Clustering of server instances
• Support for caching via the WebSphere Web Cache (DynaCache) and distributed caching with WebSphere eXtreme Scale
• Ability to install the entitled WebSphere Application Server edition on developer
machines for development and unit testing purposes•
• WebSphere Application Server V8.5.5 tooling bundles updated with Rational®
Application Developer (RAD) V9 and the WebSphere Application Server Developer
Tools (WDT) V8.5.5

For details see http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&appname=gpateam&supplier=897&letternum=ENUS213-137&pdf=yes

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

In case you are wondering where I have been all these months. I have taken a new job within IBM as a senior developer working on Cloud based application platform and services.

We just released Project Icap at IMPACT 2013
See https://www.ibm.com/developerworks/community/blogs/icap/entry/home?lang=en

1812 icap-v1.3 0430 from kelapure