Overcome E-commerce Application Challenges
Learn how Commerce Server 2002 offers a framework that reduces Web development time, costs, and risks.
by Rockford Lhotka and Todd Van Nurden
September 2002 Issue
For this solution: Commerce Server 2002, .NET Framework, Visual Studio .NET
The Web provides extensive business opportunities, both internally and externally, but addressing these Web-based opportunities creates technical challenges. When you plan an e-commerce application, you need to consider security, user profiling and customization, scalability, and performance issues. You also need to know who's visiting your site and need to filter the site's content to meet that visitor's needs. The great part about Web-based development today is your team doesn't have to re-create the wheel. You can take your choice of existing toolkits and development products to build a solid e-commerce application infrastructure.
In this article, we'll discuss how to address some common Web-based development challenges with Commerce Server 2002 and .NET. Now, before you turn the page, or throw down the magazine, because your organization doesn't have an e-commerce site, bear with us for a few more sentences. In our opinion, the name Commerce Server doesn't adequately describe what the product offers. Commerce Server 2002 isn't merely an Internet storefront technology; it provides a host of tools and technologies that can simplify building and managing many types of complex Web systems. You can use Commerce Server technologies as a whole to create an e-commerce application, or in pieces to create other types of Web applications. Some companies leverage Commerce Server to develop event calendars, job listings, and news-and-reviews sites, while others use it for its authentication abilities or its analytics alone. You should think of Commerce Server as a toolkit rather than a storefront. Now that it's coupled with .NET, Commerce Server 2002 provides a framework you can use to build Web-based applications, rather than creating everything from scratch. Next we'll address some of the common challenges in Web applications, and explain how Commerce Server offers a solution.
Client authentication, profiling, and content selection are essential elements for most modern Web applications, but they also represent some of the most common Web development challenges. Authentication can mean many things, but for our purposes authentication means the act of identifying users accessing your system. During the early days of Web development, most sites were developed with a custom-coded authentication solution. More recently, authentication facilities have been available as part of the operating system or as a third-party solution. However, just knowing someone's user name is generally not enough: Enter profiling.
Profiling is the process of collecting information about your users. Using Commerce Server 2002's cataloging features, profiling can be as simple as requiring the user to select a username and password, or as advanced as collecting a home address, an e-mail, a gender, and recording buying and browsing habits. Profiling can also be tied to Web analytics that track the user through the site based on his or her ID. This can then feed additional hidden profile attributes. Profiling is another area that has been traditionally custom built to address specific business needs. However, as with authentication, this feature is increasingly available as part of the operating system or as a shrink-wrapped solution.
Content selection, or filtering, works with authentication and profiling to target information to the user. Pushing specific information to a user can enrich his or her experience and, in some cases, it ensures that only the appropriate users get to see sensitive data. For example, if your site is an extranet where your partners access and view specific content, you don't want them to be able to access content for internal users. So, you'd use content filtering to target content appropriate for the site visitor. It's one of the more complex feature sets to custom develop. Many architects and developers forget that it's not enough to get the Web site to filter content; you need a system to manage content targeting as well.
All three of these features relate directly to real-world business problems. If your organization is looking for a simpler way to implement them in your Web-based applications, consider using Commerce Server 2002. Its integration with .NET, along with its new features, offers a new way to address these challenges.
Start With Authentication
Authentication is the starting point for everything. Without some type of authentication, it's difficult to secure your site and filter content for visitors. Commerce Server offers an extensive authentication infrastructure. You can tie it directly into the Windows security model, or you can implement your own model using the Commerce Server profiling database. You can also use a combination of Windows and custom security, based on your business requirements. This is often useful when your application has both internal users (authenticated through Windows) and external users (authenticated from your custom user database). However, the complexity of a mixed model typically outweighs the benefits. Mixed mode authentication requires additional work to secure content store in the file system as well as requires the developer to implement additional checks as part of each page request. The benefit to mixed mode is that you can leverage your investment in other systems, such as a customer relationship management (CRM) package or Windows.
Implementing either approach requires you to install Commerce Server on each Web server supporting your e-commerce site. Commerce Server manages the authentication resources though a Microsoft Management Console (MMC) snap-in. This allows administrators to modify settings from browser and cookie support to login pages, session times, and authentication modes within the familiar, standard MMC environment used for almost all system administration under Windows 2000.
Once you've installed Commerce Server and configured authentication, you can customize its behavior. So, if you don't like Commerce Server's default authentication pages or want to include additional security checks against other systems, you can make changes to suit your requirements. Commerce Server 2002 ships with a series of example sites that provide sample implementations of basic Commerce Server functionality, including sites targeted specifically at the .NET developer. These sample solutions integrate directly into the Visual Studio .NET environment, providing the developer with a single consolidated environment.
Commerce Server 2002 also includes a series of .NET classes that provide Commerce Server functionality directly to .NET. Although Commerce Server 2002 was written using Windows and COM technologies, this library of classes ensures that it's fully available to the .NET developer.
In the case of authentication, the developer can simply reference the CommerceServer and CommerceServer.Profiles namespaces to implement the authentication. Authentication can be done in as little as six lines of code, which include the appropriate warning messages and commonly anticipated behavior.
Using Commerce Server and .NET also allows you to modify your application's authentication architecture without breaking existing code throughout the application. The actual authentication mechanism is encapsulated within Commerce Server itself, so you can change from one authentication scheme to another by changing code in only one location.
Once the user has been authenticated, the developer needs to use only the Commerce Server profile object to determine if the user has filtered available content (but we're getting ahead or ourselves). Commerce Server and .NET handle all session ticket processing, cookie management, encryption, and session timeout management. By writing less authentication code, your development time is reduced, as are your long-term maintenance costs.
Use Windows and Active Directory Authentication
As we mentioned earlier, you can customize how Commerce Server authenticates visitors to your site. You can also use Windows domain or Active Directory (AD) security as an authentication option. However, this choice comes at a price: licensing. If your system is for internal use only and all your users already have Windows Client Access Licenses, this could be the way to go, because they're already licensed. However, if you're deploying your application on the Internet, where you might need to support hundreds or thousands of external users, the licensing costs per user could become prohibitive.
The .NET Framework already implements all the required hooks into the operating system to provide a robust Windows-based authentication solution. The Windows .NET solution also allows you to manage profile data in AD for each user. This approach is particularly viable if you've implemented AD already; otherwise it requires you install and configure AD within your environment.
Besides licensing, performance can represent another serious downside to using AD in an Internet scenario. If you need to support hundreds of thousands of users on your Web site with profile data, the Windows and .NET solution begins to break down. Although AD will scale to millions of users, data-access performance takes a significant hit. This is caused by the number of users as well as the amount of data stored about each user. In this regard, if you architect the solution to store only two data elements per user, your solution would likely maintain a higher level of performance than if you architected it for 10 elements per user. Additionally, as we'll discuss later in the article, Windows and .NET handle content selection poorly when they're used without Commerce Server or another third-party tool.
If you need an authentication mechanism that's more sophisticated than Windows security or a username/password lookup can provide, you can further customize the process. The Commerce Server infrastructure for .NET is implemented as a series of .NET HTTP modules. This standard .NET architecture allows developers to insert their own functionality as needed. They can intercept the processing and make modifications that help systems match the business need.
As we mentioned earlier, simply identifying the user for authentication is often inadequate. In most applications, you'll want to know more about each user. You'll want to have a user profile of some sort. Developers often consider creating a collection system for user demographics or profiles to be a straightforward task. All you need is a Web page with a few textboxes and a database to store the data, and presto! You have a profile system. This is true conceptually, but ignores some important business issues.
Tie Into Existing Systems
First, most organizations have an existing system to manage user information, such as a CRM package or even AD. In this case, it's smart to connect your Web site's data with your existing profiling system. Second, building systems from scratch can increase your risk of encountering performance, scalability, and even security issues. Storing, retrieving, and managing large amounts of profile data is no small matter, and it can be difficult to implement these features without having a significant impact on performance and scalability. Finally, collecting the data is only one part of the equation. You'll need services you can use to administrate the data collection and manage the system's performance and behavior.
It's also important to take privacy and data retention issues into account. A number of legislative initiatives require privacy statements and regulate control over users' data and other important policies and data management. Simply collecting the data into a database, or even placing it into an existing CRM system, might fall afoul of these legislative initiatives. You should approach this sort of data aggregation with great caution.
Commerce Server and .NET provide an infrastructure and services to handle user profiling out of the box. Commerce Server has a service address profiles specifically, including a Web-based administrative application that allows you to set up and manage profiles. BizDesk, Commerce Server's Web-based administration tool, lets administrators configure a profile collection. For example, they can add a profile attribute such as "gender" or "favorite color" to the site's user profile configuration. You can then map this attribute to a persistent storage, such as an ODBC database, an LADP store, or AD. Remember, this all happens through a Web-based administrative application, allowing the system administrators to access these services easily.
By default, Commerce Server saves all profile data to its SQL Server profile database. If you have existing user-information repositories, you can use Commerce Server's MMC snap-in to bind these data stores to the Commerce Server profile infrastructure. This allows you to aggregate user profile information from multiple data sources. For example, we used this feature to tie into a Lotus Notes LDAP store to retrieve client profile information, while other information was stored in SQL Server (see Figure 1).
Once you've configured the profiling resources in Commerce Server, you have full access to these resources within your application through Commerce Server's .NET resources. After a user is authenticated, Commerce Server queries all the associated profile resources automatically and aggregates this information for the developer. When a page request is made, the developer needs only to reference the Commerce Server objects to get access to profile information. This insulates the application code from changes to the back-end profile data stores.
This architecture also scales. Microsoft has run benchmarks against Commerce Server using AD and SQL Server as profile stores (see Table 1). AD supports ten million authenticated users and SQL Server supports more than twenty five million authenticated users. Boiling this approach down, you reduce code, improve management, get proven scalability, and ultimately, save money.
If your system is going to scale past hundreds of thousands of users and you're using AD, Microsoft recommends you use it only for user IDs and passwords and leverage SQL Server to store other profile information. Although AD can store all this data physically, if SQL Server stores it, the data is retrieved more quickly, and, in turn, your architecture's performance is much better.
When it comes to selecting a way to store and maintain profile data, you have a wide variety of technologies to choose from. One way is to develop the profile system from scratch. This entails developing a series of ASP.NET Web pages to collect the user's profile information. The profile data is then persisted to a database such as SQL Server.
Although the custom-build approach works, if your goal is to reduce costs and risks, this plan falls short. With a custom solution, you have to create your own database and tie the profile data to an authentication mechanism so you can look it up the next time the user visits the site—and this doesn't even address administering the profile information or monitoring the architecture's performance (see the sidebar, "Choose the Best Time for Commerce Server").
Developing a custom profile solution obviously isn't ideal, but there are other technologies used commonly for this kind of work, such as Lotus Notes and Domino R5. Both technologies use an LDAP store to manage user authentication and profile information. In this scenario, you could use the Domino Java technologies to develop a site and collection-profile information, or you could even interoperate using .NET. The .NET part of the solution would use the LDAP objects to store and retrieve profile information from Lotus Notes. Lotus provides facilities to manage the user-profile configuration. You could then create a custom ASP.NET Web page to collect the profile information and persist it to Lotus.
Although this approach is completely viable, Commerce Server has an advantage in that it can hide the underlying data store and retrieval process from the application developer. Without Commerce Server, any changes to the LDAP store or structure aren't masked from the Web application, and the application will break if LDAP modifications are made.
Commerce Server's profile aggregation functionality can link back to the Lotus LDAP store. The developers are then insulated from changes to the underlining Lotus store, because they'll always use Commerce Server and it interacts with Lotus and LDAP behind the scenes.
Now that you've authenticated the users and collected information about their preferences, it's time to put that information to work. Content selection enables you to customize your site's behavior and appearance based on a visiting user's preferences. If you're building an intranet site with business applications, content selection enables you to limit services to specific users, preventing them from viewing each other's HR data, for instance.
Make the Most of Content Selection
Although custom development for authentication and profiling can be relatively straightforward, content selection is complex, and custom development is often prohibitive. To create a robust content selection system, you need services to set up content selection rules, a rules engine to process those rules against user information, a content repository, and a reporting mechanism to determine how the process is working.
Targeting content to users isn't always as complex as we just described, but once your business people get a taste of targeting functionality, they're likely to ask for more. Fortunately, Commerce Server's content selection infrastructure provides an organization with features for managing content targeting.
Commerce Server's BizDesk provides an administrative facility to manage Web-based content and content targeting rules. It breaks content selection into three categories: advertisements, direct mail, and discount management (remember, it was originally developed to sell things). If you're selling products and services on your site, then you're set with the discount management function.
However, even if you aren't selling products on your site, Commerce Server's content selection offers valuable functionality. If you want to target specific Web pages, or other Web content, to your users, the ad management facilities are the place to start. Though they're designed to deliver ads, these facilities can deliver any content you choose.
All the content controlled by the ad management facilities are grouped into campaigns. The BizDesk administrative tool is used to manage these campaigns. Each one defines a set of content to be delivered, a content schedule, targeting rules, and can even include other campaigns, allowing you to create a hierarchy of content for delivery.
As part of these campaigns, the business user can specify content targeting rules. The selection rules are based on profile data, and users are grouped and filtered based on the information stored in their profiles. These groups are then associated with campaigns. This allows you to control which groups of users have access to which content. A given user might be in the HR group based on her profile, and because she's in the HR group, she'll have access to any campaign associated with that group. All the HR content in the site can be contained in this campaign, meaning only HR users can access the content.
Commerce Server allows you to specify start and end dates for the content, as well as specify when, how often, and on which pages content should be displayed. You can also specify which selection rules to apply when targeting the content, which enables you to control which users will or won't see this particular content. As a result, the home page might have no content filtering associated with it, but the reporting pages might have campaigns established for finance, IT, marketing, and so on. Out of the box, you can use Commerce Server to manage HTML, image, and multimedia content, and can store it in a database or as a file on the Web server.
The best part of the BizDesk's ad management facility is the content selection rules definition. It allows you to define which users will see your content. Together, BizDesk's Campaign Expressions and Group Targeting functions produce content targeting rules. You can use Campaign Expressions to set up filtering criteria based on information stored in the user profile. For instance, you can target all male users by selecting the gender property of the user profile objects. You could then compound this rule by stating that the males must live in a zip code where 55 are the first two numbers.
The Group Targeting facility enables the business users to create complex selection rules by combining campaign expressions. So, if you take the expression that targets males users with 55 as the first two numbers of their zip codes, you could then state the visitor must be a male, age 25-30, and a resident of Minnesota—but not a member of the sports fanatic visitor group. This might sound quite complex, but most computer-savvy business people can master this task with a couple hours of training and a few days of support.
After you've established the targeting rules, you can specify which pages to display the content on. This criterion takes the form of page groups, which are related series of Web pages Commerce Server manages. Managing these page groups is also a function of the Commerce Server BizDesk.
Drill Down on Content Selection
Up to this point we've talked about the administrative functions related to content selection. Next, we'll dive down a level and talk about how your developers can use Commerce Server to implement these capabilities. Commerce Server's content selection framework does most of the heavy lifting. Remember that Commerce Server and .NET keep track of the current user and that user's profile automatically. Commerce Server then uses this information to populate the Commerce Server objects with the appropriate content selection information. It's up to the developer to call the Commerce Server targeting services to get the appropriate content on each specific page (see Figure 2).
Having these services at the developer's command out of the box can be helpful, but you might encounter cases where Commerce Server doesn't match your functional needs. For example, you might not like how Commerce Server scores the selection rules, or you might want to add another content source the content selection framework doesn't support.
Commerce Server's content selection framework is based on what we often refer to as "workflow lite." Content selection is made up of a series of business components, and each component is responsible for tasks such as scoring the content for applicability, filtering content, and retrieving content. These components are registered as part of a content selection pipeline. Commerce Server provides a pipeline editor to administrate the workflow for these processes. When a service such as content selection is invoked, Commerce Server loads the appropriate pipeline automatically and begins processing the request.
Managing the pipelines used for content selection is built into the Commerce Server .NET extensions. Commerce Server uses sections in ASP.NET's web.config file to establish the relationships between content selection and the appropriate pipeline. This means you can change your application's behavior by editing the web.config file, helping reduce the app's administrative and maintenance costs.
Commerce Server and .NET are designed to address content selection by providing services from administration, management, and logging to development infrastructure. Leveraging these pre-built services can simplify development, reduce risks, and reduce both short-term and long-term costs.
Before you choose any technology, it's important to evaluate the business benefits of a solution. Knowing what your IT infrastructure already supports and identifying your long-terms goals can help you select the appropriate technical solution. But regardless of the tools you choose, they must integrate and work together as seamlessly as possible. Commerce Server and .NET provide the potential for this kind of seamless integration, which ultimately smoothes development and keeps costs down.
Commerce Server and .NET offer integrated platforms you can customize to meet your organization's exact needs. Our experience with large customers shows that point solutions tied together with a ton of code aren't the wave of the future. To be successful, systems need to be integrated. One of the goals of the .NET initiative is to provide a way to simplify application integration. As one of the first .NET-enabled Enterprise Servers to emerge from Microsoft, Commerce Server shows promise in delivering on this goal. It allows the architect and developer to focus on adding the real business value to a system instead of figuring out why systems don't work together.
About the Author
Rockford Lhotka is the principal technology evangelist and Todd Van Nurden is the national practice lead for Magenic Technologies, a premier Microsoft-focused consulting company. Rockford is a regular author for Visual Studio Magazine and is the author of a number of books on Microsoft and .NET programming. You can reach Rockford at . You can reach Todd at .
|