CS2007 Software Architecture Series Part 3: What’s Under the Hood

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
•    Marketing

o    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.

Advertisements

CS2007 Software Architecture Series Part 2: Platform Basics

Most of the meat of Commerce Server is to be found within its programming model and underlying data storage mechanisms. Commerce Server started out with the 2000 release by providing extensions to Active Server Pages. Today, with the 2007 release Commerce Server provides a platform that extends the Microsoft .NET Framework 2.0 and above – utilizing Microsoft Visual Studio 2005 and above as the development toolset. In particular, Commerce Server 2007 is geared towards extending ASP.NET, as that represents the primary means of building Web applications on top of the .NET Framework (though certainly many other creative or legacy means are available).

Commerce Server 2007 supports both x86 32-bit as well as x64 64-bit processor architectures natively, running on top of Windows Server 2003 Service Pack 1 and above. The product does not, however, support the 64-bit IA64 processor architecture (though it can leverage SQL Server running on IA64 systems). For the most part, Commerce Sever 2007 relies upon Microsoft SQL Server for data storage. Commerce Server 2007 supports both SQL Server 2000 and SQL Server 2005. The product, because it still supports SQL Server 2000, does not leverage any specific SQL Server 2005 capabilities however. The rationale behind this was simple – most pre-existing Commerce Server customers were running on SQL Server 2000 at the time of the product’s release; the thinking was that upgrade to a new database platform (given the newness of SQL Server 2005 at the time) would be a barrier to technology adoption. BizTalk Server 2006 is supported from an application integration perspective as well. Microsoft Operations Manager 2005 is supported from a systems health monitoring perspective. Beyond those components, Commerce Server 2007 does not have any particular technical dependencies warranting consideration.

All of that being said, a Commerce Server developer should be proficient in all of these technologies to be successful: .NET Framework 2.0+ (in particular ASP.NET), SQL Server 2000+, Windows Server 2003+, and potentially Operations Manager 2005+ and BizTalk Server 2006+. This, of course, makes finding qualified Commerce Server architects and developers an at times rare breed of individual.

Going forward, Microsoft is committed to enhancing core platform support of Commerce Server 2007 throughout the product’s 5-year standard support lifecycle, which commenced upon August 1, 2006. This makes the product relatively future-proofed. So, as new versions of Windows Server, BizTalk Server, SQL Server, and Operations Manager are shipped in the 5-year period from August 1, 2006 through August 1, 2011 – it is reasonable to expect that Commerce Server will support those versions barrring any egregious breaking changes in the underlying platform – at least until replaced with subsequent versions of Commerce Server itself. Conversely, as products in the dependency stack have their standard support lifecycles end – such as SQL Server 2000 in the coming years – it may come about that platform support is removed in future service packs or other interim releases.

SP2 adds support for Windows Server 2008, Visual Studio 2008, and .NET Framework 3.5. SQL Server 2008 support on SP2 is imminent; details forthcoming.

When planning deployments and which versions of technologies to base a system upon, the bleeding edge should indeed be chosen to maximize longevity of the solution once deployed.

The Ill-Fated Voyage East

I decided that it would be a good idea to drive the Bentley Arnage from Seattle to Ottawa. I set out on a beautiful morning in Seattle in early October. I made it through to Missoula, Montana without incident – and saw some extremely beautiful sights along the way.

Between Missoula and Butte, record-setting snow set in. The Arnage is a rear-drive car. It does not handle snow well. It uses tires that were designed specifically for it – and there are no snow tires available that will fit. The traction control proved to be useless – all I ended up doing was losing all power – and having to turn it off.

After spending the night in Butte, I ended up flying back to Seattle, via Salt Lake City – on the sole flight per day that comes in and out of Butte. There is no ILS nor control tower, so the pilot had quite a challenge getting in and almost had to turn back. (He eventually made it, but landed with the wind versus against – given a clearer approach flying in the opposite direction.)

The car was retrieved a week later after the record-setting snow thawed out – and the roads were again passable.

Given that I live now in a city that is under snow almost half of the year, this requires some re-thinking. Hmm…in the meantime – enjoy the snapshots from earlier in the day at: http://flickr.com/photos/rdonovan/sets/72157608189691237/.

CS2007 Content Management Integration and CS2002 Migration Questions Answered

I received a question this week on how to best upgrade from Commerce Server 2002 to Commerce Server 2007, and then integrate it with a 3rd party Content Management system.

Tackling the upgrade scenario first, the question was raised – is it better to upgrade or re-architect? If you are using Commerce Server 2002 on ASP.NET – then upgrade is probably the way to go. If not, a redesign- with data migration is probably the way to go. Between CS2002 and CS2007 – there is not much direct portability (other than the data) unless the .NET APIs were utilized.

In terms of content management integration, there are several interface points that can be utilized:

  • Catalog Import/Export API
  • BizTalk Adapters
  • Web Services

Depending upon which interface points the content management system uses, any or all of those interface points can be utilized; it is really a matter of preference. There is no right or wrong answer.

What about integrating with SharePoint? I have blogged about this before in March 2006 and in March 2007.That story has not changed – yet. It will, very soon however, with the next release of Commerce Server – which just might be coming sooner than you think…more to come on that.

Hope this helps.