1 SCM系统概述

    供应链管理(supply chain management，SCM)是指对整个供应链系统进行计划、协调、执行、控制和优化的各种活动和过程。供应链管理的内容是提供产品、服务和信息来为用户增加价值，是从原材料供应商到最终用户的关键业务过程的集成管理。对于一些相对较长、关联性相对较紧密，具有大规模协同的一个产业结构链来说，如汽车工业，一个强大、稳定的SCM系统将帮助企业提高管理水平、降低库存、加快资金周转、提高客户响应速度，并成为企业供应链的整体增值经营的关键因素。

    这样一个SCM系统需要有数目众多的WebService来支撑其整个服务环境，比如汽车工业管理部门与一级供应商、二级供应商、一直到第n级供应商，部件的配套、汽车的总装等各个部门的在线交互中会产生大量携带业务数据的事务请求。为此，需要一个具有一定可靠性与稳定性的系统应用环境，需要采用一个松耦合的构架，这种构架也是未来分布式应用的大势所趋——面向服务架构。以确保企业能对业务的变化做出快速的反应，实现对现有的应用程序和应用基础结构的投资，并不断解决新的业务需求。汽车产业中的SCM中的SOA服务架构见图1。
 

    在图1中，服务消费者可以通过发送消息来调用服务。这些消息由一个服务总线转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎，该引擎容许业务规则被合并在一个或多个服务里。这种架构也提供了一个服务管理基础用来管理服务。在服务总线中，这种架构还需要实现一种异步模型，特别是针对SCM的应用，常常携带大量业务数据(例如订单及对订单的处理信息)，需要把大量业务逻辑的消息包附件的逆序列化放在消息接收者中处理以及返回通知，由此给企业提供了灵活的业务流程，并且能够更好地处理控制请求，及在不影响其他服务的情况下更改某项服务，确保一个强大、可靠与稳定的SCM系统。基于此，需要一个能够支持SCM系统同步异步作业通讯模型，也需要一个面对众多Web Service产生的大量XML封装数据仍能保证SCM系统高效性的通讯协议，而这样一个应用环境正是本文的研究对象，即基于Wse2.0的异步传输协议——Soap.MSMQ。

2 Wse

    WebService技术以其低耦合度、跨平台和语言无关的应用优点正在彻底地改变着传统电子商务形态，WebService使用基于XML的Soap消息处理作为基本的数据通讯方式，消除使用不同组件模型、操作系统和编程语言的系统之间存在的差异。而ASP.NET WebMethod框架与其他类似框架的普及几乎都是通过http的传统远程过程调用(RPC)来完成对网络服务的访问，这显然有违于WebService应该支持任何形式的XML消息处理和从不同的通讯协议受益的初衷。

    当性能与可靠性为主要目标时，直接使用TCP而非更高级别的协议(如HTTP)将使一些网络服务受益。Microsoft新发布的网络服务增强(Wse 2.0)支持使用诸如TCP、SMTP或Microsoft消息队列提供的异步通讯模式，允许用户开始体验除HTTP以外的其他XML消息处理可能性。大多情况下，WSe设计用来为WS-Security、WS-Trust、WS-SecureConversationl WS-Policy，WS-SecurityPolicy，WS-Addressing提供支持，以符合WS-Security标准。但是Wse 2.0(以下简称wSe)包括一个新的特性：Soap-messaging，这组增强的API支持其他传输和自定义消息交换模式，以搭建基于XML的异步消息处理系统。

    Wse的消息结构(如图2)，可以分为3层：传输层、控制层、应用层。传输层主要是处理消息在输入＼输出通道和物理流之间处理消息的封装。
 

    Soap Dime Formatter  这个基类处理主要负责Soap消息包和Dime(直接Interact消息封装)二进制流之间的转换，Dime包的第一条记录存放Soap正文，紧接着存放附件，这是Soap.tcp，Soap.inproe以及本文探讨协议传输的默认格式，这种格式可以、通过程序实现也可以通过配置文件实现。

    Soap Plain Formatter  这个基类处理主要负责Soap消息包和XML文本流之间的转换，这是Soap.http的默认格式。

    Soap Transport  这个类负责Soap消息在特定通道和传输协议之间的派送，在发送Soap消息时。可以获得在EndpointReference集合中注册的通道，然后通过特定的传输协议(tcp，http等)传输到远程地址。另一方面，接收Soap消息时，当SoapFormatter处理完特定的资源流(如Socket，MSMQ)，并将之转换为Soap消息包时，负责将此消息包派送到给定的接受通道，并且将此信息包的引用加入该通道的内存队列中。

    Soap Input Channel  这个类负责在传输协议和接受器之间使用内存队列来产生消息流，产生同步事件来唤醒接受器。接受器可以采用同步或异步方法从队列中取出相应的消息，这个输入通道是由LocaIEndpoint引用来唯一标识的，其目的主要是在传输协议和接受器之间寻址。

    Soap Output Channel  将消息包发送到uriScheme和RemoteEndpoint的远程通道中，在客户端，可以采用同步或者异步方式来进行。

    控制层负责与业务层采用同步或异步方式来接受和发送Soap消息包。这些消息处理由接受器／发送器来完成，它们通过管道技术过滤参数对Soapheader标头进行过滤来管理包的发送，这些管道可以通过定制的安全、引用、策略参数来对消息包进行过滤。

    应用层相对简单，它完全独立于传输层，利用Wse 2.0消息架构的特色来实现同步或异步的双向传输。
