Several new features are now available but there is one really interesting that introduce exciting architectural improvements.
In particular there is an architectural option who opens new scenarios for the ecommerce implementations based on Websphere Commerce and it reduces, very interesting from the business point of view, the licence investment needs.
With FEP7, Websphere Commerce becomes a platform able to implement CQRS pattern (“Command Query Responsibility
Segregation”) allowing to separate transactional traffic (“command model”) from browsing traffic (“query model”).
In general CQRS pattern is a natural evolution of CRUD model (“Create/Read/Update/Delete”) and allows ecommerce users to browse transparently two different infrastructures: one dedicated to the catalog navigation where no changes are needed on the underlying database and another specifically focused on managing transactions.
On WebSphere Commerce these two models are sharing the same database but the “query model” is based on REST services pointing to SOLR indexes.
The chance to (finally) split up the monolithic WebSphere Commerce architecture in two separated infrastructures introduced by FEP7 (image from IBM Knowledge Center)
allows to scale up independently the Search infrastructure (“query model”) from the Commerce one (“command model”).
Search infrastructure handle all browsing traffic without updating database model (navigation based on SOLR) and Commerce infrastructure manage all ecommerce related transactions (shopping carts, orders, users…)
Commerce and Search infrastructures can be separated on different Websphere Application Server clusters (image from IBM Knowlegde Center)
and Search cluster can be reached from ecommerce frontend using his dedicated REST interface (lighter than the previous one) (image from IBM Knowlegde Center)
As the frontend can call Search infrastructure directly, the Commerce infrastucture has to manage transactional requests only.
And the consequence is you can size Search and Commerce infrastructure independently and also manage separated deployment processes getting more flexibility to adjust hardware requirements to your real needs. In retail customers for example you can improve your Search infrastructure to handle more browsing users during seasonal peaks without changing the transactional infrastructure depending on your user traffic pattern.
As shown on the pictures I got from IBM Knowledge Center it’s possible to create two different clusters, one for transactional and the other dedicated to no transactional traffic and using CBR (Content Based Routing) functions of a dispatcher to distribute REST calls to the different servers depending on their content (or better on his URL pattern).
Which are the advantages to distribute no transactional requests to a specific cluster?
- Scale up independently resources dedicated to browsing and business transactions. If you need to manage traffic peaks probably your Search infrastructure will need more resources but your Commerce cluster will not. And it’s cheaper to add resources to a Web+SOLR 4.3 infrastructure than scale up DB2 or Oracle.
- Better problem isolation. Separating the Commerce monolithic architecture in two infrastructures, issues on one environment are not affecting the other.
- Higher ROI. Starting from now Websphere Commerce customers can use in his no transactional infrastructure (Search servers) the same number of cores (or PVUs) paid for the transactional infrastructure. It’s a simplification of course but we can say that splitting the ecommerce infrastructure using CQRS pattern allows you to “double” your Websphere Commerce investment in terms of licence.
To summary thanks to this new exciting features introduced by FEP7 that allows to separate transactional and no transactional traffic, it’s possible to separate scale up and optimize your investment on Websphere Commerce.
The spanish version of this article is available on atSistemas website.