专利名称：一种基于扩展soap的数据密集型多媒体服务调用方法
技术领域：
本发明涉及互联网Web服务技术领域，更具体地，本发明涉及一种基于扩展 SOAP的数据密集型多媒体服务调用方法。
背景技术：
由于需要对多媒体音视频数据进行处理，多媒体业务中经常包含连续的并且在 时间和空间两方面相关性很强的数据流，是一种典型的数据密集型业务。基于这一 原因，目前多媒体应用被普遍地以单一的、紧耦合的完整系统方式加以实现。这使 得多媒体业务的建立、维护、升级与及与其他业务的集成一直是一个比较棘手、昂 贵、时间耗费巨大的难题。除多媒体业务外，数据密集型业务还包括数据托管、大 规模数据分析如数据挖掘应用等，这些数据密集型业务也存在与其他业务集成困难 的问题。
另一方面，面向服务架构(Service Oriented Architecture,简称SOA)提供了一 种可根据需要动态组合服务以形成集成业务的方法，它基于根据标准预先定义的接 口，允许分布式和异构组件之间进行松散连接，是一种更为鲁棒并且易于扩展的大 规模系统设计方法，已经成功地为众多大规模应用系统提供了更为柔性的解决方案。 在INTERNET环境下，Web Service技术作为SOA的一种实现方式，得到学术界的 承认并获得众多软件巨头如IBM、微软等的支持。Web Service由一系列基于XML 的标准组成，如SOAP、 UDDI和WSDL等，它实际上定义了一种平台无关的远程 对象交互模型，实现该模型的核心是简单对象请求协议(Simple Object Access Protocol,简称SOAP)。因此，如果能够将Web Service应用到多媒体业务领域，构 建一种支持面向服务架构的分布式多媒体应用系统，则可以有效地解决多媒体业务 系统的开发、维护与及与其他业务系统集成等方面的难题。
但是，Web Service技术最初是作为INTERNET事务类应用(如电子商务)的解 决方案被提出的，主要针对的是输入参数的数据规模较小的文本数据业务，对于涉 及大容量的二进制数据的多媒体业务支持很弱。其中一个关键原因就是多媒体应用 中数据一般要作为程序的处理对象，例如转码服务中原视频文件必须作为参数提供 给服务。而现有的SOAP及其扩展无法有效地支持将大规模数据作为参数封装到其 消息体中作为远程过程调用的输入。万维网联盟(W3C)定义了两个在SOAP中携带附件的规范带附件SOAP消 息(SOAP Message with Attachment)禾卩XML 二进制数据优化打包(XML-binary Optimized Packages, XOP)规范。这两个规范都基于多用途因特网邮件扩展 (Multipurpose Internet Mail Extensions, MIME)协议，附件所包含的二进制数据在 传输时要首先使用base64编码为文本然后作为MIME信封中的一部分进行传输， SOAP消息本身作为另一部分。由于将二进制数据进行base64编码会增加1/3的数据 量，在附件很大时这种作法将导致严重的数据膨胀，造成不必要的网络资源消耗； 并且由于要将整个附件读入内存进行打包，在附件很大时内存将被殆尽，在实验中 发现当附件较大时，基于这两个规范的系统开始变得极不稳定。另一方面，基于这 两种方法调用服务，无法自动感知附件的角色(即附件的所起到的作用)，从而无法 进行自动化处理，特别是在存在多个附件的情况下，这个不足更加突显。最后，基 于MIME这一特征，破坏了 SOAP标准本身的独立性。因此上述两个规范既无法兼 容现有的Web Service模型，也不能完全地支持多媒体业务这类数据密集型应用。
再者，多媒体业务中经常涉及数字内容的版权安全，目前的Web Service体系无 法提供一个高效的内容保护方案。目前SOAP消息的安全主要依赖于WS-Security规 范，主要通过对消息体进行完全加密的方式获得安全保障，这在数据量不大时是可 行的。但是对于多媒体应用而言，由于多媒体数据经常在数百兆以上，采用完全加 密方式代价太大，同时多媒体数据与文本数据相比其数据之间的相关性很强，采用 适当的加密方式一般能够达到只加密部分数据即可达到保护整个数据文件的效果。
发明内容
本发明的目的是，对SOAP进行扩展，在SOAP消息中引入参数与附件的关联 机制，使得SOAP能够支持将大规模数据作为参数封装到SOAP消息体中作为远程 服务调用的输入，从而提供一种基于扩展SOAP的数据密集型多媒体服务调用方法。 为实现上述发明目的，本发明提供的基于扩展SOAP的数据密集型多媒体服务调 用方法，涉及的实体包括扩展SOAP客户端和扩展SOAP服务器端，所述多媒体服 务调用方法包括如下步骤
1)扩展SOAP客户端向扩展SOAP服务器端发送扩展SOAP请求消息，所述扩 展SOAP请求消息包括消息主体部分和附件部分，所述消息主体部分包括所请求服 务的名称，所请求服务的参数名称和实例值，以及所述参数名称与附件的关联关系； 所述附件部分包括与所述消息主体部分所请求服务的参数名称相关联的附件实体， 所述附件实体包括附件元数据信息和附件文件所包含的二进制数据；2) 扩展SOAP服务器端接收到所述扩展SOAP请求消息，调用该请求消息中所 请求的服务对应的功能函数并获得计算结果，所述计算结果包括需返回的函数返回 值与及某些可能的经过处理的附件数据；
3) 扩展SOAP服务器端向扩展SOAP客户端返回扩展SOAP反馈消息，所述扩 展SOAP反馈消息携带步骤2)中得到的计算结果。
上述技术方案中，所述服务的WSDL描述中指明该服务中的参数与附件的关联 关系。
上述技术方案中，所述服务的WSDL描述中包括元素Relation、 Parameter和 Note;所述Relation、 Parameter和Note用于在WSDL中指明参数与附件的关联关系； 对于每个要关联附件的参数，在服务的WSDL文档中生成一个对应的Relation元素； Relation元素的第一个子元素是Parameter元素，Parameter元素的值为服务所定义的 输入参数中的某一个；Relation元素的第二个子元素是Note元素，该元素为本关联 的说明信息，指明本关联的含义。
上述技术方案中，涉及的实体还包括应用程序，所述步骤l)之前，还包括如下 步骤
应用程序启动服务调用过程，向扩展SOAP客户端指明服务调用信息，所述调 用信息包括所调用的服务的WSDL描述或其地址，所调用服务的名称，所调用服务 的各个输入参数的实例值，以及格式的参数与附件的关联关系。
上述技术方案中，所述步骤l)中，所述扩展SOAP客户端根据所述应用程序所 指明的信息构造所述扩展SOAP请求消息。
上述技术方案中，所述扩展SOAP请求消息通过Web服务器转发给扩展SOAP 服务器端。
上述技术方案中，所述步骤l)中，所述扩展SOAP客户端首先发送消息主体部 分，然后再发送附件部分。
上述技术方案中，所述步骤3)中，所述计算结果包含附件时，所述扩展SOAP 反馈消息包括消息主体部分和附件部分，所述计算结果不包含附件时，所述扩展 SOAP反馈消息包括消息主体部分，不包括附件部分；所述步骤3)中，扩展SOAP 服务器端首先发送消息主体部分，然后査询计算结果中是否包含附件，当包含附件 时，所述扩展SOAP服务器发送附件部分，否则，断开与所述扩展SOAP客户端的 连接。
上述技术方案中，所述附件部分进行加密传输，加密方法是使用一个全局密钥 对数据块中的数据进行有选择的加密，并使用一个与每个数据块对应的流式密钥对各数据块进行交错加密处理(所述交错是指打乱原有二进制数据位串的排列顺序)。 与现有技术相比，本发明具有如下技术效果
1、 本发明基于SOAP模型实现数据密集型业务(尤其是多媒体业务)，能够兼 容Web Service现有标准，有利于业务系统的维护和升级。
2、 与带附件SOAP消息和XML 二进制数据优化打包技术进行相比，本发明不 需要将二进制数据转码成文本并打包，不会导致突发地大量内存的占用，同时本发 明极大地降低了服务调用的等待时间。
3、 本发明将数字内容的保护纳入到整个多媒体服务调用框架之中，大幅提高了 加密效率。
图1为扩展SOAP客户端与服务器端在服务调用过程中的交互时序示例； 图2为扩展SOAP服务器对调用请求的处理流程图。
具体实施例方式
本发明在兼容Web Service现有标准的基础上，通过在SOAP中引入新的语义要 素对SOAP进行了扩展，使其能够支持携带大规模多媒体数据进行远程对象访问； 定义了与现有标准完全兼容的新的端节点SOAP消息交互模式——当前交互模式是 其子集，并基于HTTP协议给出一种实现该交互模型的方法，在此基础上本发明给 出了一个多媒体业务的面向服务架构实现策略。下面结合附图和具体实施例对本发 明做进一步地描述。
实施例
模型定义
SOAP作为一种远程对象调用方法可以分为请求和反馈两个部分，请求消息中主 要包含所要调用服务的名称和参数，反馈消息则包含客户端期望的服务计算结果， 比较通俗的理解可以认为服务是一个函数，SOAP请求即发出调用该函数的指令而 SOAP反馈则是函数调用的结果。显然，在这种计算模型下，将大规模的二进制多媒 体数据作为参数传进函数是不现实。在一般的编程模型中，如果需要让函数处理大 规模数据例如将一个AVI编码的影片转码为FLV格式， 一般是将数据存储起来然后 将文件的名称作为参数传递给函数，从而使函数可以索引到该文件并进行处理。本 实施例所定义的SOAP扩展源于该思想。本实施例所扩展的远程对象访问模型的形 式化描述如下定义l: 一个扩展SOAP请求是一个4元组(N， M， P， R)，其中N为服务 的命名空间；M为服务的名称；P为服务的参数集合，其元素为二元组(pj , vj ) (j >0)，其中pj为参数名称，Vj为pj的实例值；R附件与参数的关联关系集合,其元素
为二元组(am,fm)(m >0)，其中ake(pl, p2 ,…，pj } (k《m)， fk为与参数ak 相关的附件；以lakl和lfkl分别表示ak和fk中在R中的出现次数，要求ak必须满足 |ak|》0 ， fk必须满足lfklE(0,1)。
根据这个定义，当R为空时，本实施例所定义的扩展SOAP请求将退化为标准 的SOAP请求，因此标准SOAP请求实际上是扩展SOAP请求的一个特例。
定义2: —个扩展SOAP反馈是一个4元组(N， ， M， ， V, R，)，其中N， 为服务的命名空间；M'为产生该反馈的服务的名称，必须与定义1中的M对应； V为服务的返回值；R'为附件与参数的关联关系集合，其定义同R。
由于反馈是基于请求的，因此定义2是依赖与定义1的。显然，上述扩展是完 全兼容当前SOAP标准的。下面基于这两个定义，给出具体的扩展SOAP消息格式。
消息格式
目前SOAP消息一般通过HTTP协议进行传输，即将SOAP消息封装到HTTP 协议数据包中进行传输。通过HTTP传输可以使SOAP消息穿越大部分的防火墙， 从而增加了 Web Service的可用性；另一方面，通过在通用的Web服务器中增加SOAP 处理模块即可使其支持Web Service应用，避免了为Web Service设置专门的服务器。 鉴于SOAP HTTP绑定的上述优点，本文所定义的扩展SOAP消息仍使用HTTP协议 进行传输。 一个根据定义1使用HTTP POST方式提交的扩展SOAP请求消息示例， 如下所示POST /UpLoadService.ews HTTP/1.1 Host: www.tempuri.org Content-Type: text/xml; charset=utf-8 Content-Length: length
SOAPAction: "http:〃tempuri.org/UploadMovie"
< xml version="1.0" encoding="utf-8" > <esoap:Envelope
xmlns:xsi="http:〃www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http:〃www.w3.org/2001/ XMLSchema" xmlns:esoap="http:〃dsp.ac.cn/enhanced-soap/envelope/"> <esoap:Body>
<UploadMovie xmlns="http:〃tempuri.org"> <Provider>China Movie Group</Provider> <Name>Warm Spring</Name> <Prevue>Girl， don't cry!</Prevue> <Tag>Ch'ma story </Tag> </UploadMovie> <esoa p: Atta ch ments> <Name>
<esoap:File>video-cd1.avi</esoap:File> <esoap:File>video-cd2.avi</esoap:File>
</N3IT16> <Pr6VU6>
<esoap:File>summary.flv</esoap:File> </Prsvu6> </esoap:Attachments> </esoap:Body> </esoap:Envelope>
--attachment part—
上面代码示出的消息是一个上载电影服务请求消息。该消息包含两个部分 HTTP协议报头和扩展SOAP请求消息。其中HTTP头部指明了服务的地址 "www.tempurl.org/UpLoadService.ews"，它实际上指明了 SOAP服务器所应该加载 的服务组件，在这个例子中对应的组件是"UpLoadService.ews"，所要调用的服务 必须在该组件中定义。扩展SOAP请求消息包含两个部分消息主体和附件部分。 上文只列出了消息的主体部分，附件部分将在下文给出。消息主体指明所要调用的 方法为"UploadMovie"，它有四个参数Provider、 Name、 Preview禾卩Type,分别 表示影片的提供者、名称、预告片名称和所属分类信息；其中参数Name和Preview 关联附件，即电影的视频文件以及预告片的视频文件。Attachments元素用于定义与 调用方法相关的附件集合，其子元素必须是参数的名称，每个参数可以关联一个或多个附件，每个附件使用File元素进行声明。在上面的例子中，参数Name关联两 个附件，分别是video-cd2.avi和video-cd2.avi，它们是所要上载影片对应的两个视频 文件；参数Preview关联一个附件summary.flv，它是影片预告片对应的视频文件。
对于每一个在扩展SOAP消息主体中指明的附件，在消息的附件部分必须有一 个对应的实体。在上文示例扩展SOAP请求消息中附件video-cdl.avi的实体部分如
下所示
—boundary— Content-Type: video/avi Content-Length: 987786786 filename: video-cd1.avi EBS: 4096
Encryption-Algorithm: AES Encryption-Key: eweff 78y78JKJHHhjhff… Key-Size: 128 Encryption-Intensify: 10% —boundary-binary data ( of video-cd1 .avi)
另两个附件的情况是类似的。每个附件实体包含两部分信息附件元数据信息 和附件文件所包含的二进制数据。这两部分信息之间存在边界，不同的附件实体之
间也存在边界。与带附件SOAP和XML 二进制优化数据打包方法将二进制数据转码 成文本打包到SOAP消息体中不同，本实施例对于不同边界隔开的内容分段打包进 行发送，并且对于二进制数据采用直接发送方式。在元数据部分，域Content-Type 用于表示附件的文件类型，文件类型定义依据MIME媒体类型；域Content-Length 用于表示附件的大小，单位为字节；域filename为附件文件的名字，该名字必须在 消息主体的File元素中出现。最后5个域是为保护多媒体内容而设立的。由于，多 媒体内容涉及版权问题，安全等级较高，因此本实施例在定义服务与客户端的交互 模型时， 一并考虑了安全问题，具体将在下文介绍。域EBS为附件加密处理时的数 据块大小，是服务器对附件解密所必须的；域Encryption-Algorithm为附件进行加密 处理时所采用的加密算法；域Encryption-Key为加密附件所采用的密钥，对于附件 内容采用对称加密方式，但是密钥是以密文形式传输的；域Key-Size为密钥长度； 域Encryption-Intensity定义了加密强度，它定义了加密数据块中的哪些比特将被加 密。
服务端根据客户端的扩展SOAP请求消息，调用相应服务并获得计算结果后， 将向客户端发送反馈消息，该消息也可能包含附件。 一个根据定义2基于HTTP绑定的扩展SOAP反馈消息示例如下所示
<Name〉String</Name> <Prevue〉String</Prevue>
</Up〗oadM o v i e〉 <Attachments> <Relation〉
<Parameter>Name</Parameter> <Note>using for specifying the video
files of the movie </Note> </Relation> <Relation>
<Parameter>Prevue</Parameter> <Note>using for specifying the video
file of the movie abstract </Note> </Relation> </Attachments>
上面代码示出的消息是一个视频转码服务的反馈消息，服务的名称是
VideoTranscode，服务的返回值为真表示转码成功，这与标准SOAP是一致的；返回 结果中还包含了两个附件，就是转码之后得到的视频文件，使用服务定义的参数 Contentld进行关联。反馈消息附件部分格式与请求消息中的附件格式是完全一致的， 不再赘述。
服务开发者必须在其服务的WSDL描述中指明哪个参数将关联到附件，并必须 对这种关联的含义进行注释，例如说明与某个参数关联的附件的作用。如此，服务 调用者在调用服务前通过查看服务的WSDL描述即可了解向服务提供输入数据的方 法。通过这种方式，在扩展SOAP请求消息符合服务的WSDL描述时，服务即可自 动化的确定每个提交附件的角色(即确定每个提交附件的作用)并进行处理。例如， 在上文例子中，服务可能对Name参数关联的附件进行加密，而对于Preview参数关 联的附件则不做该处理。为使WSDL能够支持服务参数的附件关联声明，本实施例 对WSDL标准进行了扩展。如果服务需要调用者以附件形式提供数据或者服务的返 回结果中包含参数，则必须在其WSDL描述中指明参数与附件的关联关系。为此， 本实施例对WSDL进行了扩展，引入了 3个新的元素，分别是Relation、 Parameter 和Note。基于这三个元素在WSDL中指明参数与附件的关联关系的方法如下(1) 对于每个要关联附件的参数在服务的WSDL文档中生成一个对应的Relation元素；(2) Relation元素的第一个子元素必须是Parameter元素，Parameter元素的值为服
务所定义的输入参数中的某一个；(3) Relation元素的第二个子元素必须是Note元
素，该元素为本关联的说明信息，指明该种关联的含义。与上文例子中扩展SOAP
请求对应服务"UploadMcwie"对应的服务描述片段如下所示
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
< xml version-" 1.0" encoding="utf-8" > <esoap:Envelope
xmlns:xsi="http:〃www. w3.org/2001/XMLSchema-instance" xmlns:xsd-"http:〃www.w3 .org/2001/XMLSchema" xmlns:esoap="http:〃dsp.ac.cn/enhanced-soap/envelope/"> <esoap:Body>
<VideoTranscodeResponse xmlns="http:〃tempuri.org">
<VideoTranscodeResult>True</VideoTranscodeResult> </VideoTranscodeResponse> <esoap:Attachments> <ContentId>
<esoap:File>video—cdl—trans.flv</esoap:File> <esoap:File>video—cd2—trans.flv</esoap:File> </ContentId> </esoap: Attachments> </esoap:Body> </esoap:Envelope>
—attachment part—
上述描述片段中Attachments元素内容为扩展SOAP请求对应的的参数-附件关 联关系定义。对于每个参数附件关联关系集合，通过一个Relation元素来定义，该 元素包含两个子元素，其中Parameter指明参数名称(必须是服务的参数)，Note则 是对该关联的含义进行说明，在上文第一个Relation元素中由Parameter元素指明了 要关联附件的参数为Name,并由Note元素指明关联到本参数的附件为电影的视频 文件。服务调用者在调用服务前通过查看服务的WSDL描述判断服务请求是否需要 携带附件信息，以及获得服务反馈结果中是否包含附件。
服务调用过程
上文给出了扩展SOAP消息的格式，现在给出进行多媒体服务调用时，客户端 与服务端的交互过程。首先定义如下系统实体(1)应用程序多媒体服务的消费 者；(2)扩展SOAP客户端用于为应用程序提供透明的服务调用；G)HTTP服务 器为应用程序提供服务的接入点；(4)扩展SOAP服务器端 一个嵌入在HTTP服务器中的模块，专门用于与扩展SOAP客户端交互，完成服务调用过程；(5)服 务完成某一个功能的程序模块。在这些实体中，扩展SOAP客户端实际上并不是 一个独立的实体，它是嵌入到应用程序中的。下面基于附图1给出服务调用过程中 各实体的交互过程
步骤l、服务的消费者(可能是应用程序、业务流程引擎或其他服务等)通过调 用扩展SOAP客户端(以下简称为EC)提供的函数CallService启动一个服务的调用 过程，应用程序必须在该函数中为EC指明四个方面的内容作为其输入参数①所 要调用的服务的WSDL描述或其地址，②所要调用服务的名称；③所要调用服务 各个输入参数的实例值； 以[参数名，附件]的格式指明所要关联的附件；
步骤2、 EC针对该调用请求，首先分析应用程序输入参数是否准确，主要检查 所要调用的服务名称是否在所指定服务描述中存在，与及参数是否有遗漏、所指定 的参数附件关联关系是否遵循服务描述等，如果检査不通过则向应用程序返回输入 参数错误信息；否则，EC调用GenESQMainpart函数开始构造扩展SOAP请求消息 主体，构造完成后根据服务WSDL描述中绑定的服务地址发出该服务调用请求；发 出该请求后，如果该被调用的服务中没有指明需要附件，则EC进入接收调用反馈消 息状态，否则转到步骤5;
步骤3、服务所在的Web服务器接收到该请求后，首先检査该请求的类型，如 果不是自行进行应答，否则将该请求转发给扩展SOAP服务器模块(以下简称为ES) 处理；
步骤4、 ES调用MPAnalyze函数分析请求消息主体，如果该消息不含附件，则 转步骤10;否则，ES生成一个公开密钥对，并将公钥发送给EC， ES等待接收EC 发送的附件；
步骤5、 EC等待ES发送本次会话所需要的公钥，并接收该公钥，设置/=1;
歩骤6、 EC首先为应用程序所指定的第/个附件生成加密密钥，之后调用 GenFileMetadata函数生成附件元数据信息各个域的值，其中加密密钥使用ES发送的 公钥进行加密，生成完成后将该消息发送给ES;
歩骤7、 ES收到附件元数据信息后，调用GetAttachmentlnfo函数解析出各个对 应域的信息，并使用其第4歩所生成公钥对的私钥对附件的加密密钥进行解密，其 后开始等待接收附件所包含的二进制数据；
步骤8、 EC从附件文件中顺序读取EBS域所指大小的数据块，使用附件加密密 钥进行加密后后发送给ES，ES接收该数据块后使用其解析出的附件加密密钥进行解 密并存储，该过程持续进行直至整个附件数据发送完毕——ES根据附件的大小来确定该附件是否接收完毕；本步骤中附件数据块进行加密的算法如下
假设附件的加密秘钥为K(K至少为128位)，按从左到右顺序表示成, 其中A包含K中的第x64至!'x64—l比特位，设V^y^Orv4w-7 ， C2=X7 ， (3-产』2 ，则第m (0S")个将被发送的附件数据块的加密密钥C^由下列公式计算获 得
C KCW—,+ Cw—:)ModM ， m兰0 (1) 上述公式中进行加法运算时默认将比特串转换为对应的无符号整数。计算出Cw 后，对第m个数据块进行加密的算法如下所示(em为将被加密的数据块)
Algorithm泣reaw五尸L/Ewco^ (SharedKey: K， PrivateKey: cm, EPU: em ) begin
D=uint(cm).
while( D>0 ) R=DModN.
e,e,+jR ,/ E
D=D/ N. end while end
上述算法中调用了函数五co^km五/^/(X:, ej，该函数用于对加密数据进行预处 理，实际上是一个加扰的过程，具体算法如下(EI为附件元数据信息域 Encryption-Intensity所指明的加密强度值)
Algorithm五c，"'o"五尸C7 (EncryptionKey: K, EPU: e )
begin
uint loop = (K丄e"g&仍x(uint) (100 / EI). b=0.
while ( b< e丄e/ g^(9 ) te丄e"g决(9 二 b . r = t > K丄e"gr/z(9 K』e"-(9 ， t. for (i = 0; i < r; i++) e&+>= e&+,. Xor K,. cud for b=b+loop. end while
end步骤9、检查是否还有别的附件要发送，如果有设置并转到步骤6，否则 表示整个扩展SOAP请求接收完毕，转下一步骤；
步骤IO、在扩展SOAP请求中抽取出服务所在模块名称，以该名称为参数调用 ServiceModelarLoad函数动态加载该模块到ES中；
步骤ll、在扩展SOAP消息中抽取出调用服务的名称和各个参数的值，以其为 参数在上一步骤所加载模块中调用相应的函数，并获得函数的返回值；
在多媒体应用领域，附件作为函数的输入数据是非常普遍的，这导致扩展SOAP 服务器与服务所在组件之间的交互比目前标准的SOAP调用远为复杂首先附件信 息必须有效的传递给服务，其次如果服务返回结果中包含附件则服务还必须将附件 信息提供给服务器。为此，本实施例要求服务(函数)所在的类必须按照以下模版
进行开发
public class ClassName
public ClassName ( string ESQMB )
{ …." }
public string GetAttachmentlnfo ()
{ ...... }
......〃service functions
即首先必须定义构造函数，通过该函数扩展SOAP服务器通过该函数将经过更 新(主要是将附件在服务器中的路径信息添加到Attachment元素中)的SOAP请求 消息头部作为参数传递给服务，以此使服务可以存取附件；其次，必须定义 GetAttachmentlnfo函数，扩展SOAP服务器通过调用该函数査询服务反馈中是否包 含附件；
步骤12、ES调用函数GenESSMainPart产生服务调用反馈消息头部并发送给EC， 然后ES调用函数GetAttachmentlnfo检查服务是否有附件需要返回给服务调用者， 如果没有附件返回，ES直接关闭与EC的连接，否则发送完附件后关闭该连接(如 果有附件需要返回则附件的发送过程与上面EC发送附件给ES的过程一致)；
步骤13、 EC接收ES发送的扩展SOAP请求反馈消息后，抽取出调用结果并返 回给应用程序，结束服务调用过程；
附图1给出了一个基于上述过程的服务调用示例时序图，该例子中服务请求和 反馈中都包含了一个附件。上述服务调用过程中服务器端的主要活动列于附图2。服 务器端是一个包含扩展SOAP服务处理单元的通用HTTP协议服务器。服务器启动后，开始侦听来自客户端的请求，如果该请求是服务调用请求则将由扩展SOAP服 务处理单元进行处理。扩展SOAP处理单元首先对请求消息进行分析，如果该请求 中包含附件则启动附件接收过程。首先扩展SOAP处理单元生成用于本次会话的公 开密钥对，并将公钥发送给客户端，客户端将使用该公钥加密每个附件的对称加密 密钥。每个附件的接收过程包含两个步骤(1)接收客户端发送的附件元数据信息， 并抽取接收附件数据所需的密钥和文件长度等信息；(2)按照附件元数据信息中指 明的数据块规模，逐块接收并解密附件的二进制数据，直至指定的文件长度。接收 完所有附件之后根据服务请求所指明的服务加载相应的软件模块，完成服务对应函 数的调用，并将服务的调用结果进行封装生成服务反馈消息并发送给客户端。如果 反馈消息中包含附件，则扩展SOAP处理单元发送完反馈消息头部后，开始等待客 户端发送其公钥(客户端接收反馈消息头部后，经分析若发现反馈消息中包含附件， 则它将生成本次会话所用的公开密钥对，并将公钥发送给扩展SOAP处理单元)；接 收该公钥后，对每个需要发送的附件使用以下步骤进行发送(1)生成一个附件加
密所用的对称密钥，并使用接收到公开密钥进行加密，之后构造附件元数据信息，
并发送给客户端；(2)按照附件元数据信息中所指明的加密数据块大小，逐块读取 附件数据加密后发送给客户端，直至发送完所有的附件数据。
本发明给出了一种兼容WebService现有标准的支持数据密集型多媒体服务远程 调用的扩展SOAP模型，基于该模型给出的方法可在多媒体业务的开展中采用面向 服务架构技术通过服务组合的方式迅速的开发新业务与及与其他类型的信息服务进 行集成；同时在面向服务架构下由于各个功能组件(服务)相对独立(松耦合)，这 有利于降低系统的维护和升级成本。与带附件SOAP消息和XML 二进制数据优化打 包技术进行相比，采用本发明给出的方法在进行数据密集型多媒体服务调用，由于 不需要将二进制数据转码成文本并打包，因此不会导致突发地大量内存的占用同时 极大地降低了服务调用的等待时间。在本发明的实现系统中，对于同一服务其等待 时间縮短50%以上。另一方面，本发明将数字内容的保护纳入到整个多媒体服务调 用框架之中，避免了使用WS-Security进行整体消息加密所带来的低效率，同时可以 使应用程序设计者摆脱复杂的内容安全议题，专著于业务设计。基于多媒体数据时 空相关性强这一特征，本发明使用数据位交错结合异或运算，达到仅加密部分数据 获得接近完全加密(从内容解码的角度)的效果；并且，用户可根据不同的内容等 级设置不同的加密强度， 一般加密强度在30%左右即可达到完全加密的效果，此时 与采用AES进行完全加密方法相比，可节省约80%的数据加密时间。
权利要求
1、一种基于扩展SOAP的数据密集型多媒体服务调用方法，涉及的实体包括扩展SOAP客户端和扩展SOAP服务器端，所述多媒体服务调用方法包括如下步骤1)扩展SOAP客户端向扩展SOAP服务器端发送扩展SOAP请求消息，所述扩展SOAP请求消息包括消息主体部分和附件部分，所述消息主体部分包括所请求服务的名称，所请求服务的参数名称和实例值，以及所述参数名称与附件的关联关系；所述附件部分包括与所述消息主体部分所请求服务的参数名称相关联的附件实体，所述附件实体包括附件元数据信息和附件文件所包含的二进制数据；2)扩展SOAP服务器端接收到所述扩展SOAP请求消息，调用该请求消息中所请求的服务对应的功能函数并获得计算结果，所述计算结果包括需返回的函数返回值与及某些可能的经过处理的附件数据；3)扩展SOAP服务器端向扩展SOAP客户端返回扩展SOAP反馈消息，所述扩展SOAP反馈消息携带步骤2)中得到的计算结果。
2、 根据权利要求1所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，所述服务的WSDL描述中指明该服务中的参数与附件的关联关系。
3、 根据权利要求2所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，所述服务的WSDL描述中包括元素Relation、 Parameter禾B Note;所 述Relation、 Parameter和Note用于在WSDL中指明参数与附件的关联关系；对于每 个要关联附件的参数，在服务的WSDL文档中生成一个对应的Relation元素;Relation 元素的第一个子元素是Parameter元素，Parameter元素的值为服务所定义的输入参数 中的某一个；Relation元素的第二个子元素是Note元素，该元素为本关联的说明信 息，指明本关联的含义。
4、 根据权利要求3所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，涉及的实体还包括应用程序，所述歩骤l)之前，还包括如下步骤应用程序启动服务调用过程，向扩展SOAP客户端指明服务调用信息，所述调 用信息包括所调用的服务的WSDL描述或其地址，所调用服务的名称，所调用服务 的各个输入参数的实例值，以及参数与附件的关联关系。
5、 根据权利要求4所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，所述步骤O中，所述扩展SOAP客户端根据所述应用程序所指明的信 息构造所述扩展SOAP请求消息。
6、 根据权利要求1所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，所述扩展SOAP请求消息通过Web服务器转发给扩展SOAP服务器端。
7、 根据权利要求1所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，所述歩骤l)中，所述扩展SOAP客户端首先发送消息主体部分，然后 再发送附件部分。
8、 根据权利要求1所述的基于扩展SOAP的数据密集型多媒体服务调用方法， 其特征在于，所述步骤3)中，所述计算结果包含附件时，所述扩展SOAP反馈消息 包括消息主体部分和附件部分，所述计算结果不包含附件时，所述扩展SOAP反馈消 息包括消息主体部分，不包括附件部分；所述步骤3)中，扩展SOAP服务器端首先 发送消息主体部分，然后查询计算结果中是否包含附件，当包含附件时，所述扩展 SOAP服务器发送附件部分，否则，断开与所述扩展SOAP客户端的连接。
9、 根据权利要求7或8所述的基于扩展SOAP的数据密集型多媒体服务调用方 法，其特征在于，所述附件部分进行加密传输，加密方法是使用一个全局密钥对数 据块中的数据进行有选择的加密，并使用一个与每个数据块对应的流式密钥对各数 据块进行交错加密处理。
全文摘要
本发明涉及一种基于扩展SOAP的数据密集型多媒体服务调用方法，涉及的实体包括扩展SOAP客户端和扩展SOAP服务器端，所述调用方法包括1)客户端向服务器端发送扩展SOAP请求消息，该消息包括消息主体部分和附件部分，所述消息主体部分包括所请求服务的名称，所请求服务的参数名称和实例值，以及参数名称与附件的关联关系；所述附件部分包括与所请求服务的参数名称相关联的附件实体，所述附件实体包括附件元数据信息和附件文件所包含的二进制数据；2)服务器端接收到所述扩展SOAP请求消息，调用该消息中所请求的服务对应的功能函数并获得计算结果，所述计算结果包括需返回的函数返回值和某些可能的经过处理的附件数据；3)服务器端向客户端返回扩展SOAP反馈消息，该消息携带步骤2)中得到的计算结果。
文档编号H04L12/18GK101645785SQ20091008330
公开日2010年2月10日 申请日期2009年4月30日 优先权日2009年4月30日
发明者李松斌, 王劲林, 邓浩江, 君 陈 申请人:中国科学院声学研究所