三、业务建模
现在我们来描述一下如何根据业务进行扩展站点技术建模，以及WebSphere Commerce中用来实现这样业务模型的方法论，从而来实现这样的运行在单一基础平台上的大型定制作化站点实施。下面我们循序渐进的来分析如何进行业务建模：
1、商店
银行发生业务交易是它定义自身为一个金融服务提供商，在WebSphere Commerce里，我们将这个业务环境定义在“网上商店”，显然，既然叫作商店，那么业务模式是从零售业务模式中引导出来的，即购物者在卖方运营的商店里购买产品或者服务，最基本业务元素是商店有一个可供交互的空间，然后才能进行交易。
1.1 基本的商店建模
那么要建立WebSphere Commerce的多店业务模式，第一步就是先要决定商店所要表现的内容。安装好的WebSphere Commerce 可能只包含一个单一商店模型，如果这个商店已经能够满足业务需要。但是通常，WebSphere Commerce实例可以通过扩展站点创建出上百个，甚至上千个不同的商店，并支持不同的业务模型。
通常，建一个商店来满足有着共同的展现层需求、公共目录以及共同针对的市场营销活动。从另外一方面来说，如果一个客户，或者说一个客户集，与其他客户有着一些区别，如需要一些独特的业务逻辑，或者需要设计独特的业务数据模型，如产品目录，价格和库存，因此说明需要一个单独的商店来满足这些客户的需求。
如我们上面描述的，成功管理大型多站点实例的关键在于卖方通过管理单一IT基础架构，让整个企业组织分别去管理整个多站点的运维的能力。其中每个站点都只要选择一些所必须的业务资产进行管理，而不是单纯复制站点。例如，每个站点都需要从整个产品目录过滤出来再进行展示给终端购物者。另外，每个站点可能需要增加一些特定产品。同样，每个站点也需要能力来决定是否整体市场活动是否在自己的站点显示出来，也只在自己的站点上建立自己的区域市场营销活动。
刚才提到的这个WebSphere Commerce用来共享数据资产就称为store Path，下面这张图就是来阐述这个概念：
Figure 1 –目录共享
在这个例子中，通过扩展站点（extended sites）机制创建了针对个人客户（B2C）和企业客户（B2B）2个商店，这2个站点所销售的产品都是从主目录（Master Catalog）里过滤出来的。
为了能够共享产品目录，必须先创建一个“样本商店”。“样本商店”是不公开的站点，但是却管理维护着最全的电子商务数据。在这种情况下，样本商店拥有着catalog，而扩建出来的站点自身并不需要去创建自身的目录数据，取而带之的是用store path来指向样本商店来获得产品目录数据。这样看起来象每个商店都有自己的数据，而实际上每个站点都是从asset store继承下来的。除了目录，在其他方面，如展现层，市场活动，创建出来的商店都可以有自己的特性和共性。
1.3 混合扩展方式
刚才介绍了目录的扩展方式，那么除了目录，其他的业务资产也可以通过类似的store path方式进行扩展。WebSphere Commerce在其他业务资产上也提供了相同的机制进行共享，如下图：
Figure 2 – 展现层和目录层的扩展路径（ store paths）
在图2中，卖方需要创建2个教育行业的网店和2个政府行业的商店。这4个店都共享着相同的目录数据，但是不同行业的site有不同的展现要求，比如他们有着不同的结帐要求，页面风格上，产品显示上也有不同的需求。为了满足这样的业务要求，卖方管理员创建了一个展现层样本商店，它包含了页面（JSP）到后台的业务调用。
通过上图，我们可以看到卖方只要管理一个目录资产，而管理2个展现逻辑，分别一一对应不同的行业，从而创建出四个网上商店（2个是针对教育行业，2个是针对政府行业），而四个商店又可以分别创建自己的市场活动，配送和支付模式。
1.4 其他可以共享的扩展路径（store path）方式
到这里，我们已经分析了产品目录和展现逻辑是可以通过asset store进行共享的方式实现。其实其他的一些业务资产也可以通过这个机智来实现。比如，向上销售和交叉销售，市场活动，合同，业务规则都可以通过store path进行共享。其灵活性在于可以为不同的业务资产属性去创建一些自己的asset store，再通过store path进行建站。因此，资源就可以根据业务需要从混合的样本站点中进行继承，比如，通常一个卖方会创建一个产品目录的样本站点，这个在线站点是给所有的在线商店共享的。另外，会创建一系列展现层的的asset store，包含展现信息和营销活动。通过这种配置，很小数量的样本商店（asset store）就可以作为的模版来创建出一个大型多站点的配置。
1.5 扩展的资产共享
Store path的功能不仅仅在于共享数据资产，也具备部分数据共享的能力。回到图2，我们可以看到K-12这个商店只需要销售他维护产品目录中的一个子集，也许其中有些产品或者目录并没有应用到这个分类里。实际上，每个扩展出来的在线商店需要应用不同的过滤器，因此只有与这个过滤后出来的产品才能够出现在web上进行销售。另外，当主目录为所有的产品都定义了基本价格后，每个客户商店还可以进行自己的调整，在有的情况下还允许重置价格。
WebSphere Commerce提供了目录过滤器实现上述功能，它提供了业务规则来对每个商店规定store path，下面是具体的例子：
图3-主目录
图3显示的是通过工具来对主目录进行管理，图中有四个较高级的产品目录，下一张图显示不同的商店用不同的产品目录
图4-目录过滤器在主目录的基础上定义了2个不同商店的目录结构
图4显示了通过两个目录过滤器来创建两个常识点的产品目录。第一个商店不包括woodworking产品，另外一个店不包括drills和其相关产品。
通过上面的例子，我们可以通过单个控制后台去管理完整的产品目录，同时可以为每个商店创建供在线销售的目录子集，并可以根据需要进行价格的调整，调高或者调底，或者制定一个全新的价格。
虽然上面例子考虑的是一个简单也小的产品目录管理，但是从中反映了WebSphere Commerce提供的底层机制通过实践已经证明能够满足大量产品管理和站点扩展功能。
产品的store path允许卖方不仅仅是定义产品子集并做价格调整，还可以为扩展出来的这个商店去创建一些特定的数据。因此，举例来说，一个针对大客户定制出来的站点，包含着卖给特定这个大客户的产品目录，因为这些产品，以及其组合被放在这个商店里，其他用户则访问不到。但是这个大客户商店里则可以看到通过主目录被过滤器过滤出来的商品以及这个商店所特有的一些产品。