3 Soap.MSMQ工作模型及部署

    通过上面讨论的Wse消息结构，很容易得到Soap.MSMQ传输方式的工作模型，如图3所示。
 

    Soap消息包及其附件以DIME格式进行传输。DIME流先被SoapDimeFormatter转化成对应的Soap消息包，然后SoapTransport通过给定的发送算法寻找对应的接受管道，并将之加入内存队列，触发PeekCompleted事件，在Soap-port通道中对消息包进行过滤，最后到达应用层。

    可以通过在sender／receiever端编程或者配置Web.config文件的方式来部署Soap.MSMQ，因为在Web.config文件中部署，可以在构建异步传输类的实例时，通过读取Web.config文件中XML节点的方式批次设置其传输属性，而省去很多编程工作，讨论的自定义Soap.MSMQ传输属性见表1。

表1 Soap.MSMQ传输属性
 

    0
    1
    2
    3    4 type＝“RKiss．WseTransports．SoapMsmqTransport，SoapMSMQ
    5 Version＝1．0．0．0
    6 Culture＝neutral，PublicKeyToken＝a94298 b6c0d04e59>
    7
    8
    9
    10
    11
    12
    13
    14<／sender>
    15
    16
    17
    18<／receiver>
    19<／add>
    20<／transports>
    21<／messaging>
    22<／webServices>

    配置文件说明：

    构造SoapTransport的实例，SoapMsmqTransport transport 2 new SoapMsmqTransport(System.Configuration.ConfigurationSettings.AppSettings(“transports”))；

    构造函数主要访问配置文件的transports节点。3～19表明采用的是用户定义的传输协议Soap.MSMQ；7表明接收器和发送器采用transactional方式来处理消息；8～14表明发送器发送资源队列，接受和到达队列的时间间隔；15～18表明接收器线程数和错误资源队列，因为是DIME格式，所以一般只采用1个工作线程，此配置文件没有设置formatter节点，表明采用SoapMsmqTransport默认的传输格式，即DIME(SoapMessage＋attachment)进行的传输。

    Wse使用自带的3个通讯协议或定制的协议来支持发送和接收消息时，用户必须指出通过URI想要使用哪种机制：(SoapSender、SoapReceiver)。它们都必须遵循以下Wse中的语法：

    protocol_scheme：∥host[：port_number]／path_info／…

    其中，协议方案指出使用哪种协议；而主机和端U(host[：port_number])标识在哪里发送消息；路径信息标识在特定主机上访问哪种资源。同样，Soap.MSMQ在此基础上进行了扩展，以支持更灵活的通讯方式，以真正符合异步商务模型的需要。
4 应 用

    这种方案整合了两种异步通讯技术：Soap与MSMQ。在SCM系统的应用环境中，这两种技术的优势将逐渐体现。在测试级的应用中，证实了传输协议的以下应用效果。

    a．支持脱机环境的应用完全支持了SCM系统不定批次、不定量、不定时处理数据的应用特点。

    b．支持大容量数据传输传统Edj的电子媒介在以大容量文件作为Soap消息包进行附件传输时，会遇到严重的资源问题。而Soap.MSMQ传输协议将附件切割成多个小块，并附加在多个消息包中，根据发送器的需求在事务上下文中保证消息包的序列，而接受端(SoapService)仅配置一个工作线程来处理附件的合并，最后得到完整的文件。这种方式显著改善了Web服务器的资源开销。这一点也完全能够支持SCM系统在大量数据的交互中仍然需要保持系统稳定高效的应用特点。这也给本文伊始提出的传输性能问题一个较好地解决方案。在电子商务教学系统模拟环境下，对传统的通讯模型和本文所讨论的方案，在处理携带大容量附件MTOM数据时所遇到的系统性能瓶颈问题进行了研究，并得到图4中的数据对照。
 

    c．支持系统安全等级的统一由于使用了Soap，数据是以ASCII文本的方式，而非二进制传输，调试方便；并且其数据容易通过防火墙，不需要防火墙为了程序而单独开一个“漏洞”，这也符合SCM系统高稳定性的要求。

5 结束语

    在SCM系统可靠性要求较高的业务模型中，可以通过将传输协议的业务模型分为2个协同的子模型：同步模型和异步模型。通过MSDTC(Microsoft分布式事务协调器)事务方式先在同步模型(Soap.client)中对消息进行预处理，然后真正的业务逻辑放在异步模型(Soapservice)中完成，对消息的处理后再通过Soap.MSMQ回发完成通知。在这种交互方式中，消息通常用于传输业务文档，比如购买生产部件的订单、发票和提单。这种交互类型与异步消息排队系统的兼容性很好。由于SCM系统中会产生大量的事务迁移，而事务迁移会产生大量的数据交换，从而会导致处理数据需要花费数小时，甚至数天的时间才能从执行流的处理过程中获得。进而造成已执行的文档或新文档被传回给始发者，而有了异步消息排队系统的结合应用则会大大减少这种情况的发生。在SCM系统并行事务处理环境下，大量批次的请求必须以并行方式处理，同步预处理模型会产生大量的携带业务数据的事务请求。异步处理模型处理这些请求，分别更新业务数据库，并且最后完成的是事务回发一个完成通知。由于改善了Web服务器的资源问题，使SCM系统更能发挥其效用，帮励企业实现准时生产方式的理想化整体产业供应链模式。