WebSphere Application Server Reviews

More suitable for DevOps Environment.

Easy Deployment from command line.

Minimize the fixpack levels.

Better and simpler Admin Console

Auto Heap Management

Email SMTP Connectivity

In this era of cloud technology, Websphere Application Server required Integration with cloud technology.

Troubleshooting tools need to included in Websphere Application Server package for better troubleshooting of issues.

Websphere Application Server comes with some basic performance tools and these troubleshooting and performance tools need to be enhanced.

It's available in all operating systems like Windows AIX Unix Solaris Zos etc.

Licensing costs can be quite steep, more so than some competitors.

There's quite a steep learning curve with some elements and the support available online is fairly limited.

Downloading WebSphere Binaries from Passport Advantage can be made a little easier

May be expensive from a licensing perspective

The first issue for me is the time it takes for the application server to start. That's one area I hope to see improvement on

Another issue is that there are times when the nodes have issues syncing

The initial learning curve is steep, especially for new users

High overhead (i.e. resource cpu/memory)

Configuration can always be improved

Messaging functionalities are little bit complicated

There should be more detailed tutorials for messaging and security

Certification for expired notification should be automated

The IBM Websphere console would behave erratically at times. When starting or stopping the server the small red and green icons would often take time to change even though the server would have started or stopped.

When deploying the EAR files, the logs are displayed. In case the window is closed or you click on any other link on the console there is no way you can get the console log page back. You will have to keep refreshing the deployed resources page in order to figure out if the deployment is complete or not.

When changing the status of the servers, no intermediate status is shown. Most of the time it works fine, as stated in the first point it would behave erratically. When the status changed the page would suddenly get refreshed and the icon colour gets updated. An acknowledgement and and console log like the once shown in deployment would be helpful.

Less a problem of the platform but often software developed to run on top of WebSphere is tied to specific versions of it, making it difficult to have a central WebSphere farm that can service all your application needs.

The install is now fully graphical, but the configuration still requires a lot of manipulating of command line and xml/properties files. This makes it almost impossible for a novice to set up and configure; companies have to hire experienced consultants to get the job done.

Takes a bit time to get a server up and running.

Node Sync.

Steep learning curve (time consuming because of its complexity).

Setting up SSO for the application can be made simpler.

Context root dependencies can be removed.

Have had a lot of crashes on the DMGR on WAS 8.5.5. That needs improvement. Even though the available memory is more than 80% it generates multiple core, javacore, snapcore etc., dump files, which just occupy disk space.

Improvement in cache clearing. We shouldn't be required to clear the cache and restart the process.

Node sync issues.

Ease of use in terms of deployment, give simple interface to do simple stuff like Tomcat, JBoss or GlassFish.

Takes long time to start the server.

The Liferay wars need to be decorated and then deployed. Perhaps we could simplify that.

Some of the concepts are good for complexity that WAS can handle but could be simplified and better documented, like concepts of well and profile, context, etc.

A Liferay war file created using Liferay Developer studio runs fine in Tomcat, however that may not run in WAS 7.x because it needs to be decorated. I had one war for a Liferay portlet with a simple cron job, and had hard time running to WAS server. It was running on the latest free download done on my friends m/c. Other times I have seen that there are issues running a war file that runs on Tomcat but runs on WAS after lot of customization for WAS.

The corporations like this however, the product may need better vibrant community of users where issues can be discussed.

The product works great why change it -how much better can you make it...

SSL use for certificates could be a little more simpler

Ease of use in terms of deployment, give simple interface to do simple stuff like Tomcat.

Some of the concepts are good for complexity that WAS can handle but could be simplified and better documented, like concepts of well and profile, context, etc.

Takes long time to start the server.