Sitecore Commerce Server – What happened to the Foundation API?
This post is the first of many where I’ll be writing about Sitecore Commerce Server, previously known as CommerceServer.net and before that known as Microsoft Commerce Server.
I little introduction to myself, I’m Brian and I’ve been doing projects based on Commerce Server since 2007 – and since 2010 I’ve also done a lot of developer training (www.commerceservertraining.com) on the platform.
Back to the topic, on What happed to the Foundation API? Multi-Channel Commerce Foundation / MCCF / Foundation API was introduced in the Commerce Server 2009-release. Besides being a whole new programming model including a bunch of new DLLs, the Foundation API is also a set of infrastructural components including a WCF-based service layer.
What is the Foundation API?
The Foundation API is new programming model, that basically wraps all existing functionality offered by the Core Systems (Catalog, Orders, Profiles and Marketing). The Foundation API introduced a new Object Model, e.g. ICommerceEntity that is a generic and lightweight object especially designed to be serializable. The way you connect to Commerce Server is through an IOperationServiceAgent that, behind the scene, communicates with an OperationService (Broker). This IOperationService agent can work in two ways, 1) InProcess or 2) WCF, depending on your configuration.
One of the features in the Foundation API is the possibility to (easily) expand from a 2-tier topology to a 3-tier topology.
The 2-tier topology is the classical setup, where you install Commerce Server on the web-server that will host your web-site (running Sitecore/Umbraco/or anything that is ASP.NET enabled). You can’t combine different versions of Commerce Server on a single server as the installation includes configuration in the registry database (MSCS_Admin connectionstring, COM registrations and more), GAC (Global Assembly Cache) assemblies and a number of tools. So don’t even think about it – one server is bound to one version. The bottom-tier is, not surprisingly, the database server.
The 3-tier topology adds a new “Application Server”-tier in the middle of the topology. The “Application Server” is where you’ll install Commerce Server (similar to the “2-tier topology” previously mentioned). The difference lies in the top-tier, which we’ll call the “Web Server”. This server does not require Commerce Server to be installed. The only requirement is that the web-site running on the “Web Server”-tier has a subset of the Commerce Server assemblies, being the Foundation API assemblies, which you can simply include in the \bin folder along with some configuration in web.config to let Commerce Server know that it’s running in 3-tier mode.
So why is 3-tier topology interesting? For the projects we’ve been working on, introducing the 3-tier model has never been about scaling or about minimizing the amount of licenses required. The argument behind is to simplify the Development Setup.
In the 2-tier model every developer on the team is required to work on a server where Commerce Server is installed. And we can’t just simply install Commerce Server directly on the developer machine, as we work on multiple client projects with different versions of Commerce Server, thus we have to be able to swap fast between these projects. Effectively what we’ve done is to have every developer do all development work locally, in Visual Studio on their own physical machine (workstation / laptop). And in order to test the work just done, deploy the code to a virtualized server dedicated to the developer – and use remote debugging when we have to (and of course we do). Working in Visual Studio on our local machine has some advantages. Our machines are super fast and all our productivity tools are right there, we can utilize our 2-3 monitor setup, and we can minimize the “hardware” requirements to our virtualized server which is sharing resources with a lot of other developers in the team/company. This allows us to have more virtualized servers per physical host machine. The disadvantage is clear though; every time we change something, that change has to be deployed.
With the 3-tier model we don’t need to have a 1:1 relationship between virtualized servers and developers on the team. The 3-tier model allows us to run all code locally (on our local developer machine) – where Commerce Server behind the scene connects to the Foundation API WCF service running on a single server, shared by all developers on the team. Only that single and shared server needs to have Commerce Server installed. This has turned out to be a major productivity boost for us – allowing us to quickly add new team members, but more importantly reduce time spent cycling between development and testing. The concrete way to setup this 3-tier model is out of scope for this blog post.
The Foundation API is not used by the Sitecore Commerce Connect architecture.
The Commerce Connect implementation (Sitecore.Commerce.Connect.CommerceServer.dll) is, similar to the Foundation API, an architectural layer that wraps existing functionality of the Core System (Catalog, Orders, Profiles and Marketing). This effectively means that in order to execute any code you need to be on an machine with Commerce Server installed (exactly like the 2-tier model, mentioned earlier in this blog post).
While this is bad news for us, again because it will add complexity to our development setup, I do recognize the reasoning behind this decision. My best guess is that one of the arguments is to minimize the overall complexity by “simply” removing a major architectural layer (+ tier) (Foundation API), which then lowers the learning curve for new developers to be able to work effectively with the platform.
My fingers are crossed that another argument for not using the Foundation API is that the awesome guys at Sitecore could be working on a solution that allows us not to have Commerce Server installed in order to run Commerce Server code – a solution that then would remove the requirement of having to install or place anything “outside the web-site folder”, having no GAC assemblies and no registry database configuration, thus allowing us to run different versions of Commerce Server side-by-side on the same machine.
Please don’t hesitate to use the Comment-area below to ask questions, share thoughts and ideas or to propose other topics for future blog posts. Thanks.