引言

在定义多商店的 WebSphere Commerce 部署时，需要考虑许多相关事项。WebSphere Commerce 平台可以实现许多资产的跨商店共享，并且通过选择适当的布局可以最佳地利用这些可重用的资产。本文使用案例研究的方法说明在设计多商店部署时要注意的典型事项。侧重讨论使用资产商店、角色、策略组、契约、买方和卖方组织结构的商店布局。

案例研究：TiresAmericas 的自定义模型

TiresAmericas 在北美和拉丁美洲经营着为数不多的传统商店。为了使业务可以在全球开展，他们决定启动在线销售，最初的目标是他们当前拥有商店的国家。这些国家是美国、加拿大和智利。在不久的将来，他们还打算将业务扩展到拉丁美洲的其他国家，不过在这些国家他们希望以在线销售作为开端。观看了 WebSphere Commerce V5.6.x 附带的示例业务模型的演示后，他们确信此产品具备他们需要的所有功能。

下面是 TiresAmericas 对商店布局、目录设置和授权的要求：

• 为了更好地满足其客户的不同文化要求，他们让墨西哥的 Web 设计公司构建西班牙语商店的页面，同时，让美国的 Web 设计公司构建英语商店的页面。分析显示，北美客户和拉丁美洲的客户有不同的消费习惯。例如，北美客户注重品牌，而拉丁美洲的客户则不是。因此，TiresAmericas 打算将不同用户体验反映到上述两个组中。
• 尽管许多商店页面可以在同一文化区域中的所有商店之间共享，但是有些页面对于每个商店而言都是独有的，如商店主页。
• 商店目录在这三个商店之间共享，并且他们期望保持这一方式。但是，拉丁美洲的商店不销售冬用轮胎。类似地，个别国家的商店可能不销售某个特定产品类别或某个产品。
• 对于 TiresAmericas 产品系列有一个主价格表。但是，可以为某个区域、个别国家和个别客户设置产品类别和产品折扣。
• 只允许注册的用户购买智利商店的商品。在其他商店，同时允许来宾和注册用户购物。
• TiresAmericas 可以对客户直销，并且可以向自助商店销售，以便对客户进行离线零售。这些自助商店有资格实行特殊的零售价格。

以下各部分概述 WebSphere Commerce 5.6 中可以满足上述需求的一些功能。还附带介绍了一些最佳实践。

给出组织、商店、授权和契约之间的关系之后，建议您以迭代的方式设计这些部分。首先确定您需要立即或在将来部署多少个商店，按照商店部分的指导原则将其布局在组织结构上。划定对这些商店的授权范围，根据需要，按下面授权部分中的指导原则重新调整组织结构。其次，确定需要为各个商店建立的契约，并按照组织契约以执行业务规则中的建议对组织布局进行适当调整。最后，重复这一过程，确保在每一步所做的更改不会导致出现不想要的组织布局。

安排隔离内容的商店

每当需要为一组客户提供不同的配置或体验时，您可以随时使用 WebSphere Commerce 商店。您可以为每个品牌和不同的地理区域提供单独的商店，在某些情况下，还可以为您的每个大客户提供自定义的购物体验。

共有两种商店类型：面向客户的商店和资产商店。面向客户的商店是客户可以直接访问的商店。资产商店向其他商店提供共享资源。面向客户的商店可以包含它的所有构件，或利用资产商店的一些构件。

WebSphere Commerce 基础结构是这样设计的：绝大多数商店所需的内容可以重用，但是，它还允许建立变化点，以支持独特的需求。例如，不同地理区域的商店可以销售不同分类的产品。但是，当分类重叠时，不需要重定义产品库存单位（Store Keeping Units，SKU）。而是提供了共享主目录的概念，并且每个商店可以通过筛选主目录来提供各自的分类产品。通过利用资产商店概念（作用相当于一个容器商店），可以将诸如目录、契约，甚至显示构件（如 JSP）之类的共享资产在商店之间共享。

