A multisite application must be able to quickly determine which site a given request is associated with. The ATG platform includes a very flexible URL management system for ensuring that each request is associated with the correct site. In addition, it provides ways of handling the potentially large number of different URLs that are required for multisite production, staging, and preview machines.

As discussed in the Site Context section, when a new request is received, the SiteContextPipelineServlet examines the URL to determine the site to associate it with. There are two main approaches to making the determination, one based on URL paths, and the other based on domain names.

Path-Based Strategy

In a path-based strategy, the domain name is the same for all sites, and the site is keyed off the context root in the URL. For example, suppose a sports equipment company, sports.com, has separate sites for baseball, football, and basketball equipment. The URLs for these three sites might begin with:

http://www.sports.com/baseball/
http://www.sports.com/football/
http://www.sports.com/basketball/

To handle this case, you would configure the URL management system to associate the request with a site based on the context root, so that a request whose URL includes /football/ in the path would be associated with the football site.

The advantage of this approach is that it is makes it easy to manage cookies. Because the sites all have the same domain, they automatically share cookies (and thus sessions).

One difficulty with this approach is that an individual Web application (WAR file) can have only one context root. To make it possible for all of these sites to be part of the same Web application, ATG uses a technique called virtual context roots. Using virtual context roots, you map the sites’ context roots (for example., /baseball/, /football/) to the actual context root of the Web application. Even though the virtual context root is not the true context root of the application, it still appears in the browser when a customer accesses the site.

Domain-Based Strategy

In a domain-based strategy, each site has a different domain name, and a request is associated with a site based on the domain name. This strategy is trickier to implement because by default application servers do not share cookies across domains.

There are a couple of variants of this approach, depending on whether the subdomain changes or the parent domain does.

If the subdomain changes, the domain names might be:

http://baseball.sports.com/
http://football.sports.com/
http://basketball.sports.com/

Note that using different subdomains is distinct from redirection. Some merchants use URLs like this but actually redirect to a single domain. For example, baseball.sports.com might redirect to www.sports.com/baseball, and the actual URL management strategy used would be path-based. In contrast, using different subdomains means that baseball.sports.com is the actual domain name, and it is what customers see in their browsers.

If the parent domain changes, the domain names might be:

http://www.baseball.com/
http://www.football.com/
http://www.basketball.com/

In the case where the parent domain is always the same, but the subdomain varies, you can configure your application server to use cookies that specify only the parent domain. For the case where the parent domain changes, the ATG platform provides a mechanism called session recovery. (You can also use session recovery if only the subdomain changes, but you do not want the application server to use cookies that specify only the parent domain.) Session recovery uses a special cookie-tracking mechanism to allow all of your sites to share a single session.

Sticky Site Parameters

The URL management system also provides a third mechanism, sticky site parameters, in which the site is specified explicitly through a query parameter, and the value persists throughout the session (or until it is explicitly overridden). This mechanism is primarily intended to be used in development and preview environments to override the site selection made through one of the other two mechanisms. In production environments, this mechanism should be disabled.