零售示例应用程序

[http://msdn.microsoft.com/zh-cn/library/aa905316.aspx]

摘要：不断变化的市场条件要求业务应用程序有灵敏性。面向服务通过将重点放在 XML 和 Web 服务标准（这些标准从根本上改变了开发人员设计系统并将它们集成到分布式网络上的方式）上来应对这项挑战。

本页内容

简介
示例应用程序的目标
情景和组件
零售标准
组件的交互
信息流
技术决策
结束语

简介

零售商面临着全球化、管理法规、不断增加的成本以及挑剔的客户所带来的巨大挑战。除了这些不断变化的市场条件外，现在还有多种接触到客户的渠道。所有这些都对业务应用程序的灵活性和灵敏性提高了要求。但是，在竞争热衷于灵敏性和适应性之类的口号的时代，企业却面对着看上去是由钢材水泥构建的系统，并且当初开发系统时的想法就好像事物永远不会改变。每次组织为适应新的业务需要调整这些系统时，它们就变得更加昂贵和麻烦。不幸的是，这导致了更少的自动化实现，因为系统需要不断的人为干预与 IT 开发。调整技术以适应业务目标的方案时常会陷入集成问题的困境而停留在计划阶段。

零售商时常面临的一项巨大挑战是：需要在适当的时间、适当的地点获得正确的信息 — 例如，向商店经理、区域经理和公司总部的采购经理提供几乎是实时的销售信息。另一项挑战是向销售代理提供产品信息。要使信息几乎实时可用，就需要能够生成几乎是实时的数据、将数据发送到正确的地点以及几乎是实时使用数据的系统。

面向服务通过将重点放在快速发展的 XML 和 Web 服务标准（这些标准正在从根本上改变开发人员设计系统并将它们集成到分布式网络上的方式）上来应对这项挑战。开发人员不再被迫去设法应付呆板、专用的语言和对象模型，而这在面向服务出现之前是常有的事。该新方法的出现尤其在基于 Web 的分布式计算方面有助于人们找到新的途径。这项革命正通过集成完全不同的系统来进行业务转型以建立实时企业。

若要使信息可用于简化商品销售流程，将需要有一种基于各种商店内应用程序和后端应用程序之间松散耦合集成的方法。这种需求使得基于面向服务的体系结构（目的是实现不同应用程序之间的集成）成了解决问题的关键。

通过选择零售过程中的几种常见情景（例如缺货、预防损失的措施、客户服务和库存生产力）以展示这种使用面向服务的集成，最终形成了本白皮书与其中提供的示例应用程序。本白皮书探讨了应用程序与应用程序的实时连接。数据作为业务事件而不是批序列从商店传送到企业。数据以行业标准 IXRetail 格式在商店和业务 (LOB) 应用程序之间传送。

本白皮书还说明了通过面向服务达到灵活性和集成的最佳途径。最后，还提供了一个示例应用程序供读者下载，该应用程序使用几种所选的情景示范了该途径。

返回页首

示例应用程序的目标

本白皮书的主要目标是论证以下内容：

• 使用 Web 服务集成不同的应用程序。

• 使用行业标准实现互操作性。

• 使用 Microsoft 平台方便地构建 Web 服务。

• Microsoft BizTalk Server (BTS) 2006 的转换和编排功能。

• 使用 Microsoft Business Scorecard Manager (SCM) 方便地构建管理人员工作台和仪表盘。

构建示例应用程序

为说明使用面向服务的架构使该方案自动化，我使用 IXRetail 零售企业行业标准、BizTalk、Windows Communication Foundation (WCF) 和 SCM 构建了一个示例应用程序。方法如下：

1. 构建一个基于 Visual C# 的示例服务点 (POS) 应用程序。

2. 使用 IXRetail 架构设计 Web 服务接口定义。

3. 构建一个示例 BizTalk 后端 IXRetail 适配器。

4. 使用触发基于警报和事件的工作流的 WCF 构建一个示例 Web 服务。

5. 构建一个与后端 Web 服务交互的示例供应商服务。

6. 将该应用程序打包到一组 Web 服务、Windows 应用程序、元数据（配置、架构定义）和一组应用程序。

零售商如何能从中受益？

此示例应用程序证明了零售商可获得的许多益处。该示例应用程序有益于构建实时连接的零售解决方案的一些关键特征是示例应用程序：

• 示范了使用标准创建可扩展的解决方案。

• 是松散耦合成的，以提供灵活性、适应性和可调整性等益处。

• 是使用预打包技术构建的，而不是从头开始创建的。

使用标准、松耦合以及使用现有技术有助于零售商逐渐改进而转向此解决方案，而不是“打破并更换”现有解决方案。这些特征也有助于选择“最佳品种”，而不是局限在某个具体供应商的解决方案。最后，它们还使得企业能够在市场条件变化时扩展解决方案。

返回页首

情景和组件

本节详细介绍了构建一个集成零售程序的参考体系结构。如前几节所述，零售商面临着集成其商店和企业（或公司）总部的传统系统时带来的挑战。由于客户希望从商店和其他渠道都能获得丰富体验的要求越来越高，这项挑战变得甚至更加关键。

为了实现接近实时的数据可用性和收获相当于实时数据的果实，让我们首先来了解一下零售价值链。

图 1. 零售价值链

单击查看大图像

在零售价值链中，销售数据和客户数据从商店流向企业系统。根据预测、库存量和销售数据，企业系统从供应商处订购新产品和商品。供应商通过其仓库履行订单并同时在仓库中的库存低于某个阈值时向制造商下订单。

要使所有这些功能顺畅地工作并避免客户经历缺货的情况，零售商需要一个灵活、可适应和经调整的流程。这样就减少了成本和低效，同时确保了无缝的客户体验。如果此流程的建立未能获得灵活性、适应性和可调整的益处，零售组织将注定要经历前文讨论的痛处。

此示例应用程序定位的目标零售情景

零售中有许多场合和用例。但是，为了说明该技术的功能，我们只选择了几个常见的情景：

• 找不到商品：这是零售环境中发生的常见情形。对于这种情形，在某种商品通过促销系统推出且定价信息传送到商店之前，该商品就已运到商店并上架。客户挑选了该商品并走向收银台。当扫描该商品时，不能结帐，因为找不到该商品。当前，这会导致许多的手动处理步骤，例如主管被呼叫且不得不走到结帐通道，从收银员那儿拿起商品，然后在商店中四处走动，尝试通过查找类似商品的价格找到定价。找到类似商品的价格后，经理在 POS 上手动改写价格以便能实现交易。

• 商品召回：对于这种情形，供应商通常向公司总部发送一条消息以召回某种商品。商品经理使用商品召回信息更新商品管理系统并向商店发出这一消息。每家商店的反应取决于商店经理处理该消息并从货架上撤除召回商品所花费的时间。示例应用程序示范了通过使用最新技术（具体地说，即 Web 服务）如何能够完全自动化处理此情形。

• 商品缺货：这是零售行业非常常见的一种情形。对于这种情形，某位客户正在寻找一件商品，他在货架上没找到，便询问商店员工，该员工告诉客户这种商品缺货 — 但事实上，该商品正放在库房中呢。发生这样的问题是由于商店库存缺乏实时可见性。示例应用程序示范了该最新技术如何能克服这个问题并提供更佳的客户体验。

• 实时促销商品销售数据传送：通常，销售数据将每夜或一天分两次传送到企业系统。这并不能为商品管理人员提供充分的库存水平（特别是促销商品的库存水平）可见性。因此，示例应用程序示范了将交易信息从商店实时传输到企业系统。同时还示范了某些业务规则在实时传输销售交易信息过程中的应用。例如，与高价商品和促销商品相关的销售信息以最高的优先级实时传送，其他交易数据则以第二优先级实时传送。托管在本地主机上的服务从多台 POS 设备收集同时发生的销售数据更新信息，将之汇总、转换，然后根据公司总部设置的规则传送数据。

• 供应链：通常，将一笔交易输入 POS 系统时，要到当天晚些时候或次日才能将它传到企业系统中。从库存和销售来看，这样会降低企业系统人员和执行人员掌握商店情况的可见性。该连接的系统示例应用程序展示了从商店开始，经过采购系统、仓库系统，并最后回到商店的供应链周期的完整集成。当一笔交易输入 POS 时，该交易将流入商店级库存函数并更新商店现有的数据。在现有商品数量落至某个最小阈值以下时，它将触发向仓库管理应用程序立即订货。仓库管理系统可能与贸易伙伴交互以满足该订单要求。在订货运送到商店被接收后，该商品的商店库存数量将相应增加。

示例应用程序使用上一种情形说明如何能够将它们完全自动化并提供实时可见性，使员工和执行人员能时刻掌握信息并及时做出决策。

示例应用程序的关键组件

本节提供有助于理解示例应用程序组件的说明。图 2 提供了这些组件如何集成和工作的完整架构视图。此体系结构展示了各种商店和后端应用程序之间的松散耦合集成。这种高级体系结构提供的构成组件可按照业务需要进一步进行扩展或替换，或者可为其他一些纵向行业以类似方式建模之用。

图 2. 架构图

单击查看大图像

销售点 (POS)

示例应用程序有一个 POS 应用程序。此程序被构建成一个 .NET 应用程序（POSSystem，说明与平台无关的与 LOB 应用程序的集成）。该 POS 应用程序可以两种模式进行操作：在线和离线。在线表示存在到商店服务器的连接，离线表示与商店服务器断开连接进行工作。在离线模式下，这些终端在本地平面文件中存储销售交易信息。在在线模式中建立了与商店服务器的连接之后，离线交易信息就会被传送到商店服务器。

在实际商店中，由于失去网络连接或商店服务器发生故障而时常会出现离线情形。但是，在此示例应用程序中，离线和在线模式通过一个配置文件来控制。如下所示，由 POS 解决方案配置文件中的一个参数控制操作模式。

<!--该项为 POS Id，用户可在该项中给出 POS 名称-->
   <add key="POSID" value="101"/>

<!--该项表示应用程序的联机/脱机状态-->
   <add key="Online" value="true"/>

POS 应用程序的名称在 POSID 键中配置，它将与传送到商店的每条通知消息一起传递。如果 Online 键的值为“true”，则表示 POS 连接到了商店服务器。在零售情形中，可能存在多个数据库，而每台 POS 应引用其单独的数据库连接设置。这也可以在 Config.xml 文件中配置，如以下所示。

<add key="ConString" value="Data Source=machinename;
Initial Catalog=Databasename;
User Id=test;Password=test123;/>

在线情形中的每笔交易都会被定向到商店数据库，并且所有交易都在数据库的销售主表和销售明细表中维护。还会在系统级维护一个包含商品主表明细的附加文件，该文件的路径在 Config.xml 文件中配置，如下所示（确保 POS 应用程序有访问此交易文件的权限）。

<!--这是 WCF Web 服务将详细信息写入
稍后将由 POS 应用程序访问的共享位置的路径-->
<add key="FileItemPath" value="//machinename//temp//price.xml"/>

如果将 Online 键的值更改为“false”，则 POS 应用程序将与商店数据库断开连接，并且所有交易将通过前一步骤中创建的商品主表明细 Price.xml 文件来完成。还会在本地驱动器上创建一个附加交易日志文件，其路径也是使用 Config.xml 文件来配置，如下所示。此文件的名称与生成的发票 ID 的名称相同。然后，在 POS 在线或者 POS 的状态从离线变为在线时，这些交易将被合并到商店数据库中。

<!--这是 POS 应用程序在脱机模式下
将事务详细信息写入 xml 文件的路径-->
<add key="FileTransactionPath" value="C:\\"/>

商店数据库或商店 DB（图 2，第 3 项）

商店 DB 维护商店的销售和库存数据。来自所有 POS 应用程序的交易数据都将汇总到商店 DB 以进行本地存储。

POS 应用程序生成的所有通知和 Store Manager 应用程序（在下节说明）也都存储在此数据库中。该数据库的 E-R 图在图 3 中显示。商店 DB 主要包含如下这些表：

• SalesDetails — 此表存储 POS 应用程序售出的每件商品的详细信息。

• SalesMaster — 此表存储订单及小计、税等。

• PoSMaster — 每个 POS 终端的 POS 明细存储在该数据库中。Store Manager 应用程序会引用此表为所有应用程序查找 POS 位置以及广播任何事件。

• Employees — 此表包含商店员工的详细信息。

• ProductDetails — 这是产品主表，列有商店中每个产品的详细信息。

• ItemMaster — 这是商店数据库中包含对应每件商品的交易数据和通知的主表。此表包含表示每件商品的召回状态的 RecallFlag。

• Inventory — 此表包含商店库房或货架上可用商品的库存。只要有商品售出，就会更新此表。

• LocationMaster — 此表存储商店库房和货架的位置详细信息。

• OutOfStockItemHistory — 如果一件商品的库存落到阈值以下，则该商品的交易明细将被推送到此表。

• RecalledItemHistory — 如果 Store Manager 应用程序因各种理由从商店货架召回任何商品，则 ItemMaster 表中该商品的 RecallFlag 将被设置为“true”，并且 RecalledItemHistory 会进入此表。

• UoMMaster — 此表存储 ItemMaster 中每件商品的度量单位详细信息。

• Promotions — 此表包含削价商品或供促销商品的详细信息。

图 3. 商店 DB E-R 图

单击查看大图像

Store Manager 应用程序会引用此数据库进行所有必要的操作。到商店数据库的连接将通过示例应用程序 DataAccess 组件中的 DBManager 类来完成。此解决方案管理到该数据库的所有连接。

Store Manager 应用程序（图 2，第 6 项）

此 .NET 应用程序充当有可能在 Tablet PC 上运行的 Store Manager 应用程序。所有来自 POS 的消息和通知均会被传送到此应用程序。Store Manager 应用程序充当要发送给 store Web 服务或从中接收的所有消息的接口。

Store Manager 应用程序从 POS 应用程序接收通知，并通过商店中运行的 Windows 通信服务 CSTStoreWinService 将其发送回去。此通信是通过 CSTStoreWinService 上配置的 TCP/IP 侦听程序来完成的，该服务的通信 IP（及其侦听时所在的端口）是在 Store Manager 应用程序中配置的。此配置在 App.config 文件中完成，如下所示。

<!-- 托管 Communication Windows Service 的装置的 IP 地址-->
   <add key="CommunicationIP" value="172.28.41.61"/>
<!-- Communication Windows Service 正在侦听装置的端口号-->
   <add key="CommunicationPort" value="8000"/>

Store Manager 应用程序使用此套接字来进行通信。Store Manager 应用程序还会为商店所收到的每个通知（或者来自 POS 应用程序或者来自 Enterprise 应用程序）生成通知 XML 文件。通知文件在 App.config 文件中进行配置，如下所示。

<!--将存储商品召回通知的 XML 文件的名称-->
   <add key="IRCXmlName" value="ircnotify.xml"/>
      
<!--将存储商品缺货通知的 XML 文件的名称-->
   <add key="IOOSSXmlName" value="ioossnotify.xml"/>
      
<!--将存储商品缺货通知的 XML 文件的名称-->
   <add key="IOOSBXmlName" value="ioosbnotify.xml"/>
      
<!--将存储所收到商品装运通知的 XML 文件的名称-->
   <add key="ISHIPMENTXmlName" value="ishipmentnotify.xml"/>

这些通知文件是依照针对所有情况的 IXRetail 架构而创建的。这些通知文件起着通知消息的作用，这些消息由 Store 服务以通知邮件形式传送到库房职员的 PDA 或终端上（对于商品召回的情况），或传送到 Enterprise 应用程序（对于商品未找到的情况）。

在商品未找到的情况下，电子邮件将通过 Store 服务传送到 Enterprise 应用程序，这样，工人便可为商店数据库中缺少的商品设置价格。要发送到企业的电子邮件的配置设置也是在配置文件中定义的，如下所示。

<!-- 总部邮件 ID-->
<add key="headquartersMailID" value="testmail@microsoft.com"/>

电子邮件通过 IIS Server 中所配置的 SMTP 服务器进行发送。相应的配置设置（如 SMTP 服务器名称及端口）也是配置文件的一部分。

<!-- 具有 SMTP 的装置的 IP（通常为 Indigo 装置） -->
   <add key="SMTPIP" value="smtphost"/>

<!-- SMTP 服务正在其上运行的端口-->
   <add key="SMTPPort" value="25"/>

另外，Store 服务的端点地址还可以在 Config.xml 文件中进行配置。

<!-- Indigo Store 服务路径 -->
<add key="EndPointAddress value="http://localhost:2769/StoreService/Service.svc"/>

Store Windows 服务（图 2，第 4 项）

Store Windows 服务 (CSTStoreWinService) 以 Windows 服务形式公开，并通过 POS 发出的通知与 Store Manager 应用程序进行通信。CSTStoreWinService 还负责管理 Store Manager 应用程序与 Store 服务之间的通信，因为 Store Web 服务是在 Windows 服务中托管的。

每当有任何高价值商品或促销商品的销售量超过其库存阈值时，该 Windows 服务均会向 Store Manager 触发所有的通知。向 Store Manager 应用程序传送通知这一过程是通过在 CSTStoreWinService 的配置文件中配置 Store Manager 的地址来完成的。

<!-- 将运行 Manager 应用程序的设备的 IP 地址-->
    <add key="MGR" value="172.28.41.61"/>

CSTStoreWinService 一启动便会搜索销售数据传输业务规则。

Store Web 服务（图 2，第 5 项）

Store Web 服务是作为向 Enterprise 应用程序公开的一项 WCF Web 服务来托管的。Store Manager 应用程序与 Enterprise 应用程序之间的所有通信均通过此 Web 服务进行传送。此 Web 服务的端点在配置文件中进行配置。商店所需的业务逻辑被并入此 Store Web 服务的公共方法。

Store Web 服务通过充当公司总部端接口的 BizTalk 服务与 Enterprise 应用程序进行通信。BizTalk 服务公开了业务规则和销售信息方法。Store Web 服务使用 IXRetail 架构与 BizTalk Web 服务进行通信。它负责执行商店数据到 IXRetail 格式的数据转换。这是通过将 Store 数据库中的数据映射到 BizTalk Web 服务所公开的架构来实现的。稍后将对数据转换进行更加详细地说明。

下面列出了 Store Web 服务的核心功能：

• 数据聚合：对来自 POS 设备的销售数据和交易进行聚合并使用插入 DB 方法将其推送至数据库。数据库连接设置是在 Store Web 服务的 Web.config 文件中完成的，如下所示。

  !-->Db 连接字符串数据源 =<<数据库服务器>> 目录 =<<数据库名称>> -->
  <add key="ConString" value="Data Source=servername;Initial Catalog=db name;Integrated Security=True"/>
  

• 数据转换：Store Web 服务通过将 Store 数据库中的数据映射到 BizTalk Web 服务所公开的架构来执行商店数据到 IXRetail 格式的数据转换。通过“在实时数据更新中应用规则”方案对此进行了演示。

  • 在此示例应用程序中，交易信息从商店实时传送到公司系统；在此过程中，应用了某些业务规则来选择要传送的信息。例如，与高价值商品或促销商品有关的销售信息以最高优先级实时进行传输。其他交易数据将以次优先级进行实时传输。本地主机上托管的服务会从多个 POS 设备收集同时发生的销售数据更新，对其进行聚合、转换，然后根据商店经理或公司系统所设置的规则来传送这些数据。

  • BizTalk 服务根据 IXRetail 格式公开架构，并将其绑定到编排上。这些编排随后将以 Web 服务形式进行公开，而业务方法将作为 Web 服务方法向商店公开。

    [System.Web.Services.WebMethodAttribute()]
            [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://temp
    uri.org/BizTalkWS/PriceNotFound", 
    Use=System.Web.Services.Description.SoapBindingUse.Literal, 
    ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Default)]
    
    [return:System.Xml.Serialization.XmlElementAttribute(Namespace="http://
    BizTalkWS.PriceNotFound", ElementName="PriceNotFound")]
    
    public PriceNotFound 
    PriceNotFound([System.Xml.Serialization.XmlElementAttribute(
    Namespace="http://BizTalkWS.PriceNotFound", 
    ElementName="PriceNotFound")] PriceNotFound part)
    {
    }
    

在上一个 Web 方法中，输入参数应映射到 BizTalk 所公开的 PriceNotFound 架构。在商品未找到的情况下，Store 服务会从 Store DB 中检索数据并将其转换成 BizTalk 所公开的架构对象。因此，该转换是通过将 Store DB 所公开的数据集映射到 PriceNotFound 架构来完成的。

Corporate 或 Enterprise Web 服务（图 2，B 项）

消息、通知和销售数据在商店与公司系统之间的来回传送是通过 Corporate 或 Enterprise Web 服务实现的。Corporate Web 服务以 BizTalk Web 服务形式公开。在商店与公司系统之间发生的数据流使用了数据转换技术。所有的零售业务方案架构均由 BizTalk Web 服务进行公开。根据“零售”方案为每一个方案均创建了架构。然后将这些架构转换成消息，并以编排形式进行公开。BizTalk 所创建的这组编排和接收位置随后以 Web 服务形式进行公开。此 Web 服务是通过 Web 服务“发布向导”发布的。Corporate Web 服务使用存在于 BizTalk Helper 类中的 Config.xml 文件来进行配置。Corporate Web 服务还会将公司端发生的事件记录到日志文件，在配置中提及了该文件的路径。

<category name="Common">
   <setting name="LogFilePath" value="CSSample applicationLog.txt"></setting>
   <setting name="EventSourceName" value="CS Sample application"></setting>
   <setting name="EventSourceLogName" value="CSSample applicationLog"></setting>
</category>

使用在配置文件中配置的电子邮件来向公司系统、采购商、供应商和库房职员发送通知。

<setting name="DBConString" value="Data Source=ibm-indigo;Initial 
Catalog=Test_headquartersDB;Integrated Security=True"></setting>
<setting name="MerchandisersEmail" value="testemail@test.com"></setting>
<setting name="headquartersEmail" value="testemail@test.com"></setting>
<setting name="BusinessRuleFilePath" value="\\ibm-indigo\temp\BusinessRules.xml"></setting>

Supplier 应用程序

Supplier 应用程序以 Web 应用程序形式公开并在公司（或总部）端托管，从而使得总部经理可以从 POS 应用程序中召回商品。Supplier Web 应用程序允许经理输入所要召回商品的详细信息，召回消息将通过 BizTalk Web 服务传送到商店。

图 4. Supplier 应用程序使用此屏幕发送商品召回消息。

单击查看大图像

Corporate 或 Enterprise 数据库（图 2，D 项）

Enterprise DB 在自己一端对销售和库存进行维护，公司应用程序直接连接到该端。BizTalk Web 服务和公司 Web 应用程序所生成或传送的所有通知也存储在该数据库中。公司数据库中主要有以下各表：

• SalesDetails — 此表存储了从 POS 售出的每件商品的详细信息。

• SalesMaster — 此表为存储每次交易后所生成发票的发票主表。

• PoSMaster — 每个 POS 终端的 POS 详细信息均存储在该数据库中。商店经理在广播任何事件时均会在此表中查找所有终端的 POS 位置。

• Employees — 在商店工作的所有员工的详细信息都在此表中进行维护。

• ProductDetails — 这是产品主表，其中列出了 Store 中每个产品的详细信息。

• ItemMaster — 这是 Store 数据库的主表，其中包含与每件商品相对应的交易数据和通知。此表包含 RecallFlag，它指明了每件商品的商品召回状态。

• Inventory — 此表包含商店库房或货架上现有商品的库存。每当有任何商品从 POS 中结帐时，此表都会进行更新。

• LocationMaster — 此表存储商店库房和货架的详细位置信息。

• OutOfStockItemHistory — 如果有任何在 POS 上结算的商品无法在商店获得，且结算量低于库存中的阈值水平，则会将该商品的交易详细信息推送到此表。

• RecalledItemHistory — 如果商店经理由于种种原因从商店货架上召回了任何商品，则会将 ItemMaster 中该商品对应的 RecallFlag 设置为“true”，并将 RecalledItemHistory 置入此表。

• UoMMaster — 此表存储 ItemMaster 中每件商品的度量单位详细信息。

• Promotions — 此表包含正在销售或促销的高价值商品的条目。

Corporate 或 Enterprise Web 应用程序（图 2，E 项）

Enterprise 应用程序以 Web 应用程序形式公开。它在总部端进行托管，负责执行与总部相关的所有操作。此 Web 应用程序支持各种操作，如发送通知、用于进货的采购功能、存货转移、根据商店请求发货以及生成订单。其主要功能如下：

• 编辑商品价格。

• 通过商店端的 WCF 服务将价格变动实时传送到商店。这是使用 UpdateItem 完成的，它会在应用程序启动后显示出来。更新并提交了价格后，即会向商店经理发送电子邮件，并且在 Store Manager 应用程序中会出现通知。

• 通过提供 RecallItem 功能，能够从商店召回商品。在输入了商品 ID 和召回原因并将其发送到 Store Manager 应用程序后，商店中已召回的商品将会被搁置。

• 库存管理功能，用以创建发货请求并将其发送给商店。从下拉列表中选择商店 ID，并为待完成的转移选择要转移的数量。

• 业务规则配置，用以创建从商店实时传送销售信息的业务规则。此信息存储在 SampleBusinessRules.xml 文件中。以下对业务规则设置进行了说明。

• 优先传输频率：

  • 立即

  • 每隔 <text box> 小时

• 标准传输频率：

  • 每隔 <text box> 小时

  • 每天一次（轮班时在 POS 上完成）

• 高价值商品：

  • 将 >= $<text box> 的商品的 UnitPrice 计为高价值

• 保存/取消：

  • 将值保存到一个 XML 文件，其路径从 Web.config 中读取

Store Manager 门户

此 SharePoint 应用程序充当 Tablet PC 或 PDA 应用程序上运行的 Store Manager 应用程序。来自 POS 的所有消息和通知均被传送到此应用程序。该 Store Manager PDA 应用程序充当要发送到 Store Web 服务和从中接收的所有通知的接口。在此应用程序中，Store Manager PDA 通过对数据库进行调用来从 POS 接收通知。

该 Store Manager PDA 应用程序用于编辑商品价格、查看销售数据，以及从“快速链接”启动程序来启动 Windows Store Manger 应用程序。

InfoPath 窗体：每当 PDA 设备或 Tablet PC 上的 Store Manager 收到商品未找到的通知时，都会启动 InfoPath 窗体以编辑商品的价格。InfoPath 窗体在 SharePoint Portal Forms 库中发布。

通知 Web 部件：开发了一个 Web 部件来显示 POS 和 Store Manager 应用程序生成的所有通知。来自 POS 的所有消息和通知均被传送到此应用程序。该 Store Manager PDA 应用程序充当要发送到 Store Web 服务和从中接收的所有消息的接口。

销售数据 Web 部件：在 Business Scorecard Manager 中开发了一个 Web 部件，用以在图示视图中显示每周的销售信息。该数据读取自 Analysis Service CUBE，它负责聚合并处理销售数据。Business Scorecard Manager 用于将销售数据信息发布到 SharePoint Portal Library 上。

图 5. 示例销售数据 Web 部件

单击查看大图像

返回页首

零售标准

零售标准非常重要；它们有助于实现设备（如扫描仪和销售点终端）或应用程序间接口的标准化，并为与设备的交互定义标准。零售标准还确保共享应用程序间的消息采用可预见的格式，这样一来由不同人员开发的应用程序就能够彼此对话。标准对于应用程序开发人员和终端用户都有益。从开发人员的角度来讲，标准降低了系统设计和开发的成本，使应用程序区域内的迁移和特殊化更加容易。从零售商的角度讲，标准允许不同供应商提供的设备和应用程序相互集成、协同工作，从而能够创建更加经济、可自定义的、高级和强大的系统。标准还能使客户自由选择适合其需求的最佳应用程序。

零售标准可对零售团体提供以下益处：

• 更便宜的解决方案。

• 更加丰富的用户体验。

• 提高生产率。

• 降低维护成本。

• 挑选最佳类型的应用程序。

• 基于开放式的与供应商无关的语言（例如 XML），该语言可由任何应用程序生成和使用，无论平台和供应商是什么。标准定义了要交换的数据；XML 提供了开放性的语言来承载数据，以及开放性的传送方法（如 Web 服务）以允许应用程序交换该数据。

• 使客户在不同应用程序间灵活切换的难度降至最低。

零售技术标准协会（Association of Retail Technology Standards (ARTS)）具有称为 IXRetail 的标准，用于 POSLog 和其他与销售相关的交易信息。IXRetail POSLog 描述了 POS 系统用于向零售企业中的其他系统报告活动结果的各种接口。POSLog 包括许多不同种类的交易和事件。IXRetail POSLog 架构由一个单一的 XML 架构组成，后者定义了 POS 可能向另一个系统发送的全部交易和事件的集。

IXRetail 构建于开发标准的 XML 架构和消息集的 ARTS 数据模型之上，以简化零售企业内“应用程序对应用程序”（A-对-A）的集成。示例应用程序解决方案必须符合 ARTS IXRetail 标准 XML 架构，以便在零售企业内连接各个应用程序。用于示例应用程序的架构符合 IXRetail 标准，并且从 ARTS 提供的架构标准集中提取。Store 和 LOB 间的数据流通过使用这些架构来实现。

该引用实现使用与 POSLog 相关的 IXRetail 标准，其中项目被购买和返回。IXRetail POSLog 的示例如下所示。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- 用例：商品从货架购买 -->
<!-- 注：此示例包括所有可选字段 -->
<POSLog
xmlns="http://www.nrf-arts.org/IXRetail/namespace/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace/ POSLog.xsd">
<Transaction CancelFlag="false" OfflineFlag="false" TrainingModeFlag="false">
<RetailStoreID>HighStreet</RetailStoreID>
<RevenueCenterID>6333-1221</RevenueCenterID>
<WorkstationID>POS5</WorkstationID>
<TillID>22</TillID>
<SequenceNumber>4294967295</SequenceNumber>
<BusinessDayDate>2001-08-13</BusinessDayDate>
<BeginDateTime>2001-08-13T09:03:00</BeginDateTime>
<EndDateTime>2001-08-13T09:05:00</EndDateTime>
<OperatorID>John</OperatorID>
<CurrencyCode>USD</CurrencyCode>
<RetailTransaction Version="2.1" OutsideSalesFlag="false">
<ManagerApproval>false</ManagerApproval>
<ReceiptDateTime>2001-08-13T09:04:32</ReceiptDateTime>
  <LineItem VoidFlag="false">
  <SequenceNumber>1</SequenceNumber>
  <BeginDateTime>2001-09-16T09:04:00</BeginDateTime>
  <EndDateTime>2001-09-16T09:04:03</EndDateTime>
    <Sale ItemType="Stock">
    <POSIdentity>
      <POSItemID>01234567890123</POSItemID>
    </POSIdentity>
    <ItemID>CA7865</ItemID>
    <MerchandiseHierarchy Level="Department">Chocolates</MerchandiseHierarchy>
    <ItemNotOnFileFlag>false</ItemNotOnFileFlag>
    <Description>4 盎斯黑巧克力</Description>
    <TaxIncludedInPriceFlag>false</TaxIncludedInPriceFlag>
    <UnitCostPrice>1.23</UnitCostPrice>
    <UnitListPrice>1.79</UnitListPrice>
    <RegularSalesUnitPrice>1.63</RegularSalesUnitPrice>
    <InventoryValuePrice>1.23</InventoryValuePrice>
    <ActualSalesUnitPrice>1.63</ActualSalesUnitPrice>
    <ExtendedAmount>4.89</ExtendedAmount>
    <DiscountAmount>0.00</DiscountAmount>
    <ExtendedDiscountAmount>4.89</ExtendedDiscountAmount>
    <Quantity>3</Quantity>
  </Sale>
</LineItem>
<Total TotalType="TransactionGrossAmount">4.89</Total>
  </RetailTransaction>
</Transaction>
</POSLog>

返回页首

组件的交互

前面的部分介绍了组成示例应用程序的各种组件。此部分将介绍这些组件交互和组合的方式，以在零售中创造灵活而近乎实时的决策体验。

该示例实现包括创建引用体系结构、演示松散耦合益处的示例代码、使用标准完成互操作性和 Microsoft 平台轻松完成该操作的功能。还显示了零售商是如何能够以增量方式，而不是使用剥离更换的方法转入更加实时的决策过程。实现包括使用 WCF 创建与企业系统进行近乎实时通信获取交换消息的 Web 服务。IXRetail 标准用于和企业系统交换数据，BizTalk 的自定义 IXRetail 示例加速器经实现用于与企业系统通信。

此引用实现所选方向实现解决方案的方式是：使用 WCF 和 BizTalk Server、使用 IXRetail 消息类型作为交换和规范消息格式，以及通过 Web 服务线路协议发送消息。

商店端结构体系实现构图

该部分概括介绍了商店端引用架构体系。

图 6. 商店服务交互方式

单击查看大图像

图 6 显示了带有 POS 系统商店的功能视图，一台本地主机或商店服务器、经理工作站和“商店”数据库。POS 系统在本地数据库中存储交易信息，然后从数据库中检索价格信息完成销售交易。该图也显示了 Web 服务，此服务响应存储在数据库中的信息或从企业系统收到的消息。POS 系统完成销售交易时，销售数据由 Web 服务拾取并转换成标准的 IXRetail 格式，然后被传送到公司总部系统。Web 服务基于由商店经理和/或公司总部系统配置的规则，选取销售数据。例如，促销商品销售数据替代非促销商品销售数据被传送到公司总部系统。

在传送到企业系统前，传出消息要经过聚合、转换和压缩的步骤。从商店到企业系统的实时数据传送，有助于在公司总部级作出实时决策。它还有助于监控实时核心绩效指标 (KPI)，并且能够在企业级触发工作流。例如，传送有关商店中库存级别的信息，能够触发从供应商那里订购商品的工作流。

图 7. 来自商店的外发消息

单击查看大图像

同时如图 7 所示，来自 POS 系统的销售数据在传送到企业系统前，经过了聚合、转换和压缩。

找不到商品的情况能够触发备用工作流，这样商店经理能够不考虑销售交易的建议价格继续工作。在找不到商品的情况下，Web 服务实时提醒经理，经理会在工作站或 PDA 依次启动库存管理应用程序，暂时分配给售货员一个价格以便完成交易。同时，Web 服务还向企业系统提醒有缺失的价格。当采购经理收到有关缺失价格的警告时，经理将更新价格，之后价格信息将会被实时传送到全部商店。

来自企业系统的传入消息也实时经过相同的步骤，如图 8 所示。

图 8. 来自企业系统的传入消息

单击查看大图像

来自企业系统的消息（例如价格更新或商品召回通知）也经过相似的步骤。例如，如果价格更新消息到达了商店，在传送到价格数据库前，要对这些消息进行解压缩和转换。价格更新将会在商店中的全部 POS 系统中实时反映。

例如，当商店收到商品召回消息时，会将它保留在数据库，之后会立刻暂停召回商品的继续销售。提示 Web 服务会选取该消息，通知商店经理将正在销售的召回商品撤回到仓库，以阻止召回商品的继续销售。实时触发工作流阻止了召回商品的销售，减少了零售商的责任。

该引用结构体系显示了如何使用面向服务的结构概念（其中无需很多的人为干预即可触发工作流）实现实时服务。使用标准化的 XML 消息即可实现商店和企业系统的全部通信。如上一章所述，消息是来自商店、企业系统或供应商的 XML 文档。XML 文档的一部分标识消息类型和路由信息。每一条信息都与定义有效消息格式集的 XML 架构相关联。在该引用实现中，来自企业系统的传入消息在任何可以使用 HTTP 的地方，以 IXRetail 的格式传送。尽管消息能够以各种不同的模式交换，该实现还是选择使用异步双向消息传送。

在商店收到消息时，如果需要，该消息会被转换，然后保存到数据库供其他服务使用。其他 Web 服务会选取该消息，以触发警告或操作。

公司总部体系结构实现构图

图 9 显示了公司总部系统的引用结构体系。在这种情况下，MSMQ（未在示例应用程序中实现）可作为排队机制；BizTalk 用于聚合、转换和编排到达企业的信息。消息包括了商店销售数据、供应商商品召回消息或购买订购单的确认。BizTalk 加速器用于和企业 LOB 系统（例如销售系统或 ERP 系统和数据仓库）通信。

BizTalk 用于转换数据和编排传入消息。这有助于快速将商店系统与企业 LOB 系统相集成。

图 9. 企业参考结构体系

单击查看大图像

企业从商店、供应商和多种渠道（如电子商务和分类订单）接收信息。来自商店的消息包括销售交易数据、库存级别阈值和商品价格请求。销售交易数据经转换实时保存在数据库和数据仓库中。这些数据库驱动企业级实时 KPI 监控和报告功能。电子商务和分类订单需要实时检查库存来完成实现，以及确认客户挑选店内商品的请求。即使这一点得到正确地执行，而且接受了电子商务或分类订单并承诺客户可以在店内挑选商品，也可能由于店内商品短缺而不能满足客户的要求。因而，订单履行应用程序在接受订单前实时检查店内的库存级别就显得至关重要。

商店发出的消息（如“未找到该商品”）在企业处生成警告，要求采购经理输入商品价格，该价格将实时下载到商店。店内库存掉落到某个阈值以下时，企业会收到一条消息，该消息将触发生成订购单 (PO) 的工作流，并且要求企业采购经理的批准。随后 PO 被发送至供应商。

商店发送给企业的实时信息流有助于企业进行实时决策和监控。

图 10 显示了来自企业的外发消息。价格更新、库存检查和商品召回等消息被实时发送到商店，能够避免企业的损失和财务责任。

图 10：外发企业消息

单击查看大图像

外发消息（如供应商发出的商品召回消息）被即时传送到商店以暂停召回商品的继续销售。供应商发送的消息以任何形式被接收，之后被转换为 XML 格式。然后将执行库存查找来检查哪些商店存有召回商品，接着召回消息就会传送到那些商店。

对未找到该商品请求的响应也遵循相似的途径。价格更新信息仅发送至存有特定商品的商店。

返回页首

信息流

此部分讲述信息在每个情景中是如何流动的。它显示了各种服务在商店和公司级别是如何交互以简化实时决策的。将对每个示例情景以及实时传送信息到合适地点的步骤作详细讲解。

情景 1：未找到产品

正如前面所述，这是零售环境下出现的常见情形。该情形需要经理的实时干预，以保证对商品的顺利结帐以及提供良好的客户体验。

使用示例应用程序复制此情景的步骤和相应的解决方案，如下所示：

1. 在 POS 应用程序上选择一项价格在 Store DB 的 ItemMaster 表中为零的商品。

2. 单击“Add”（添加）为此产品结帐。消息如下所示：“Price not found for this item.Do you want to convey it to the Store Manager?”（没有找到此项商品的价格。要将它传递给 Store Manager 吗？）

3. 单击“Yes”（是）。之后该通知被发送至 Store Manager。

4. 单击“Notifications”（通知）选项卡查看 Store Manager 应用程序中的通知。

5. 在 Store Manager 应用程序中，单击“Inventory”（库存）选项卡，选择找不到价格的商品。编辑价格并保存。一封电子邮件会发送到公司总部的采购经理处，Store DB 中的价格将得到更新。

6. 通过以下位置打开公司总部的 Merchandising 应用程序：http://localhost/HQSystemsetup/UpdateItem.aspx

7. 更新找不到商品价格商品的价格，然后保存。

8. 最终价格保存于 Store DB 和 HQ DB 中，同时显示消息。

9. 再次选择 POS 上的同一商品。该商品能够用更新后的价格结帐。

图 11. 找不到商品的情景

单击查看大图像

图 12. 找不到商品的情景 - 顺序图

单击查看大图像

情景 2：商品召回

正如前面所述，这是零售环境下出现的常见情形。该情景需要经理和职员的实时操作。示例应用程序说明如何通过使用最新技术（具体地说，即 Web 服务）使此场景能够完全自动化。

使用示例应用程序复制此情景的步骤和相应的解决方案，如下所示：

1. 供应商通过在以下位置启动 Supplier 应用程序来启动召回过程：http://localhost/SupplierAppSetUp/SupplierApp.aspx

2. 选择一项商品后，供应商将商品召回消息发送给采购经理（其“邮件 ID”在 Supplier 应用程序的 Web.config 文件中被配置）。

3. 一旦收到电子邮件，公司总部应用程序在以下位置被启动：http://localhost/HQSystemSetUp/RecallItem.aspx

4. 单击“Notify Recall”（通知召回）按钮，向 Store Manager 发送通知。

5. 单击 Store Manager 应用程序上的“Notifications”（通知）将显示此通知。

6. 当试图对召回商品结帐时，将会显示一条信息说明这是一项召回商品，禁止结帐。

7. 同时，在 Store Manager 应用程序也能够看到召回商品的通知，可以提醒经理将召回商品从商店货架中撤下。

图 13. 商品召回情景

单击查看大图像

图 14. 商品召回情景顺序图

单击查看大图像

情景 3：商品缺货

正如前面所述，这是零售业普遍面临的常见问题。示例应用程序说明了最新技术如何克服这个问题并提供更丰富的客户体验。

使用示例应用程序复制此情景的步骤和相应的解决方案，如下所示：

1. 当试图对一项商品结帐时，POS 设备会显示缺货消息。

2. 紧接着，通知将被发送给商店经理，要求其将商品从仓库摆放到商店货架。

3. 如果结算商品的库存级别降至某一阈值（由公司总部的职员设置）之下，将重复相同的步骤。

4. 警告会发送至商店经理处，提示缺货。

5. 单击 Store Manager 应用程序中的“Notifications”（通知）选项卡，打开警告。

6. 单击 Store Manager 应用程序上的“Stock Transfer”（存货转移）链接，将存货从仓库转移到货架（如果仓库有库存）。

7. 接下来，通过在以下位置打开公司总部应用程序，能够将一些商品从公司仓库进行转移。http://localhost/HQSystemsetup/InventoryShipment.aspx

8. 当您在公司总部应用程序中时，从组合框中选择缺货商品和商品一定会转移到的商店位置，然后单击“OK”（确定）。

9. 商品从 HQ DB 库存表转移到将要接受商品存货的 Store Manager 应用程序。

10. 通过单击 Store Manager 应用程序上的“Stock Transfer(In)”（存货转移）链接并接受所显示的存货，商店即可接收商品。

11. 库存在 Store DB 中得到更新。

图 15. 商品缺货情景

单击查看大图像

图 16. 商品缺货情景顺序图

单击查看大图像

情景 4：促销商品销售数据实时传送

如前所述，商店销售数据以批处理形式传送，其中销售数据被积累然后每晚或一天两次传送到公司。这限制了公司级别特别需要的有关商店运营的可见性。有必要以近乎实时的方式提供销售交易数据。因此，示例应用程序说明了将交易信息从商店实时传输到企业系统的过程。它也说明了某些业务规则在实时传输销售交易信息中的应用。例如，与高价商品和促销商品有关的销售信息以最高优先级进行实时传输。其他交易数据以次优先级进行实时传输。本地主机上托管的服务从多个 POS 设备收集同时发生的销售数据更新信息，将它们进行聚合、转换，然后根据公司总部设置的规则传输数据。

使用示例应用程序复制此情景的步骤和相应的解决方案，如下所示：

1. 通过在以下位置启动 HQ 应用程序，在公司总部级别设置实时传送的规则：http://localhost/HQSystemsetup/SalesConfig.aspx

2. 接下来，使用公司总部 Web 应用程序，输入“Details”（详细信息）和将某种商品作为优先级处理的条件。

3. 这些详细信息存储在 BusinessRules.xml 文件中，其路径在 BizTalk 应用程序中设置。它将存储在 config 文件中提到的共享位置。

4. 打开 POS 应用程序，选择要结帐的商品。单击“Proceed”（继续）。将会显示“Check for PRITRANS”（检查 PRITRANS）的通知。

5. 在高速传送数据的 Store DB 表的 SalesDetails 中，为传送位选择“True”。

6. 数据自动移动到高速传送数据表相应的 HQ DB 中的 SalesDetails 表。

7. 关闭 POS。一个弹出窗口将会显示“Checking for standard data transmission”（检查标准数据传输）。随后，全部低优先级数据被传送到 Store DB 的 SalesDetails 表。

图 17. 促销商品销售数据实时传送情景

单击查看大图像

情景 5：供应链

如前所述，商店销售数据通常每晚以批处理的形式传送到公司系统。这会导致公司级别不能准确预见商店库存的存货情况，会延迟针对供应商的订单生成，这样供应商就会在延迟很长时间后才能供货。接下来，以上全部事情就会导致非常不好的客户体验。示例应用程序说明了最新技术如何克服这个问题并提供更丰富的客户体验。

使用示例应用程序复制此情景的步骤和相应的解决方案，如下所示：

1. 在 POS 处检查某种商品。库存级别是更新过的，并且如果它在阈值级别之下，Store Manager 应用程序将发出通知。

2. 商店经理会将剩余商品从仓库移动到商店货架。

3. 必须订购新商品以保持完整的供应链和库存级别。要订购新商品，通过以下位置打开 HQ 应用程序：http://localhost/HQSystemsetup/Purchase Order.aspx

4. 输入商品的“Details”（详细信息），然后单击“Send PO”（发送 PO）来更新在 HQ DB 的库存。

5. 发送确认 PO 的电子邮件后，通过以下位置打开 HQ 应用程序：http://localhost/HQSystemsetup/InventoryShipment.aspx

6. 从组合框中选择商品和商店位置（商品一定会传送到这里），单击“OK”（确定）。

7. 商品从 HQ DB 库存表转移到将要接受商品存货的 Store Manager 应用程序。

8. 经理通过转到 Store Manager 应用程序并接受库存转移来完成接收步骤后，可在 POS 对该商品结帐。

9. 在 POS 应用程序，商品库存可通过单击“Check Availability”（检查可用性）来查看。这将显示来自 Store DB 的更新后数量。

图 18. 供应链情景

单击查看大图像

返回页首

技术决策

零售企业实现灵活性的方法有多种。但是，采用有助于开发和维护并可灵活进行未来扩展的技术将会降低零售企业的总体拥有成本。本部分将介绍此最新技术的功能和特性，以及采用这些不同技术所带来的益处。

Windows Communication Foundation (WCF)

WCF（以前的代号为“Indigo”）是一套用于构建和运行互联系统的 .NET 技术。它是围绕 Web 服务架构构建的一种新通信基础结构。

WCF 通过安全、可靠和事务式的消息传递提供先进的 Web 服务支持以及互操作性。但有三个方面尤为突出，是 WCF 最重要的方面：其整合了多项现有的 Microsoft 技术，其支持跨供应商互操作性以及其明确以服务为导向。

此外，开发此示例应用程序时的一个主要顾虑是我们要在难以实现的实时应用环境中连接分离的系统（POS、LOB、Store）。但由于 WCF 的基本通信机制是 SOAP，所以 WCF 应用程序可以与运行于各种环境中的其他软件进行通信。构建于 WCF 之上的应用程序可以与以下所有应用程序进行交互：

• 运行于同一台 Windows 机器不同进程中的 WCF 应用程序。

• 运行于另一台 Windows 机器上的 WCF 应用程序。

• 构建于其他技术之上的应用程序，例如，支持标准 Web 服务的、基于 Java 2 Enterprise Edition (J2EE) 的应用程序服务器。这些应用程序既可以运行于 Windows 机器上，也可以运行于装有其他操作系统的机器上，例如 Sun Solaris、IBM 的 z/OS 或 Linux。

因此，如果要针对非 Microsoft 平台扩展此示例应用程序，十分容易便可完成。

为支持基础通信以外的其他高级通信，WCF 实现了一组统称为 WS-* 规范的较新 Web 服务技术。这些文档定义了各种多供应商方式，用以将可靠的消息传递、安全性、事务及更多功能特征添加到基于 SOAP 的 Web 服务中。第一版 WCF 中所支持的 Web 服务规范包括 WS-Addressing、WS-Policy、WS-MetadataExchange、WS-ReliableMessaging、WS-Security、WS-Trust、WS-SecureConversation、WS-Coordination、WS-AtomicTransaction 以及 SOAP 消息传输优化机制 (MTOM)。

最后，由于 WCF 为面向服务的软件提供了一个标准基础，因此将成为大部分 Windows 通信的基准。

这项技术的影响不可小觑。那些基于 Windows 构建分布式应用程序（尤其是必须与其他平台上的应用程序实现互操作的应用程序）的人们应予以密切关注：WCF 将改变他们的一切。

商店端的 WS-* 实现

WS-*(WS-Security, WS-Reliability) 可以帮助组织定义用于在多个端点之间识别和交换 Web 服务消息的标准机制，从而构建可靠而又能够互操作的 Web 服务应用程序。有了一种标准方法来表示消息在 Web 服务网络中的传送目标后，开发人员可以简化 Web 服务的通信和开发，而且不必再开发费用高昂而且往往难以实现跨平台交互的一次性解决方案。

WS-* 是核心 Web 服务体系结构的关键部分。具体来说，此规范支撑着其他规范（如 WS-ReliableMessaging、WS-Federation 和 WS-AtomicTransaction），用以提供一种独立于的协议公共方法来查找支持事务、安全性、可靠消息传递及身份联合等特征的 Web 服务。

WS-Security：Windows 身份验证

此应用程序中的配置文件将 wsHttpBinding 中 Security 元素的模式属性设置为 Message，将 clientCredentialType 属性设置为 Windows。clientCredentialType 的其他选项为 None、Username 和 Certificate。安全模式的其他选项为 Transport 和 TransportWithMessage。

<bindings>
   <wsHttpBinding>
      <binding name="Binding1">
         <security mode="Message">
               <message clientCredentialType="Windows"                
                negotiateServiceCredential="True" />
         </security>
         <reliableSession enabled="true" ordered="true" />
      </binding>
   </wsHttpBinding>
    </bindings>

客户端端点配置由配置名称、服务端点的绝对地址、绑定和约定组成。客户端绑定通过相应的 securityMode 和 authenticationMode 加以配置。运行于跨机器环境中时，使用 identity 和 userPrinicpalName 元素。

<system.serviceModel>
   <client>
      <endpoint address="http://mmoin/contoso/Service.svc" 
           bindingConfiguration="WSHttpBinding_IStoreService"
           binding="customBinding" contract="IStoreService">
          <identity>
          <servicePrincipalName value="host/mmoin" />
          </identity>
      </endpoint>
   </client>
   <bindings/>
</system.serviceModel>

服务源代码已经过修改，用以展示如何使用 CurrentPrincipal 来访问调用方的身份。此代码需要包括 System.Security.Principal 命名空间。

WS-Security：Kerberos

在有些情况下，应使用 Kerberos 身份验证来代替 Windows 身份验证。

Windows SSPI 协商实质上需要在客户端与服务器之间进行多次信息交换才能获得实际要使用的身份验证协议。而在性能要求较高的环境中，多路协商可能是不允许的。

这种情况下，所期望的消息交换模式应做这样的规定：通过对每条消息使用 Kerberos 身份验证的服务来进行客户端身份的验证。

利用 WCF，您可以创建和部署要求采用 Kerberos 身份验证的客户端和服务。

客户端和服务配置文件应进行相应修改，指明此绑定不应采用协商形式。

<bindings>
   <wsHttpBinding>
      <binding name="Binding1">
         <security mode="Message">
            <message clientCredentialType="Windows"
            negotiateServiceCredential="False" />
         </security>
   </wsHttpBinding>
</bindings>

如果此示例跨机器运行，则应在端点地址中指定完全限定的机器名称。同时，身份应指定具有完全限定机器名称的服务主体名称。WCF 会将端点地址中的完全限定主机名称与服务主体名称进行匹配。如果此项检查成功，服务会被视为已经过客户端的身份验证。

WS-Security：匿名

“匿名”示例展示了一个特殊 WCF 应用程序的实现方法，这个应用程序使用不进行客户端身份验证的 WS-Security 但要求服务器身份验证使用服务器的 X.509v3 证书。客户端和服务器之间的所有应用程序消息都要经过签名和加密。

客户端配置

<security mode="Message">
   <message clientCredentialType="None" />
</security>

<!--服务配置-->

<security mode="Message">
   <message clientCredentialType="Certificate" />
</security>

WS-Security：证书

要为客户端配置使用 X.509v3 证书进行身份验证的 WS-Security，服务器的身份验证必须使用服务器的 X.509v3 证书来进行。

服务器证书中包含的 SubjectName 值必须与 serviceCredentials 中的 findValue 值相同。

<serviceCredentials>
   <serviceCertificate findValue="localhost"
           storeLocation="LocalMachine" storeName="My"
           x509FindType="FindBySubjectName" />
</serviceCredentials>

<!--客户端与服务均应针对 clientCredentialType 配置
为证书。-->

<security mode="Message">
   <message clientCredentialType="Certificate" />
</security>

WS-Security：用户名

为实现一个使用用户名身份验证 WS-Security 的应用程序，所有客户端和服务器之间的应用程序消息都要经过签名和加密。默认情况下，会使用客户端所提供的用户名和密码登录到有效的 Windows NT 帐户。

<security mode="Message">
   <message clientCredentialType=" UserName " />
</security>

客户端调用将使用用户名和密码。

proxy.ClientCredentials.UserNamePassword.UserName = username;
proxy.ClientCredentials.UserNamePassword.Password = password;

WS-Reliability

服务将如下进行配置。

<reliableSession enabled="true" ordered="true" />

BizTalk Server 2006

BizTalk Server 2006 是一个业务流程管理 (BPM) 服务器，可帮助公司实现业务流程的自动化和最优化。其中包括强大而为人所熟知的各种业务流程设计、开发、部署和管理工具。因此，为了管理工作流以及商店与企业之间的业务流，我们选择了 BizTalk Server 2006。

此外，BizTalk Server 2006 还从用于商店与总部间通信的 IXRetail 架构创建了 XML 消息。

BizTalk Server 2006 支持在不同机器上的商店和总部系统之间进行有效地交换信息。如果存在多种通信风格，BizTalk Server 2006 引擎还必须支持 IXRetail 等各种协议和消息格式。

此外，BizTalk Server 2006 还针对不同的产品（如 Microsoft SQL Server）提供了适配器，用以与之集成。因此，在本示例应用程序中，为了与 Store 服务和 SQL Server 集成，使用了 Web 服务适配器和 SQL 适配器。

各种零售场合的业务逻辑是使用 BizTalk Server 2006 的编排引擎实现的，这使其成为一个托管业务逻辑的公共中间层。

BizTalk Server 2006 还提供了一个企业单一登录工具，能够在 Windows 和非 Windows 系统之间映射身份验证信息。从而，可以实现跨异类平台的互操作性。

总之，BizTalk Server 2006 旨在帮助此示例应用程序解决在创建依赖于多样系统的自动化业务流程时所面临的一系列问题，并帮助此示例程序使用产品的基础 BizTalk Server 2006 引擎，这一引擎可以提供核心的消息传递和编排功能。

在 BizTalk Server 2006 发布后的某个时间，BizTalk Server 将作为一个通信选项为 WCF 增加支持功能。

Business Scorecard Manager

Management Dashboard 是在此示例应用程序中创建的应用程序，供管理人员在一个公共的 Web 位置查看销售情况、库存量及警报信息，使其能够有效地管理商店中的库存及资源。

Management Dashboard 提供了基于 Web 的报告门户，使管理人员可以只访问和查看最为重要、最为相关的信息，从而提高了管理人员的工作效率。管理人员可以同时查看多个着重展示商店数据中关键问题的报告。然后可以进一步深入浏览到底层的详细报告。这是使用 Business Scorecard Manager (BSM) 2005 来实现的。

仪表板全面利用计算机桌面，并结合其他相关的信息（如非结构化数据、协作工具、图表和图形以及其他计分卡），从而增强了此示例应用程序的功能。此仪表板以图形的形式显示各种趋势，并为用户提供做决策时所需的其他上下文信息，从而提供了供数据通信和分析使用的全面视图。

BSM 是一个综合的计分卡和仪表板应用程序，可以帮助您对业务的驱动因素有深入且有脉络可寻的了解。BSM 提供了一个直观且友好的设计，使组织内的任何人都能够构建、监视和管理对其有意义的关键绩效指标 (KPI)。

示例应用程序使用 BSM 在 Management Dashboard 中为商店管理人员提供销售、库存和促销数据 KPI，用以分析 KPI 与有形业务对象之间的关系。

从业务角度来说，示例应用程序通过在 BSM 中跟踪关键绩效和财务数据，大大地增强可视性，并加快了报告的速度，从而使其对零售业务中的物料变化更为警觉，并符合相关的信息披露与归档要求。

此外，平衡计分卡并不只限于用财务数据将企业策略与 LOB 操作关联起来。这是因为计分卡通常根据 KPI 来汇报组织在财务及非财务方面的绩效。企业策略往往围绕整个组织的各个环节，从财务到销售再到运营，因此计分卡及其要素 KPI 也必须涉及所有这些环节。

在此示例实现中，使用了 BSM 来实现以下目标：

• 采用清晰的图形界面进行明确的数据解释。

• 完全支持 Web，从而使用通用媒体将相同的消息即时中继到多个远程位置，使用户能够实时查看关键业务的趋势。示例应用程序中 BSM 销售和库存情况就是这样实时更新的。实现实时更新是选择 BSM 进行仪表板管理的一项关键要求。

• 通过鼓励针对对象进行个别定义引入灵活性，同时引入对销售绩效的测量、监控和管理。

• 将销售信息映射并链接到组织的战略目标；创建以策略为核心的操作，并鼓励使用各种信息来衡量和优化销售引擎；或驱动新的方案。

• 为个别商店管理人员及时提供跨不同商店的个性化信息。

• 将业务流程与其为了帮助自身更有效运行而创建的各种信息重新联系在一起。

• 支持各种不同的数据和报告视图以及深入且易于执行的分析，提供高度定制的、具有可测量值的业务工具。

• 提供结构化数据，以及文档、电子表格、链接和其他非结构化数据，从而促进了平衡且有据可依的决策过程。

• 位于传统的销售 LOB 应用程序之上，以保护财务和培训投资并充分利用现有数据。

返回页首

结束语

颠覆性技术（如 RFID、无接触式支付、移动式支付、生物特征测定式支付、Wi-Fi 等）为零售商们带来了挑战和机遇。那些适时采用这些技术并利用它们来接触更多客户及发现新市场的零售商将会获得不断增长的收益，而那些躲避这些技术的零售商则会发现要在这个竞争严酷的市场中存活是何等艰难。

随着宽带和 RFID 技术在这一市场中不断发展，客户会从零售商那里获取更好的体验。这就要求不但要在内部采用这些技术，而且还要改进现有系统以吸纳生成的新数据。如果使用得当，这些额外的数据会有助于进行实时的决策；否则，它们就会倾覆并扼杀企业的业务。因此，进行实时决策在零售业务中极为关键。随着客户要求的日益苛刻，竞争压力不断增大，系统灵活性的要求也与日俱增。要获得灵活性，就需要在合适的时间、合适的地点使用合适的信息。

零售商利润微薄，这就意味着他们必须始终寻求各种方式来削减成本。遗留应用程序是发展的绊脚石，因而与其说 IT 在支持业务的发展，还不如说 IT 在支配着业务的发展。要使 IT 支持不断变化的业务需求，必须具有构建于可支持发展的技术之上、具有灵活性和适应性的解决方案。以服务为导向是新的体系结构模式，这种模式有着帮助 IT 实现灵活性并跟上这些业务要求的潜力。

致谢

我要感谢 Microsoft Corporation 的 Nick Lewis、Tim Gruver 和 Michael Graber；Tata Consultancy Services 的 Avadh Jain、Anurag Katre 和 Ramesh Lankaand；以及 Ideastream 的 Jon Tobey 在这项工作期间所给予的帮助。