The most obvious difference to the commerce-led scenario in the content-led scenario is the presence of a second virtual host, that separates both systems, the CAE and the commerce system, clearly from one another. Here the CAE is the fully equal partner of the commerce system with the potential to become the driving force for rendering the whole front end.
The description of a typical request flow through the system, as shown in Figure 5.9, “Content-led integration scenario”, clarifies the different roles of the CAE and the commerce system in this scenario.
The user requests a marketing driven landing page of a shop system.
The virtual host for the CAE forwards the request to the CAE.
Part of the requested page are various product teasers, with dynamic prices. Hence, the CAE needs to fetch corresponding information from the commerce system.
After receiving the page from the CAE, the user decides to click on a product teaser to see the corresponding product details. The link, rendered by the CAE as part of the landing page, directs the user to the virtual host of the commerce system.
The virtual host forwards the request to the commerce server.
As the requested Product Detail Page (PDP) contains a CoreMedia fragment, the WCS requests it from the CAE and sends the whole PDP back to the user.
From the example follows, that the commerce-led integration scenario described in Section 5.1, “Commerce-led Integration Scenario” is a subset of the content-led scenario. The request flow 4->-5->-6 uses the exact same technique to handle included CoreMedia fragments into WCS pages as described in the commerce-led scenario. The only difference is that resources or dynamic fragments fetched via Ajax requests are not handled by the virtual host of the commerce system. Instead, they are sent to the CAEs virtual host.
 |  |  |
 |