专利名称：数据处理方法、程序、装置、消息结构、消息生成方法及消息发送方法
技术领域：
本发明涉及数据处理方法、程序、装置、消息结构、消息生成方法及消息发送方法。
背景技术：
图1图示了现有技术中的、使用客户机服务器方式下的消息的分布式处理的概要。
服务器S1、S2和客户机C1分别具有处理程序P1、P2、P3。然后，通过在客户机C1和服务器S1、S2之间收发消息M1来分布式地执行处理，所述消息M1的内部仅保存成为该处理程序的处理对象的数据D1。
当在分布式处理中以消息为基础时，所收发的消息M1只是数据。因此，即便服务器S1和S2是在互不相同的计算机语言或操作系统和服务器软件等执行环境下被构成的情况下，客户机C1和服务器S1或S2也能使用相同的消息M1。在该图中，具有执行环境E1和执行环境E2二种相互不同的执行环境的节点混合存在于客户机和服务器内。
但是，在该方式中，若使原消息内不仅包含数据还包含程序地进行发送接收，则产生了服务器侧和客户机侧的执行环境、特别是程序处理环境必须相同的问题。这是因为虽然可以在任意的编程语言、计算机环境中执行对数据的解释，但是程序的执行以依赖于该程序的描述计算机语言的执行环境为必要条件。由此，在以消息交换为基本的分布式处理技术中存在在可以执行程序收发的情况下失去了所谓的“不同环境下的混合处理”的优点的问题。
作为有关分布式处理的已有技术，具有例如特开2003-157178号公报(专利文献1)。该技术在客户机和服务器中的处理调用中，通过对参数(数据)执行XML变换，使得与互联网环境的协作变得容易。但是，利用该技术，只不过仅对请求的参数执行XML化，并不能最终解决用以执行数据和程序混合存在的对象的环境在发送侧和接收侧必须一致的问题。
作为解决这样的问题的手段，我们还考虑通过在执行环境上再叠加一个虚拟的执行环境(虚拟机·VM)来构筑共用的执行环境。但是，由于这不过使结局处的执行环境易于变为相同，而计算机语言自身的标准还使用了以往类型的描述方式，从而在现实中存在发生了如下所述的、消息中的数据和程序的描述方式不匹配的问题。
还存在作为计算机中分布式处理的构筑手法的Web服务技术。在Web服务技术中，利用作为可扩展的置标语言的XML(eXtensibleMarkup Language)来描述消息。所谓XML是由WWW联盟(W3C)在1998年以在互联网上活用结构化文档为目标而制定的语言。关于XML，可参照http//www.w3.org/XML/下的标准。在Web服务技术中，将利用XML如此描述的消息的标准称为SOAP(Simpie ObjectAccess Protocol)。SOAP确定了消息的描述标准，是关于表明对什么样的数据如何进行表达的方法的规定。通过使用Web服务技术中的SOAP，能够容易地实现图1的分布式处理。SOAP也与XML一样，由WWW联盟(W3C)公开其标准，可参见http//www.w3.org/TR/SOAP/下的内容。
在使用了Web服务技术的消息收发中，以使用用XML描述的SOAP为基础。利用了XML的SOAP还可以将消息作为结构化文档来处理。也可以将消息视为文档，与其任意部分相关地随意执行处理。
发明内容
发明所要解决的问题如此，在使用了SOAP的消息收发中，将XML文档这种架构(枠組み)作为消息的格式而予以维持是非常重要的。但是，由于彼此具有上述的虚拟执行环境，若在SOAP的结构中收发程序，则使仅仅是程序的描述位置部分脱离XML架构的问题显著化。
这是因为程序的描述方法本身并不特别考虑与XML的亲和性，有必要使用已有类型的描述方法。特别是在利用了以SOAP或XML文档流通为前提而构筑的Web服务技术的各节点中，这一点引发了在消息的内容中包含有不能解释的部分的状况。因此，丧失了SOAP的、所谓使用部分加密和签名等的XML进行通信传递(messaging)的优点。
在生成虚拟环境以使程序运行的方式中，由于必须假定虚拟环境可执行该计算机语言中可描述的全部程序，因此存在不能实现不会变为较大的目标，需要丰富的计算机资源的问题。即，还存在不能忽视由于需要构筑与本来的计算机环境不同的其他多重计算机环境而造成的资源溢出的问题。
若是采用覆盖到所有真正的处理的描述的语言，则也大多是采用编译方式的情况，在这种情况下，在执行时还需要进一步承担编译处理的负担。在以二进制形式发送编译完毕的对象的情况下，还会发生在执行前不能确认执行内容这样的问题。
解决问题的手段为了解决上述问题，本发明的数据处理方法、数据处理程序、数据处理装置接收具备数据部、标准部及程序部的消息，其中所述标准部表示处理所述数据部的标准，而所述程序部包含用以执行由所述标准部所示的标准的处理的命令；在执行包含在接收到的所述消息的程序部内的命令时，决定表示通过所执行的命令而进行的处理的标准的标准部；和按照由所述消息中被确定为表示通过所述执行的命令而进行的处理的标准的标准部所示的标准，来处理所述数据部。
本发明的消息结构具有数据部、表示处理所述数据部的标准的标准部、以及程序部，其特征在于，所述程序部包含表示按照所述消息中的标准部所示的标准来处理所述数据部的命令。
发明效果根据本发明，在消息中具备数据部、标准部和程序部，通过利用消息中的标准部来定义由程序部执行的处理的标准，能够在描述消息的架构的范围内描述程序和必要的数据。
根据本发明，可以使用较少的计算机资源来执行程序。本发明的其他特征和优点将通过参照附图而做的以下说明变得更加明了。在附图中，对于相同或同样的结构，赋予相同的参考标记。
图1是关于已有技术中的、在计算机之间的分布式处理的示意图。
图2是关于依据本发明实施方式的消息处理概要的示意图。
图3是依据本发明实施方式的、利用PC(个人计算机)等计算机系统构成了客户机和服务器时该计算机系统的方框图。
图4A、4B是关于依据本发明实施方式的处理概要的流程图。
图5是关于依据本发明实施方式的处理细节的流程图。
图6是关于依据本发明实施方式的处理细节的流程图。
图7是关于消息结构的具体例子的示意图。
图8是关于依据本发明实施方式的消息结构的具体例子的示意图。
附图标记的说明P1 程序部R1 虚拟服务部D1 数据部P2 SOAP处理程序P4 虚拟服务处理程序P5 服务协作处理程序
具体实施例方式
下面，将参照附图详细说明本发明的一种实施方式。尽管还一并记载了具体的处理例，但是，本发明并不限于该具体的处理例。
图2示出了本实施方式下的消息收发的概要。首先，说明SOAP消息的概要。SOAP消息M1由包络(envelope)部、头部、以及主体(body)部构成。在包络部、头部按与已有技术相同的内容构成时，不对以SOAP为处理对象的已有处理系统请求变更。在本实施方式中，在主体部中，除通常按SOAP存储的数据部D1之外，还存储虚拟服务部R1及程序部P1。
首先，客户机C1决定想在外部处理系统(服务器S1)中执行的处理，并在SOAP处理程序P3中生成SOAP消息M1。此时，不仅存储数据D1，还存储表示希望如何处理该数据D1的程序P1。此时，程序P1是利用服务协作描述语言来描述的，所述服务协作描述语言是与使用了XML的SOAP消息的亲和性高的计算机语言。这一点将在后面进行详细的说明。
此后，客户机C1将消息M1发送到服务器S1。进行接收的服务器S1在是常规的SOAP消息时利用SOAP处理程序P2来执行处理，而在是内包有程序P1的SOAP消息的情况下，将处理转到虚拟服务处理程序P4。虚拟服务处理程序P4通过存储在消息内的虚拟服务部R1，将程序部P1和作为处理对象数据的数据D1连结在一起。之后，利用服务协作处理程序P5来执行程序P1。之后，将执行后的结果从服务器S1返回到客户机C1。
图3示出了依据本实施方式的、使用PC(个人计算机)等计算机系统来构成客户机C1和服务器S1时该计算机系统的方框图。
在图3中，301是对计算机系统进行控制的中央运算装置(以下记为CPU)。
302是随机存取存储器(以下记为RAM)，用作CPU 301的主存储器，并用作执行程序的区域、该程序的执行区及数据区。
303是记录有CPU 301的操作处理过程的只读存储器(以下记为ROM)。ROM 303包括程序ROM，它记录作为执行计算机系统控制的系统程序的基本软件(操作系统，OS)；以及，数据ROM，它记录用以运行系统所必需的信息等。也可以使用后述的HDD 309来代替ROM 303。图2中客户机C1的SOAP处理程序P3也记录在客户机C1的ROM 303或者HDD 309内。另外，服务器S1的SOAP处理程序P2、虚拟服务处理程序P4、服务协作处理程序PS也记录在服务器S1的ROM 303或者HDD 309内。
304是网络接口(以下记为NETIF)，用于诊断用以经由网络与其他计算机系统之间执行数据传输的控制和连接状况。图2中的客户机C1通过客户机C1的NETIF 304向服务器S1发送SOAP消息M1，图2中的服务器S1通过服务器S1的NETIF 304接收SOAP消息M1。图2中的服务器S1将接收到的SOAP消息M1存储在SOAP消息M1内。
305是视频RAM(以下记为VRAM)，用于展开在示出了计算机系统的运行状态的CRT 306的画面上所显示的图像并进行其显示控制。306是显示装置，例如是显示器(以下记为CRT)。307是对来自后述的外部输入装置308的输入信号执行控制的控制器。
308是用于接受计算机系统的使用者对计算机执行的操作的外部输入装置，例如是键盘等。
309是用于程序、图像信息等数据保存用的存储装置。例如是硬盘等。
310是外部输入输出装置，用于输入输出例如软盘(注册商标)，CD-ROM驱动器等可移动盘。用于从媒体中读出上述应用程序。以下记为FDD。
HDD 309内存储的应用程序和数据也可以保存在FDD 310内使用。300是用于在上述各块之间执行连接的输入输出总线(地址总线、数据总线、以及控制总线)。
图4A、图4B以流程图的形式示出了客户机C1、服务器S1的处理步骤。图4A表示客户机C1所具有的程序的一部分，图4B表示服务器S1所具有的程序的一部分。客户机C1的CPU 301从ROM 303或HDD 309中读出该程序，然后执行图4A所示的操作。服务器S1的CPU 301从ROM 303或HDD 309中读出该程序，然后执行图4B所示的操作。
首先，在图4A的步骤S301中，客户机C1决定想在外部处理系统(服务器S1)中执行的处理。该处理例如是基于来自外部输入装置308的输入而决定的。
接着，利用SOAP处理程序P3生成SOAP消息M1。即，首先，在步骤S302中，将数据D1保存到SOAP消息M1的主体部内。然后，在步骤S303中，生成表示希望如何处理该数据D1的程序P1以及虚拟服务部R1，并将其保存到SOAP消息M1的主体部内。关于步骤S303的处理，后面将会有更详细的描述。虚拟服务部R1是表示处理数据D1的标准的标准部。
接着，在步骤S304中，客户机C1通过客户机C1的NETIF 304，将SOAP消息M1传送到服务器S1。
服务器S1在图4B的步骤S305中，利用SOAP处理程序P2来接收该消息。即，利用SOAP处理程序P2来处理通过服务器S1的NET1F 304而接收的消息M1。
之后，在步骤S306，判断是否是常规的SOAP消息，若是常规的SOAP消息，则在步骤S307，利用常规的SOAP处理程序P2来执行处理。
在步骤S306中，若判断为内包有程序P1，则将处理转到虚拟服务处理程序P4。之后，在步骤S308中，虚拟服务处理程序P4根据消息M1内所存储的虚拟服务部R1的信息来取得构成虚拟服务所必需的信息，并在步骤S309中构筑用于将程序部P1和作为处理对象的数据的数据D1连结在一起的虚拟服务。之后，在步骤S310中，将该信息发送到服务协作处理程序P5。在步骤S311中，服务协作处理程序P5执行程序P1。之后，在步骤S312中，将执行后的结果从服务器S1返回客户机C1。关于步骤S309，后面将进一步详细描述其处理。
下面说明在上述实施方式中，在客户机C1生成SOAP消息M1时，用作程序P1的描述语言的服务协作描述语言。在本实施方式中，所谓服务协作描述语言是指在Web服务技术中供服务协作用的协作描述语言。即，是用于在Web服务技术中，逐次调用提供多个服务一侧的功能、或在其处理结果中，一边执行条件分支一边执行特定的更大处理的技术。作为具体技术，可以举出被称为BPEL4WS或WSCI的技术。
所谓BPEL4WS是Business Process Execution Language forWeb Service(BPEL4WS)的缩写，是作为用于使多个服务协作的复合服务描述的基准而占有一席之地的服务协作描述语言。标准是由OASIS(http//www.oasis-open.org/)的OASIS Web Services BusinessProcess Execution Language TC管理着。在使用BPEL4WS时，生成例如对Web服务调用的执行、数据的操作、故障(fault)的通知、或过程的结束等各种活动，并通过使这些活动连结在一起，可以生成复杂的过程。这些活动能够嵌套在定义了其执行方法(例如是顺序执行、并行执行、还是基于特定条件来执行)并使之结构化的活动中。
WSCI是Web Service Choreography Interface的缩写，它同样是使复合服务协作的、用于服务描述的服务协作描述语言。标准由WWW联盟(W3C)管理，可参照http//www.w3.org/TR/wsci/。
这些服务协作描述语言中的任何一种都具有用XML描述的特征，与使用了虚拟计算机环境的已有技术相比，没有将已有类型的计算机语言存储到SOAP消息内时的问题。即，不会产生丧失如下优点的问题将已有的语言存储到作为XML文档的SOAP消息内时所产生的、作为XML的优点的、可部分处理的优点。由于即便存储了程序，也可以维持所谓的可处理整个消息的XML文档的状态，因此，与已有的常规SOAP消息的兼容性非常高，没有必要向执行例如消息传送等中间处理的节点等强行追加新的处理程序等。
但是，在使用服务协作描述语言的情况下，首先他们都以在各种Web服务技术中使提供服务的节点的功能协作为主要目的，存在不以操作存储在SOAP消息内的数据为目的的问题。即，服务协作语言只有用于推进使用了常规Web服务技术的服务器(服务提供节点)的能力，而不能执行针对存储在特定SOAP消息内的数据的推进。因此，难以原封不动地将其用作用以描述以存储在SOAP消息内的数据为对象的处理的计算机语言。
因此，在本实施方式中，还为了不对服务协作描述语言的标准和处理系统施加一切修正地实现对存储在SOPA消息内的数据的参照，通过在消息M1内设置虚拟服务部R1的同时还在服务部S1内设置虚拟服务处理程序P4来应对。按照这种方法，没有必要扩展服务协作描述语言，以往存在的服务协作描述语言的处理系统在实际安装时没有必要支持该扩展标准。
下面说明消息M1内的虚拟服务部R1、服务器S1中的虚拟服务处理程序P4在本实施方式中的具体功能和处理。如前所述，服务协作描述语言的处理对象只是Web服务技术中的服务，不具有参照或操作在SOAP消息内同时存储的数据等的功能。在本实施方式中，通过向服务协作描述语言的执行处理部(P5)提供只能应用在该SOAP消息处理中的虚拟Web服务的服务提供部，如果服务协作描述语言的处理部(P5)执行对应于常规的Web服务器的处理，则实际上实现了变换为参照或操作存储在该SOAP消息内的数据的结构。因此，在本实施方式中，能够不对服务协作描述语言的标准和处理系统施加修正，就能够实现对存在于SOAP消息内的数据部的参照或操作。
更具体地说，在构成图2中的SOAP消息M1时，将用于参照所存储的数据部D1的虚拟服务描述作为虚拟服务部R1进行存储，将程序部P1和数据部D1的关系设置为使存在于服务器S1内的虚拟服务处理程序P4能够处理。虚拟服务处理程序P4基于这些信息构筑虚拟的Web服务提供部。通过将其提供给服务协作处理程序P5，服务协作处理程序P5执行与常规的服务协作处理相同的处理，而在实际上通过虚拟服务处理程序P4实施了对数据D1的操作。该虚拟服务部R1是表示处理数据部D1的标准的标准部。
图5是为了说明本处理、以流程图的形式表示出利用SOAP处理程序P3执行的步骤S303(图4A)的进一步详细化的处理的图。在步骤S401中，获取在步骤S302中存储在RAM 302内的数据D1。在步骤S402中，生成基于在步骤S301中所决定的内容的处理程序P1，并将其存储在消息M1的主体部内。此时生成的程序P1按图2中的服务协作处理程序P5可处理的服务协作描述语言来描述。在步骤S403中，从数据D1中提取出步骤S402中所生成的程序P1使用(参照或操作)的数据。之后，在步骤S404中，求出具有变更这些数据的功能的虚拟Web服务的标准，并在步骤S405中将其做成图2的虚拟服务部R1并存储在消息M1的主体部内。
作为执行如此动态生成程序、并将其组入消息内的功能的已有技术，例如有特开2003-223376号公报。该技术使用应用程序编程模块来构筑消息的内容，代码生成程序由此自动生成用于处理客户机和服务器间的协议的个别程序。该技术是以自动生成将处理集中到作为消息传输部分的协议内的程序为目的，本实施方式中步骤S402的程序生成是实现利用计算机语言来描述处理该消息内容的方法的技术，在这一点上二者是不同的。
图6是为了说明本处理而以流程图的形式来表示利用虚拟服务处理程序P4处理的步骤S309(图4B)的更加详细的处理。虚拟服务处理程序P4在步骤S308中取得了保存在消息M1内的虚拟服务部R1的信息，在步骤S411收取该信息。在步骤S412中，根据虚拟服务部R1决定应虚拟生成的Web服务的提供功能的标准，并在步骤S413中，构成虚拟服务提供的实际功能并开始执行Web服务。由此，可以使程序部P1和作为处理对象的数据的数据D1连结在一起。接着，在步骤S310中将该信息发送到服务协作处理程序P5。在步骤S311中，服务协作处理程序P5执行程序P1。
图7是仅仅由数据构成的消息的例子。这是在作为已有技术的Web服务技术中被处理的消息，变成了基于使用了XML的SOAP而构成的消息。在SOAP中，在包络部中具有头部和主体部，进而在主体部中，保存有名称为value1和value2的内容作为数据。
图8是利用本实施方式生成的消息的例子。它示出了在保持了在作为已有技术的Web服务技术中能够进行处理的兼容性的同时，还同时保存了数据和程序。与图7相同，在SOAP消息中，包络部中具有头部和主体部，而且在主体部中，作为数据还保存有名称为value1和value2的内容。还追加了虚拟服务部和程序部。虚拟服务部是表示处理数据部的标准的标准部。
以下，说明图8中的处理SOAP消息时的实际流程。该例子示出了接受2个值、进行合计运算后返回结果的简单处理。
首先，所发送的SOAP消息与由图2中在存在于客户机C1上的执行环境E1下进行操作的SOAP处理程序P3生成的SOAP消息M1相当。
首先，在图3的步骤S301中确定想在外部处理系统(服务器S1)中执行的处理是运算2个数字的合计的处理。接下来，在步骤S302中，在SOAP处理程序P3中，与常规的SOAP消息生成处理相同地生成图7中的由要素<envEnvelope>构成的包络部、由要素<envHeader>构成的头部、由要素<envBody>构成的主体部，然后生成由要素<mdata>构成的数据部D1。另外，在数据部D1内，在要素<mvalue1>和<mvalue2>内保存了两个值100和200。
另外，在步骤S303中追加了图8中的程序部P1和虚拟服务部R1。
程序部P1的内容是计算上述2个值的合计，该程序部P1被追加到要素<pprogram>中。该程序是利用作为用XML表达的服务协作描述语言的BPEL4WS来描述的。由于此时成为对象的数据是描述在该SOAP消息的数据部D1中的要素<mvalue1>和<mvalue2>的内容，因此，为了访问这些要素的信息而在程序部P1的要素<ppartnetLinks>内嵌入对虚拟服务“virtualService”的参照。
接下来，生成了虚拟服务部R1。虚拟服务部R1由要素<vvirtualService>表示，进而根据内部的要素<vdefinitions>中的name属性，以接受先前所述的参照的形式被赋予了“VirtualService”，这样的名称。表示由虚拟服务内的访问单元返回的数据的类型的、名称为value1的消息被定义为要素<vmessage>。另外，作为对数据部D1保持的数据<mvalue1>和<mvalue2>的访问单元的getValue1和getValue2在要素<vportType>中被定义。getValue2在图8中被省略。虚拟服务部R1是表示处理数据部D1的标准的标准部。
在图8中，数据部、虚拟服务部(标准部)、程序部分别由名称为data、virtualService、program的标签来定义。
在按照这种方式生成图8所示的SOAP消息后，在步骤S304中通过客户机C1的NETIF 304而被发送。
发送出的SOAP消息由图2中服务器S1中的SOAP处理程序P2接收。即，通过服务器S1的NETIF 304接收的消息M1由SOAP处理程序P2处理。所接收到的SOAP消息M1被返回到图4B中的步骤S305之后的处理。在步骤S306中，判定程序部P1是否存在于消息M1的主体部内。图8中的SOAP消息由于在要素<envBody>内包含有要素<vvirtualServiee>和要素<pprogram>，因此，被判断为是包含虚拟服务部R1和程序部P1的SOAP消息。
这里，控制转移到图2中的虚拟服务处理程序P4。接着，在步骤S308中取得构筑虚拟服务所必需的信息。然后，在步骤S309中根据存在于图8的SOAP消息M1的主体部内的、作为虚拟服务部R1的要素<vvirtualService>的内容来决定应当构筑的虚拟服务的标准。例如，根据要素<vdefinitions>的name属性，使虚拟服务的名称为“VirtualService”。之后，图2中的虚拟服务程序P4基于所获得的标准，开始提供虚拟服务。
然后在步骤S310中，虚拟服务处理程序P4将如此构筑的虚拟服务的信息与存储在SOAP消息M1内的程序部P1的信息合在一起发送到服务协作处理程序P5。这种情况下，由于服务协作处理程序P5能够执行作为Web服务协作语言的BPEL4WS，所以作为步骤S311，开始逐次执行程序部P1内所描述的处理。此时，由存在于处理程序部P1中的<ppartnetLinks>所示的服务“VirtualService”是如先前那样构筑的虚拟服务。例如，在执行存在于处理程序部P1内的<pinvoke partnerLink＝“virtualService”operation＝“getValue1”>，服务协作处理程序P5执行对常规服务的访问过程时，实际上通过虚拟服务处理程序P4接受了该请求，并根据在SOAP消息M1的数据部D1中所描述的<mvalue1>100</mvalue>，将100作为执行结果而返回。
即，在执行<pinvoke partnerLink＝“virtualService”operation＝“getValue1”>时，首先，服务协作处理程序P5从服务的名称(“VirtualService”)开始发出用于解决服务地址的询问，假如是关于名称“VirtualService”的询问，则虚拟处理程序P4应答本地主机的地址。该本地主机的地址例如是其IPv4为127.0.0.1。在将多个虚拟服务应答(提供)给虚拟服务处理程序P4的情况下，变为IP地址与虚拟服务标识符的组合，例如变为“http//127.0.0.1/virtualService”。即，在执行在接收到的消息M1中的程序部内所包含的命令<pinvokepartnerLink＝“virtualService”operation＝“getValue1”>时，决定表示通过执行的命令而进行的处理的标准的标准部(根据服务名称(“VirtualService”)来解决服务的地址)，但在这里，消息M1中的虚拟服务部R1被决定为表示通过执行的命令<pinvokepartnerLink＝“virtualService”operation＝“getValue1”>而进行的处理的标准。
“VirtualService”是用于识别表示通过该命令而进行的处理的标准的标准部的标准部标识符。“getValue1”是用于识别处理数据的标准的标准标识符，它们分别表示消息M1中的虚拟服务部R1、以及在虚拟服务部R1中规定的数据的处理标准。“getValue1”表示从数据D1中取得数据标识符为Value1的数据。
接受该应答后，服务协作处理程序P5向该本地主机的地址请求执行存在于该服务(“VirtualService”)内的特定处理(“getValue1”)。该请求经由虚拟服务处理程序P4而被接受。虚拟服务处理程序P4在请求了处理名中以“get”为前缀(例如getValue1)的处理的情况下，检查名称为get之后的值(此时为Value1)的要素(数据)是否存在于消息M1的数据D1内。如果存在，则将其值(100)返回给服务协作处理程序P5。即，在执行所接收的消息M1中的程序部P1内包含的命令<pinvokepartnerLink＝“virtualService”operation＝“getValue1”>时，在所接收的消息中的虚拟服务部R1(标准部)表示通过执行的命令而进行的处理的标准的情况下，利用虚拟服务部R1所示的标准来处理数据部D1。这里，服务的标准对于“getValue1”而言，是从数据部D1中取得数据标识符是Value1的数据的值(100)。
这样，在针对存在于SOAP消息M1内的数据部D1内所保存的数据执行了处理之后，作为步骤S312，返回处理结果。由于该SOAP消息的处理目的是接受2个值后计算其合计，所以对100+200而言返回300。
在上述实施方式中，作为描述保存在消息中的程序部的程序的计算机语言，使用了作为服务协作描述语言的BPEL4WS，但是，不用说它也可以是WSCI等其它以服务协作描述为目的的计算机语言。此时，该计算机语言采用以Web服务作为其操作对象，并在描述中采用XML方式。
在上述实施方式中，仅仅记载了单一的客户机和单一的服务器的关系，但本发明也同样适用于多个客户机和多个服务器的关系。
本发明适用于由多个装置(例如AV装置、家用电器产品装置、计算机装置、接口装置等)构成的装置，也可以适用于由一个装置构成的装置。
上面虽然详细描述了实施例，但本发明还可以采取作为例如系统、装置、方法、程序或存储媒体(记录媒体)等的实施方式。具体而言，既可以适用于由多个设备构成的系统，也可以适用于由一个设备构成的装置。
另外，本发明包含通过将实现前述实施方式的功能的软件程序(实施方式中与图示的流程图对应的程序)直接或远程提供给系统或装置、该系统或装置的计算机读出并执行该所提供的计算机代码来实现本发明的情况。
因此，为了通过计算机来实现本发明的功能处理，安装在该计算机内的程序代码本身也是实现本发明的方案。即，本发明还包含用于实现本发明功能处理的计算机程序本身。
在这种情况下，如果具有程序功能，则也可以是目标代码、由解释程序执行的程序、提供给OS的脚本数据等形式。
作为用于提供程序的记录媒体，包括例如软盘(注册商标)、硬盘、光盘、磁光盘、MO、CD-ROM、CD-R、CD-RW、磁带、非易失性存储卡、ROM、DVD(DVD-ROM、DVD-R)等。
作为其它提供程序的方法，也能够通过使用客户机计算机的浏览器而连接到互联网的主页上，并从该主页下载本发明的计算机程序本身、或者将包含压缩的自动安装功能的文件下载到硬盘等记录媒体上来进行提供。也可以通过将构成本发明的程序的程序代码分割为多个文件，从不同的主页下载各个文件来实现。即，本发明还包含针对多个用户下载用于在计算机中实现本发明的功能处理的程序文件的WWW服务器。
也可以通过对本发明的程序加密后将其存储到CD-ROM等存储媒体内，然后分发给用户，针对清除了规定条件的用户，经互联网从主页下载解密密钥信息，使用该密钥信息来执行加密程序，并将其安装到计算机内来实现。
另外，除了计算机通过执行读出的程序来实现前述实施方式的功能外，还可以由在计算机上运行的OS等基于该程序的指示来执行实际处理的一部分或全部，通过该处理来实现前述实施方式的功能。
另外，从记录媒体中读出的程序，在被写入插入到计算机内的功能扩展板和具备连接到计算机的功能扩展单元的存储器中之后，基于该程序的指示，由CPU等执行该功能扩展板和功能扩展单元等内具备的实际处理的一部分或全部，通过该处理也可以实现前述实施方式的功能。
本发明并不限于上述实施例，还考虑了各种变更和修改等。因此，本发明的技术范围是基于后附的保护范围而确定的。
优先权主张本申请要求以于2004年3月16日提出日本专利申请第2004-074536号的优先权，在此引用其全部记载内容。
权利要求
1.一种数据处理方法，其特征在于接收具备数据部、标准部及程序部的消息，其中所述标准部表示处理所述数据部的标准，而所述程序部包含用以执行由所述标准部所示的标准的处理的命令；在执行包含在接收到的所述消息的程序部内的命令时，决定表示通过所执行的命令而进行的处理的标准的标准部；和按照由所述消息中被确定为表示通过所述执行的命令而进行的处理的标准的标准部所示的标准，来处理所述数据部。
2.一种数据处理方法，其特征在于接收具备数据部、标准部及程序部的消息，其中所述标准部表示处理所述数据部的标准；在执行包含在所接收到的所述消息的程序部内的命令时，在接收到的消息的标准部表示通过所执行的命令而进行的处理的标准的情况下，按照所述标准部所示的标准来处理所述数据部。
3.一种数据处理方法，其特征在于接收具备数据部、标准部及包含命令的程序部的消息，其中所述标准部表示处理所述数据部的标准；包含在所述程序部内的命令具备标准部标识符，用于识别表示通过命令而进行的处理的标准的标准部；以及，标准识别符，用于识别处理所述数据的标准；当执行包含在所述程序部内的命令时，在基于所执行的命令具备的标准部标识符，按接收到的所述消息中的标准部所示的标准来处理数据部的情况下，基于所执行的命令具备的标准标识符，按照包含在所述标准部内的标准来处理所述数据部。
4.一种数据处理方法，其特征在于，接收具备数据部、标准部及包含命令的程序部的消息，其中所述数据部包含数据和用于识别所述数据的数据标识符，所述标准部包含表示取得具有所述数据标识符的数据的所述数据处理标准；包含在所述程序部内的命令具备标准部标识符，用于识别表示通过命令而进行的处理的标准的标准部；以及，处理标准标识符，用于识别处理所述数据的处理标准；当执行包含在所述程序部内的命令时，在基于所执行的命令具备的标准部标识符和处理标准标识符，按接收到的所述消息的标准部内所包含的处理标准来处理数据的情况下，基于所述处理标准来获取包含在所述数据部中的数据。
5.一种数据处理程序，用于使计算机执行如权利要求1到4中任一项所述的数据处理方法。
6.一种数据处理装置，其特征在于，具有接收消息的接收单元、以及处理接收到的消息的处理单元，所述数据处理装置执行如权利要求1到4中任一项所述的数据处理方法。
7.一种消息结构，它具有数据部、表示处理所述数据部的标准的标准部、以及程序部，其特征在于所述程序部包含表示按照所述消息中的标准部所示的标准来处理所述数据部的命令。
8.一种消息结构，它具有由第1标记定义的数据部、由第2标记定义的标准部及由第3标记定义的程序部，其特征在于所述标准部表示处理所述数据部的标准；所述程序部包含表示按照所述标准部所示的标准来处理所述数据部的命令。
9.一种消息结构，它具有数据部、标准部及包含命令的程序部，其中所述数据部包含数据以及用于识别所述数据的数据标识符，所述标准部包含表示取得具有所述数据标识符的数据的所述数据处理标准，其特征在于包含在所述程序部内的命令具备标准部标识符，用于识别表示通过命令而进行的处理的标准的标准部；以及，处理标准标识符，用于识别处理所述数据的处理标准。
10.一种消息生成方法，用于生成具有如权利要求7到9中任一项所述的结构的消息。
11.一种消息发送方法，用于发送具有如权利要求7到9中任一项所述的结构的消息。
12.一种用于使计算机生成具有如权利要求7到9中任一项所述结构的消息的消息生成程序。
13.一种用于使计算机发送具有如权利要求7到9中任一项所述结构的消息的消息发送程序。
全文摘要
本发明提供一种数据处理方法、程序、装置、消息结构、消息生成方法及消息发送方法。在使用SOAP的消息收发中，当收发程序时，程序的描述位置部分会脱离XML的框架，从而在消息内会包含不可解释的部分。因此，SOAP消息M1具有数据部D1、表示处理数据部D1的标准的虚拟服务部R1和程序部P1。服务器S1在执行包含在SOAP消息M1的程序部P1中的命令时，在SOAP消息M1的虚拟服务部R1表示通过执行的命令而进行的处理的标准的情况下，按照虚拟服务部R1所示的标准来处理数据部D1。
文档编号G06F13/00GK1934537SQ20058000834
公开日2007年3月21日 申请日期2005年2月18日 优先权日2004年3月16日
发明者藤井宪一, 下野雅树, 平田隆 申请人:佳能株式会社