As noted in previous posts, Commerce Server 2007 extends the .NET Framework 2.0 and above to provide core e-commerce entities. These entities are:
• Catalog
• Inventory
• Orders
• Profile
• Marketingo Advertisements
o Discounts
o Direct Mail Campaigns• Analytics
In addition, there is an administration framework to provision all of these entities that is shared horizontally across the breadth of Commerce Server. Likewise, the Analytics module – utilized for business reporting – also leverages all of the aforementioned entities.
It is important to step back and think about the system at a forest-level. Doing so is a key factor in thinking about how to successfully leverage each component and properly navigate the interdependencies between them when architecting a software solution based upon Commerce Server.
Data is stored in SQL Server. The schemas are managed and accessed through the programming model – and are generally not meant to be touched directly by the end-developer. In fact, modifying the out-of-box schema is a good way to end up in an unsupported state and have the system broken when hot fixes or service packs are issued by Microsoft.
The programming model itself provides three programming models and an adapter framework:
• The Runtime API is meant to extend ASP.NET and provide the developer with an experience that is conducive towards building an end Web site. Plain, simple – and nothing more than that. If that’s the case WAIT – why does the programming model seem so bizarre compared to ASP.NET then? The answer lies in the past.
o Commerce Server 2000 was the first release of the product. It at the time extended Active Server Pages (ASP) rather than ASP.NET – as .NET Framework 1.0 had yet to ship. Hence, the programming model was exclusively COM-based.
o Commerce Server 2002 supported both ASP.NET and ASP/COM development (as backward compatibility with Commerce Server 2000 was mandatory). The ASP.NET support was implemented by implanting a two-level programming model:• Primary Interoperability Assemblies (PIAs) – These are simple wrappers of the COM APIs dating back to Commerce Server 2000 days. They were never meant to be consumed by end developers, though this did occur in practicality in many cases. Leveraging the PIAs in any version of Commerce Server is a bad move – as is setting the stage for broken forward-compatibility. This is because it was always intended that the product would be ported to .NET and COM support retired – therefore the PIAs were meant as a temporary stopgap measure at most.
• Base Class Libraries (BCLs) – These are abstractions of the PIAs to provide a more .NET-friendly programming model. It is intended that the BCLs are the primary API model consumed by site developers building Commerce Server applications. Over time as the product evolved – this would be the programming model going forward and the PIAs would be retired in lieu of native .NET implementations under the BCLs. Because the BCLs evolved from the PIAs, they do appear less .NET-like than something built expressly in managed code from the get-go. Over time, it is reasonable to expect these to be gradually re-factored to drive closer look-and-feel to the core platform (also as the remaining COM underpinnings are replaced).o In Commerce Sever 2007, both the BCLs and PIAs are present. Some of the PIAs that were present in Commerce Server 2002 are gone and replaced with native .NET implementations. In other cases they remain – as it was less costly (in terms of both internal development effort for Microsoft and in providing backward-compatibility to the customer) to leave some COM underpinnings in place. There are some latent COM APIs, but these are NEVER meant to be called, nor are the PIAs.
• The Web Service is meant to provide a means of performing data management CRUD (Create, Retrieve, Update, and Delete) in a secure, distributed means. It is implemented as an ASP.NET Web Service (ASMX) – as that was the newest Web services implementation available from Microsoft at the time of the product’s ship. Given the subsequent release of Windows Communication Foundation (WCF) after Commerce Server 2007 shipped, it is likely that Commerce Server 2007 will be the only major release of the product to leverage ASMX-based Web services.
• The Agent API implements the Agent design pattern to abstract the Commerce Server 2007 Web Services. It provides a lightweight runtime that can run upon the end client and run either natively or in distributed mode. It provides a considerably more natural and friendly CRUD programming model than calling the Web Services directly. It also provides for other means such as caching, etc. to improve performance.
• The BizTalk Adapter exposes the Web Service through BizTalk, allowing data to be interchanged utilizing the toolset and user interfaces within BizTalk Server with ANY system to which BizTalk can communicate WITHOUT writing any code. As of this writing, the list is extensive in terms of what is supported out of the box, with adapters available from Microsoft – see http://www.microsoft.com/biztalk/en/us/adapters.aspx.
One comment that is often raised is that Commerce Server 2007 will perform badly because it still has COM under the hood. Or the fact that COM is even present is brought up as a detractor. In terms of being a real issue, this is more myth than reality. First, Commerce Server is a .NET application; its only supported programming models are .NET-based. Second, COM underpinnings are not a detractor to performance at all. In fact – many parts of the Windows operating system and things that underlie parts of the .NET framework are also COM-based and follow a similar architecture.
