FEP7: CQRS pattern on WebSphere Commerce

On February 28th, IBM made available WebSphere Commerce Feature Pack 7 (FEP7) for version 7.

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)

FEP7 splitted infrastructure for Commerce and Search

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)

Commerce and Search separated clusters

and Search cluster can be reached from ecommerce frontend using his dedicated REST interface (lighter than the previous one) (image from IBM Knowlegde Center)

FEP7 against previous REST implementations

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.


Websphere Commerce and Portal Architect ✔ Motivated IT professional with more than ten years of experience, combining Java and JEE developer skills with systems and IBM products installation knowledge. ✔ Strong experience and skills on planning, architecting and implementing complex commerce and portal solutions based on IBM middleware products. ✔ Reliable with a strong network attitude, experience on leading developer's teams and manage international relationships. Specialties ✔ Pleasant manner, reliable. ✔ Ability to consider issues from different point of views. ✔ End-oriented work capacity and problem-solving attitude. ✔ Ability to work with deadlines and under pressure. ✔ Ability to prioritise tasks and manage people. ✔ Ability to increase the whole team skills. ✔ Ability to generate commercial leads

Tagged with: , ,
Posted in search, websphere commerce
One comment on “FEP7: CQRS pattern on WebSphere Commerce
  1. […] Marco Fabbri outlined this in an excellent blog post back in June this year.  […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: