Musings on WebSphere Commerce and stack options

Most of us know this - WebSphere Commerce is an enterprise Java application that runs on top of WebSphere Application Server that runs on an Unix OS and uses DB2 or Oracle as its persistence layer. Technology space is constantly evolving and new choices are available for each layer that WebSphere Commerce depends on. There is often doubts in the mind of retail IT departments on whether they can safely adopt an alternative technology in any of the stacks. This blog is a collection of my musings on that topic:

By default, everyone assumes that WebSphere Commerce (WCS) runs on an IBM stack! But a quick look at detailed requirements page reveals some non-IBM components in the stack: Windows and Linux on Intel based processor systems are two key differences in the operating system layer (bringing in flavors of windows server, Red Hat Enterprise linux and SuSE into the mix), while Oracle is a key difference at the database layer. Otherwise, the list looks like a pure IBM list. However, I have seen customers experiment with more choices than the above. Let us look at some variations.

1. Web Server Options

IBM HTTP Server v7.0.0.37 corresponds to Apache web server 2.2.29. Some customers choose Microsoft Internet Information Services (IIS) because they are using that solution in other parts of their IT enterprise. Similarly, other choices such as NGinx or Apache web server is not unknown. Of course, the default choice of IBM HTTP Server comes with plugin-configuration, predefined configurations for SSL communication between WAS and web server layers and supporting both unmanaged and managed WAS nodes. So using a different web server solution would require IT team to perform some manual configuration. Reasons for choosing an alternative web server is usually because they already use a different web server for their all enterprise needs or are after specific capabilities of a web server (for example, Apache web server version 2.4's bandwidth limits for clients is needed).

2. Hosting and OS options

WebSphere Commerce is supported on popular enterprise *nix options such as AIX and Linux on x86, AMD and PPC architectures and virtualization options such as PowerVM. However, customers often wonder if they can deploy WCS solutions on their choice of cloud providers. The short answer is "WCS is functionally compatible to most cloud providers". Cloud providers differ on the virtualization technology they use - so product will provide a full set of functional features, but the sizing needed to run the solution may differ between the providers. As long as the IT team works with that provider to adjust their techline sizing, this should work. Of course, going with IBM Softlayer means the techline sizing from WCS is straight forward and support is at one place. IBM Commerce on Cloud DevOps services has hardened reference architectures and devops patterns used in multiple client engagements. We also have IBM Urbancode and Chef based setup, configuration and deployment management solution that automates many of the mundane tasks in addition to supporting common solution architectures. And as per http://www-01.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.install.doc/refs/rigsupportSCCI.htm: "Depending on your virtualization configuration and use case scenarios, the cost of operating in virtualized environments could be more than 30% of your overall native, non-CCI IBM WebSphere Commerce available capacity".

On operating systems, if the database and WebSphere Application Server runs on that OS, theoretically WCS also runs. However, from WCS product literature, it is clear that only a handful of operating systems have been certified (tested) for production use. So, while WCS "should" work (and probably would) and knowing IBM, it will probably provide a best efforts help for solving any problems reported on those operating systems, companies adopting any unsupported flavors of Linux should have a plan in place to handle such situations. For example, having at least a small farm of machines in supported OS flavor helps in differentiating a problem as specific to OS or configuration vs WCS product. I haven't personally seen clients experiment much here.

3. DB options

DB2 and Oracle are very popular amongst WCS customers. What if someone wants to experiment with some NoSQL or in-memory DB options? Again, typically with IBM, these will not be supported but if you open a PMR you would find that IBM will help you on a "best efforts" basis - note that this is the same level of support provided for your custom code. I have seen customers with good IT teams experiment with such options. One of the earlier posts in this blog discusses a pattern where some of the information is moved to a NoSQL DB. Similar exploration on using alternatives for parts of transaction processing - for example if you keep all registered shopper information in an elastic search solution.

4. Queue, Transformation, ESB etc

WCS integrates with multitude of IBM and third party products - IBM OMS (Sterling), CPQ... and other OMS and ERP systems are common. Point to point queue based or ESB based integration patters are popular. IBM MQ and IIB are supported. IBM has a long history of supporting integration with SAP based systems, in fact some say better than Hybris. What if you want to explore something like Apache Kafka? Like any solution built on loose coupling - by implementing a few Java Adaptors one can integrate over such technologies too.

5. Monitoring and managing utilities

Any OS level monitoring and managing utilities are of course supported - that is a no-brainer. WCS tracing and logging framework is built on WAS's jRAS framework. While any log monitoring or log analytics tool that reads those logs is easy to support, if you need to replace the complete logging solution with some custom logging framework, you would need to switch out some foundation jars from WCS and WAS. This will impact your support statement. One option to be "in support" is to extend needed classes and override the loggers at all critical places. WCS provides many extension points which can come in handy here.

6. Search

It should be mentioned that another layer that often pops up during solution discussion is "Search". As we know WebSphere Commerce Search has Solr 4.7 (lucene) as its engine, but there are many add-ons that integrates search into mainstream e-commerce. So not just usual search and catalog navigation uses Solr, but price and inventory are available there, rules to modify search are now bubbled up to business tools and search is integral part of precision marketing too. However, some customers want to improve the core search capability itself and that is possible. For example customers may want to upgrade to a later version of Solr to take advantage of a specific filter or add custom extensions to support specific language or capability (such as phonetic search). Since the architecture is loosely coupled, and since Solr configuration (as kept in solrconfig.xml) is visible to IT teams, modifying that layer is straightforward.

7. Utility libraries

Lastly, I would like to mention about multiple third party utility or special purpose libraries that become part of the solution - these are typically located in WC_TOOLKIT/workspace/WC/lib directory in our toolkit. I know of instances where projects needed string processing capability available in a later version of a third party library. That is also the place for adding solution specific additional third party libraries.

I have just shared my musings about some of the common alternatives that come up during discussions with IT experts involved in e-commerce solutions. There are numerous other layers Note that none of the above should be interpreted as a support statement from IBM - these were just examples of options explored to various degree in various contexts. As always, check with your IBM support personnel before venturing into something different.