在组织的层次结构中，一个组织拥有每个商店。根本原因是，这可以与 WebSphere Commerce 访问控制模型中的商店联系起来。当用户在拥有商店的组织（或其祖先之一）中扮演一个角色时，那么该用户就扮演了该商店的角色。例如，如果用户在商店扮演“客户服务代表 (Customer Service Representative)”的角色，则该用户可以登录此商店上下文下的工具，并可以查看此商店的任何用户/事务。决定商店布局之后，务必考虑要支持的商店（包括资产商店）的数量和特性以及策划包含商店的组织结构。

如上所述，TiresAmericas 计划用两种语言部署三个明显不同的店面。他们打算在以后进行扩展，并希望尽可能多地重用其店面内容。基于上述考虑，TiresAmericas 决定部署三个根据地域按层次结构排列的 B2B 商店，并通过资产商店共享目录内容和支持的每种表示语言。这些资产商店如图 1 所示。

三个面向 TiresAmericas 客户的商店中的每个商店都创建在“Tire Retailers”组织之下。上述三个商店还共享同一个目录，但每个商店都建立了契约，以便筛选目录，仅保留该商店销售的产品。用于显示内容的区域特定的 JSP 存储在两个资产商店（西班牙语资产商店和英语资产商店）中。分别由智利和美国/加拿大商店使用。

站点提供的所有目录和产品在一个目录资产商店中进行了定义。面向客户的商店只需定义与目录资产商店的“目录”商店关系，就可以共享其资源。面向客户的商店中的契约允许您进一步修改该商店中所售的产品和价格。

最佳实践：让商店、资产商店和买方的组织构成条理清晰的树形分支。因为组织结构是站点体系结构的基本要素，决不会移动或删除组织。例如，商店和客户组织之间的联结应通过角色和契约完成，而不是通过组织层次结构完成。

最佳实践：在组织层次结构的叶节点创建商店。这会将每个商店放在树的不同分枝上。此最佳实践的基本原理是，如果两个商店在同一个分枝上，则将角色分配到较高一级商店中的用户而不继承较低一级商店中的角色是不可能的。如果两个商店在逻辑上相关联（如上面的示例，商店通过地域相关联），则可以引入一个中间节点，但是，要保持商店为叶节点。

布局角色和策略组以控制授权

角色

WebSphere Commerce 应用程序的授权模型有三个主要概念：用户、操作和资源。用户是使用该系统的人。资源是应用程序中（或由应用程序）维护的实体。操作是用户对资源执行的活动。访问控制是电子商务应用程序的组件，它可以决定给定的用户是否可以对给定资源执行给定操作。

WebSphere Commerce 访问控制框架使用访问控制策略来决定是否允许给定用户对给定资源执行给定操作。WebSphere Commerce 访问控制策略都是4 元组的，形式如下：

            AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]
            

只要用户满足关系或关系组中指定的条件，4 元组访问控制策略中的元素指定，允许属于特定用户组的用户对属于特定资源组的资源执行特定操作组中的操作。

在用户组中包括用户的大多数条件都基于用户担当的特定角色。例如，存在这样一个访问控制策略，其允许担当客户服务代表角色的所有用户执行客户管理操作。那么，MBRROLE 表中被分配客户服务管理 (Customer Service Manager) 角色的任何用户都将隐式包括在用户组中。

用户在组织中扮演角色。您可以设计访问控制策略，以便根据用户在特定组织中的角色对其进行授权。另外，还可以设计策略来反映商店的祖先组织分枝上的角色。如果正在访问商店中的资源，并且该资源的策略指示用户必须具有注册客户 (Registered Customer) 角色，则您可以对该策略进行设计，以反映组织祖先分枝上的任何注册客户角色。

TiresAmericas 可以对所有三个商店中的客户直销。注册后，便在缺省组织 (Default Organization) 中创建 B2C 购物者，并授予其注册客户角色，该角色允许他们在一个或多个商店购物。

尽管将这三个商店发布到了同一站点，但是通过使用商店级注册功能（WebSphere Commerce 5.5 版以后的功能），购物者只能注册为在其中一个商店购物。当购物者向三个商店之一注册时，仅在该商店中给予其注册客户角色。如果同一客户需要在多个商店购物，则必须为每个商店创建一个新的用户配置文件。通过此方式，每个商店都充当一个自主单位。请参阅href="http://www.ibm.com/developerworks/websphere/library/techarticles/0307_mckegney/mckegney.html?S_TACT=105AGX52&S_CMP=cn-a-wes">WebSphere Commerce 5.5 中商店级注册，了解关于商店级注册的详细信息。

