A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really wanted to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.
Now I started this out with the intent of covering everything in a single post but as that post got longer and longer I decided to split it up into multiple parts. So here's the first installment with a couple more to come soon.
The first thing you'll come to realize in the first couple of hours working with CS is that security is a big deal in this release; both a blessing and a curse. A blessing in the sense that the security system provided out of the box provides rich possibilities for securing the various subsystems of Commerce Server. If setup properly all components are protected by multiple layers of security and you even have the possibility to go one step further than that by leveraging business data security. Basically the last layer of security allows you to specify what data users or roles can access, not only that but you can go down to operation level and specify which operations are available to particular groups of users. While this sounds like role-based security it's not, this is much richer than that and is more akin to code access security only with a business focus rather than a technical focus.
I started out by stating that the rich security features are both a blessing and a curse, so how can that be the case with all of the above? The fact of the matter is that with security comes complexity, imagine a setup with multiple web sites running in IIS each with its own app pool of credentials, this goes all the way to the database where the individual services have very specific roles assigned to them. Debugging an error in a setup like that is very difficult and this is some of the more bland stuff you'll encounter :)
Commerce Server leverages a lot of platform technology, one that comes to mind immediately is Distributed Transaction Manager the very same used by System.Transaction in .NET Framework 2.0. Basically MSDTC is great when it's working, when it's not you'll really come to loathe it. I've been through numerous debugging sessions where MSDTC either wasn't running on all machines, it couldn't do reverse name lookups over the network, firewalls were blocking ports, etc.. As I said it's a pain when it's not running.
What this is all boils down to is that not only do you need to know Commerce Server as a product; you'll also need to know the basics of the Windows platform. This probably seems straightforward, if it does all the more power to you, but with more and more abstraction levels on top of the metal people do have a tendency to forget the underlying platform.
Developing with Microsoft Commerce Server 2007 Part 2: Three-way Data Access
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.