最佳实践：尽管可以在一个组织下创建所有三个商店，但定义符合您业务需求的分层组织结构也大有好处。在本实例中，我们会了解到让一个购物者同时注册加拿大和美国两个商店（而不是智利商店）是比较理想的。同样，在管理方面，将管理员权限授予一个区域内的所有商店也是比较理想的。

最佳实践：避免将非管理角色（如注册客户角色）分配给根节点。将用户角色分配（如注册客户角色）给根组织 (Root Organization)，会授予这些角色在站点上任何商店购物的能力。这将限制您根据品牌或地理等因素隔离客户对商店访问的能力。

策略组

自 WebSphere Commerce 5.5 起，访问控制基础结构得到了增强，提供了策略组订阅功能。可以根据业务和访问控制要求将策略归入策略组中。例如，一个策略组具有支持契约所需的策略，而另一个策略组仅允许注册用户购物。根据组织的业务和访问控制要求，组织可以显式订阅适当的策略组。当组织订阅策略组时，只有这些策略组中的策略应用于该组织的资源。其祖先组织的策略不适用。不过，如果组织没有显式订阅策略组，则它可以继承订阅策略组的最近祖先的策略订阅。

图 3 显示了该系统中可用的策略组。它们通过顶部具有标签的圆柱进行了说明。显示的四个策略组根据箭头所示归“根组织”拥有。创建 WebSphere Commerce 实例后，可以将它们引导到系统中。每个策略组简要说明如下：

• B2C 策略组：此组包含不在通用购物策略组 (Common Shopping Policy Group) 中的预加载 WebSphere Commerce 命令的策略。这些策略仅适用于面向客户的商店，如定义并允许来宾购物。
• B2B策略组：此组包含不在通用购物策略组中的预加载 WebSphere Commerce 命令的策略。此策略仅适用于面向业务的商店，如定义并允许契约命令的执行。此组中的策略仅允许注册客户执行这些命令。
• 管理策略组：该组允许管理员管理商店。
• 公共购物策略组：该组允许执行预加载 WebSphere Commerce 命令。这些命令是目录、订购和支付命令，它们对面向客户的商店和面向业务的商店都是通用的。此组中的策略仅允许注册客户执行这些命令。

系统中还显示其他两个策略组。当您无法使用系统中引导的现有策略时，这些组包含用于资产商店资源的策略。这两个组是在构建资产商店过程中创建的。例如，如果您在西班牙语商店中添加一个名为 SpanishCategoryDisplay 的新命令，则需要创建西班牙语策略组，并添加策略，以允许对此新命令进行访问。在图 6 中，有一个用于英语资产商店的策略组，称为“英语策略组”，另一个策略组用于西班牙语资产商店，称为“西班牙语策略组”。

图 3 显示了策略组的订阅，在其应用的组织附近放置了相应策略组的标签。下面我们将说明如何满足先前在案例研究中给出的授权要求。您不能在资产商店中购物。可以通过继承在“根组织”订阅的“管理策略组”完成此任务。

对于英语商店，您可以通过订阅上述四个引导策略组和英语策略组来实现来宾和注册购物。注意，您必须重新订阅“管理策略组”，因为一旦组织订阅了策略组，它就不再继承来自其祖先的任何相同策略组。

对于智利商店，通过订阅三个引导策略组并忽略允许来宾购物的 B2C 策略组，可以实现仅注册用户购物。您还可以订阅西班牙语策略组，以执行来自西班牙语资产铺店的可用资源。

最佳实践：为您部署中的每个资产商店创建唯一策略组。这样可以方便地设置对具有资产商店路径的面向客户商店的访问，因为要显示面向客户的商店，只需订阅其利用的资产商店的相应策略组即可。

组织契约以执行业务规则

我们将使用契约来满足基于契约的定价要求。了解详细信息之前，我们先回头看一下契约的模式，以便理解涉及的业务对象。

契约定义了客户在商业站点购物时所遵循的条款和条件。这些条款可以改变客户的购物体验，包括客户可以购买产品的种类、需要支付的价格以及可以使用的运输和支付方式。为使客户能够在商店中访问契约，应将契约部署到商店中。

共有两种类型的契约：客户契约和基础契约。客户契约的参与者是组织和买方。组织的所有成员都有资格按照契约进行购物。

基础契约用于包含许多客户可以共享的一组条款和条件。任何客户都没有直接使用基础契约的权力。仅当客户契约之一引用基础契约时，才允许客户使用基础契约中的条款和条件。使用基础契约可以更有效地使用商业系统中的数据，并且需要的管理工作也较少。基础契约可以包含任何契约条款和条件，但通常有目录筛选条款和条件，它定义销售哪些产品和销售价格是多少。客户有资格购买客户契约中的条款和条件指定的产品，以及客户契约引用的基础契约指定的条款和条件所指定的产品。类似地，客户将获得客户契约和基础契约中条款定义的最优价格。

客户契约和基础契约都包含在业务帐户中。业务帐户与一个组织相关联。对于客户契约，该组织是买方的顶级组织，业务帐户包含适用于所有买方契约的条款和条件。对于基础契约，该组织仅为没有买方的持有组织。业务帐户允许将相关的基础契约组合在一起，且不包含任何条款和条件。

要管理 WebSphere Commerce Accelerator 中的基础契约，您需要创建一个基础契约组织和一个关联帐户。客户与此基础契约组织没有关联。基础契约帐户仅用作管理基础契约的进入点，这可以保持基础契约和客户契约之间的契约模型一致（组织和业务帐户关联，并且帐户都有契约）。建议契约层次结构中的每个级别都有一个关联的基础契约组织和帐户。这将允许层次结构的一个级别中的基础契约能够引用不同级别的契约。

在使用商店创建向导 (Store Creation Wizard) 创建扩展站点时，将为商店创建一个基础契约帐户，并且该帐户包含基础契约。此基础契约称为“缺省契约的商店名称基础契约 (Storename Base for Default Contract)”。此契约包含适用于该商店的定价和产品条款和条件。商店的缺省契约会引用“缺省契约的商店名称基础契约 (Storename Base for Default Contract)”。这允许您在一个契约中应用适用于商店中所有客户（包括来宾购物者）的任何条款。例如，如果您的商店不销售共享目录中的某些种类，则可以将它们从缺省契约的基础契约中排除。您可以设置适用于此契约中所有客户的任何定价。商店中的所有契约可以直接或间接地引用缺省契约的基础契约。

图 4 显示了美国商店契约模型的一个示例。B2B 客户每人在商店中都有自已的业务帐户。为这些客户创建契约时，该契约会引用缺省契约的基础契约，来共享适用于所有客户的条款。商店中的来宾客户有资格按照美国商店缺省契约购物，该契约也引用缺省契约的基础契约，来共享适用于所有客户的条款。美国商店缺省契约的基础契约将包含目录筛选条款和条件，可以从主目录中排除不销售的任何产品，并提供适用于整个美国商店的产品种类和产品的首选定价。每个客户的契约还包含进一步排除不销售的任何产品的目录筛选条款和条件，并提供适用于客户的产品种类和产品的任何首选定价。

对于 TiresAmerica，在公司和地区级指定了定价和产品权限。为支持此功能，基础契约包含公司和地区条款，并且这些基础契约可以跨多个商店共享。要跨商店共享契约，需要在共享资产商店中创建契约，如图 5 所示。通常情况下，共享资产商店是一个店面资产商店。不过，对于 TiresAmerica，存在两个店面资产商店，因此可以在一个位置创建一个契约资产商店来管理所有基础契约。这允许与契约资产商店具有“com.ibm.commerce.contract”商店路径关系的任何扩展站点商店共享契约。

对于基础契约层次结构中的每个层级，创建一个相应的基础契约组织和业务帐户。业务帐户将包含该级别的适用基础契约。公共帐户将拥有一个基础契约，该契约包含适用于整个公司的定价和产品条款。区域帐户将包含一个适用于北美和拉丁美洲的基础契约，二者将引用公共基础契约。而每个国家商店中的缺省契约的基础契约又将引用合适的地区基础契约。这样，对于购物者，他们有权利使用其客户契约或商店缺省契约、该国家的缺省契约的基础契约、区域契约和公共公司契约的条款和条件。

对于 TiresAmerica，不在拉丁美洲销售冬用轮胎，所以拉丁美洲基础契约将在目录筛选中排除冬用轮胎类别。

让我们考虑这样一位客户，该客户属于 SunnyTire 组织，并且在智利商店购物。Sunny Tire 组织的成员有资格使用一个契约（即 SunnyTire 契约）购物。不过，适用于 Sunny Tire 契约的条款和条件将是 SunnyTire 契约、智利的缺省契约的基础契约、拉丁美洲基础契约以及公共产品和定价基础契约的条款组合。拉丁美洲基础契约排除销售冬用轮胎。排除条款优先于任何包括条款，所以客户不能购买冬用轮胎。客户希望购买 SKU abc-123 各个季节的轮胎。提供的轮胎价格是客户契约和三个基础契约定义的最优价格。

要使用 Commerce Accelerator 创建基础契约帐户，您必须将基础契约组织标识为业务实体（可以拥有业务帐户的组织实体）。如果商店具有 RegisteredCustomers 成员组，则基础契约组织必须是组的成员。如果商店没有 RegisteredCustomers 成员组，则基础契约组织必须有 BusinessEntity 成员属性标记。会给使用组织管理控制台创建的任何组织及其父组织为根组织的组织分配业务实体标记。或者，您可以修改 MemberRegistrationAttributes.xml 中的 <BusinessEntities> 元素，以便将 BusinessEntity 标记分配给基于其父组织的其他组织。当创建业务帐时，请选择“This account is to be used for base contracts（此帐户将用于基础契约）”复选框。

OrganizationSetInSession 在会话中设置活动的组织。以前，用户只能有一个活动帐户（其父组织）。在许多实例中，用户有资格代表多个组织进行购物。现在已将定义组织购物的功能添加为会话管理的一部分。契约的有效集合（及相应的目录筛选和定价）将以活动组织为基础，具体取决于活动组织。ContractSetInSession 通过在客户的会话中只允许使用客户有权使用的契约的子集，可以限制用户能够使用的契约。这两种功能都支持站点的要求和合适的契约模型的设计。但是，对这些功能进行详细介绍超出了本文讨论的范围。

最佳实践：提供的示例显示了花时间充分理解该站点的产品和定价要求的重要性。理解这些要求有助于创建共享基础契约和客户契约的适当契约层次结构。将公共条款和条件放置到基础契约中。如果这些条款可以跨商店共享，则将基础契放到资产商店中。

LDAP/SSO 注意事项

WebSphere Commerce 中的组织用于定义站点的框架，可以作为商店、资产商店、买方和卖方的容器。布局组织结构时的一个重要注意事项为是否需要 LDAP 集成。WebSphere Commerce 支持 LDAP 作为客户身份验证和概要信息的主存储库，并且是利用单点登录功能和提供的其他即装即用 WebSphere 应用程序的先决条件。现在，LDAP 的含义是用户和组织数据的主存储库，这是指在 WebSphere Commerce 中定义的组织结构必须存在于您的 LDAP 服务器中。这通常意味着可以使用所需的 WebSphere Commerce 布局协调现有的 LDAP 组织树，并添加 WebSphere Commerce 特定资源的新分枝。如果 LDAP 集成是您站点所需的内容，那么在设计 WebSphere Commerce 组织结构时应考虑所需的 LDAP 结构。WebSphere Commerce 联机帮助提供了关于 LDAP 集成的详细信息。

图 7 显示了为 TiresAmericas 生成的组织结构。如果需要 LDAP 集成，那么这些组织中的每个组织都需要存在于 LDAP 服务器中（预填充或由 WebSphere Commerce 动态创建）。

结束语

WebSphere Commerce 中的组织结构非常值得关注，它影响设计站点时所做的许多决定。本文介绍了布局站点时的重要考虑事项，包括支持有效多商店部署的许多最佳实践。本文还概述了商店、契约、策略组和 LDAP 的概念。案例研究使用最佳实践实现的具体示例说明了这些概念的关联情况。