CN1592893A - 具有万维网服务功能的图像形成装置 - Google Patents

Abstract

本发明的目的在于提供一种图像形成处理装置，应用程序不用具有与多种多样的通信协议相应的处理单元就能够发送接收数据，容易添加通信协议及应用程序。本发明的图像形成装置具有：连接请求中介单元，按照来自根据互不相同的通信协议来发送接收数据的多个各通信协议守护程序的连接通知，取代该通信协议守护程序，通过向上述应用程序通知该通信协议守护程序有连接请求来中介连接；以及共享存储器，用于在应用程序和该多个通信协议守护程序之间传递该接收数据及该发送数据，并且由上述多个通信协议守护程序共享。

Description

具有万维网服务功能的图像形成装置

技术领域

本发明涉及具有多个通信协议的图像形成处理装置，详细地说，提供一种图像形成处理装置，应用程序不用具有与多种多样的通信协议相应的处理单元就能够发送接收数据，容易添加通信协议及应用程序。此外，本发明提供一种图像形成装置，容易开发及添加提供Web(万维网)服务的应用程序。再者，本发明提供一种程序，自动生成进行Web服务的请求及响应消息的描述形式和该Web服务的程序可处理的数据形式之间的变换的程序。

背景技术

近年来，将打印机、复印机、传真机、扫描仪等装置的功能容纳到1个机壳内的图像形成装置已是众所周知。这种复合型图像形成装置在1个机壳内设有显示部、打印部及摄像部等，并且设有与打印机、复印机、扫描仪及传真机分别对应的应用程序，通过切换应用程序，使该装置作为打印机、复印机、扫描仪或传真机来工作。

然而，随着近年的因特网的普及及通信协议的多样化，市场要求具有打印机功能的上述现有复合型图像形成装置必须应付来自多种多样的接口的打印请求。在上述现有复合型图像形成装置中，为了应付这种市场要求，每当添加新接口时都个别进行支持。在个别支持的情况下，必须改动以往安装的应用程序以便支持新接口。此外，有下述等问题：为了新开发应用程序并安装，必须进行开发来支持多个接口。

此外，近年由于因特网的发展和普及，可经网络进行通信的具有打印机功能的上述现有复合型图像形成装置可经网络与设备相连，所以可望进一步根据因特网上的通信协议、即HTTP(Hypertext Transfer Protocol，超文本传送协议)进行通信控制来提供Web服务。再者，在除了基于HTTP的通信控制之外、还在HTTP的主体部中记述XML(eXtensible Markup Language，可扩展标记语言)等通用描述形式的消息来扩大被连接的设备的对象范围的倾向下，在上述现有复合型图像形成装置中，为了使执行与图像形成有关的处理的各应用程序通过基于HTTP的通信控制和XML等来进行消息交换，需要使各应用程序进行因HTTP指定的方法而异的处理、及与XML的描述有关的处理。因此，开发与Web服务对应的应用程序的开发者需要开发每个功能的程序。

在上述现有复合型图像形成装置中，在各个应用程序经网络来提供图像形成处理作为Web服务的情况下，需要对安装的应用程序进行改进，以便能够解释根据其网络协议交换的消息的描述形式。此外，在消息的描述形式是XML(eXtensible Markup Language，可扩展标记语言)的情况下，不管是将用现有开发方法开发出的应用程序改进为支持Web服务，还是向上述现有复合型图像形成装置中新添加支持Web服务的应用程序，开发者都需要XML的知识，所以难以通过现有开发方法来开发应用程序。

如上所述，基于XML的消息的数据形式和Web服务功能中的程序语言可处理的数据形式不同，所以在各Web服务功能中需要用于吸收这些数据形式的差异的机制。在开发这种用于吸收数据形式的差异的机制时，需要大量重复简单、相同的代码，具有容易因简单错误而混入程序错误(バグ)这一问题。

发明内容

因此，本发明的课题是提供一种图像形成处理装置，具有通过控制与经多种多样的接口连接的设备进行的打印数据及图像数据的发送接收来中介多种多样的通信协议和进行互不相同的图像形成处理的多个应用程序的中介处理单元，容易添加通信协议及应用程序。

此外，本发明的课题是提供一种图像形成处理装置，具有进行互不相同的图像形成处理的多个应用程序，通过使得能够单元化提供Web服务所需的处理单元并由该多个应用程序共享，容易开发及添加提供Web服务的应用程序。

再者，本发明的课题是提供一种图像形成装置，不依赖于提供多个Web服务的该图像形成装置和与其连接的设备之间交换的消息的描述形式，就能够开发可作为Web服务来工作的应用程序。

此外，本发明的课题是提供一种程序，自动生成下述程序：不依赖于提供多个Web服务的该图像形成装置和与其连接的设备之间交换的消息的描述形式，容易开发该多个Web服务的程序，变换该描述形式和该Web服务的开发程序可处理的数据形式。

这些目的通过以下说明的手段来解决。

根据本发明，具有：应用程序，执行与图像形成有关的处理；多个通信协议守护程序，根据互不相同的通信协议来发送接收数据；以及连接请求中介单元，按照来自上述各通信协议守护程序的连接通知，取代该通信协议守护程序，通过向上述应用程序通知该通信协议守护程序有连接请求来中介连接。此外，可以具有：共享存储器，由上述多个通信协议守护程序共享，用于保存接收数据及发送数据，在上述应用程序和该多个通信协议守护程序之间传递该接收数据及该发送数据。

在这种图像形成装置中，构成用中介多种多样的通信协议和执行与图像形成有关的处理的应用程序之间的连接的连接请求中介单元(请求中介守护程序7)及共享存储器(99)来控制数据发送接收的协议控制守护程序9。因此，多个通信协议的接口和各应用程序无需意识到相互的存在。因此，能够容易地向这种图像形成装置中添加通信协议及应用程序。

根据本发明，可以具有：多个方法处理单元，根据方法来进行规定的处理；和Web服务执行单元，按照处理请求，通过向与该处理请求指定的上述方法对应的上述方法处理单元分配该处理请求来执行Web服务。此外，可以具有：多个Web服务应用程序，共享同一方法中的处理，进行与图像形成有关的处理作为上述Web服务。

在这种图像形成装置中，由于将每种方法的处理单元化，所以能够由多个Web服务应用程序来共享方法特有的处理。

根据本发明，可以具有：Web服务处理单元，根据来自经网络连接的设备的请求消息来执行处理，提供其处理结果作为Web服务；和变换单元，将根据规定消息交换协议接收到的上述请求消息变换为上述Web服务处理单元可处理的处理请求，并且将从该Web服务处理单元输出的上述处理结果变换为符合该消息交换协议的响应消息。

在这种图像形成装置中，将消息交换协议规定的请求消息变换为Web服务处理单元可处理的处理请求，并且将Web服务处理单元的处理结果变换为消息交换效应规定的响应消息，所以无需这种消息交换协议的知识，就能够开发Web服务处理单元。

根据本发明，使计算机执行：元素树生成步骤，解析定义Web服务的接口的接口定义，来生成表示构成该接口定义的多个元素间的关联的第一元素树；和变换程序生成步骤，根据上述第一元素树，来生成进行执行上述Web服务的Web服务功能可处理的输入输出数据形式和用规定描述形式描述的与该Web服务有关的请求及响应消息之间的变换处理的变换程序。

在这种安装了程序的计算机装置中，能够根据定义Web服务的接口的接口定义(例如WSDL(Web Service Description Language，Web服务描述语言))，来生成进行Web服务功能的输入输出数据形式和基于规定描述形式(例如XML(eXtensible Markup Language，可扩展标记语言))的请求及响应消息之间的变换的程序(例如实施例的处理程序处理单元)。因此，能够大量地生成简单、相同的代码，所以能够消除因开发者的简单错误而混入程序错误等问题。此外，能够在短时间内生成程序，所以能够减轻开发者的负担。

附图说明

图1是本发明一实施例的融合多种图像形成功能的融合机的功能结构的方框图。

图2是图1所示的融合机的硬件结构的方框图。

图3是在进行通信控制的进程和应用程序之间进行中介的进程的处理的整体概要图。

图4是注册应用程序的注册序列图。

图5是注册应用程序缓冲器的缓冲器注册序列图。

图6是向应用程序通知请求的请求通知序列图。

图7是数据发送接收序列图。

图8是结束应用程序的连接的连接结束序列图。

图9是容易开发及添加应用程序的融合机的基本结构示例图。

图10是容易开发及添加应用程序的融合机的第一结构示例图。

图11是图10的第一结构例的处理流程图。

图12是图10的第一结构例的处理流程图。

图13是序列控制库的线程结构的示例图。

图14是序列控制库的线程结构的示例图。

图15是容易开发及添加应用程序的融合机的第二结构示例图。

图16是容易开发及添加应用程序的融合机的第三结构示例图。

图17是本发明一实施例的处理程序自动生成装置的功能结构的方框图。

图18是本发明一实施例的处理程序自动生成装置的硬件结构的方框图。

图19是说明整个处理程序自动生成处理的流程图。

图20是说明类型库生成处理的流程图。

图21是源码生成处理中的枚举类型定义生成处理的说明图。

图22是源码生成处理中的结构体的类型定义生成处理的说明图。

图23是源码生成处理中的数组的类型定义生成处理的说明图。

图24是源码生成处理中的枚举类型的函数声明处理的说明图。

图25是源码生成处理中的结构体的函数声明处理的说明图。

图26是源码生成处理中的数组的函数声明处理的说明图。

图27是说明处理程序生成处理的流程图。

图28是说明处理程序生成处理的流程图。

图29是基于WSDL的接口定义的描述示例图。

图30是基于WSDL的接口定义的描述示例图。

图31是处理程序处理单元的函数声明的说明图。

图32是Web服务功能的函数声明的说明图。

图33是输入消息的结构体定义的说明图。

图34是输出消息的结构体定义的说明图。

图35是自动生成的处理程序源码的示例图。

图36是用于实现Web服务的结构示例图。

图37是说明基于SOAP的Web服务提供处理的流程图。

图38是说明基于SOAP的Web服务提供处理的流程图。

图39是使用XML的符合SOAP的HTTP请求的描述示例图。

图40是XML处理器变换出的元素树的示例图。

图41是用于说明打印处理程序进行的元素树解析处理的流程图。

图42是Web服务功能的函数的变元的设置示例图。

图43是打印处理程序的处理结果的设置示例图。

图44是用于说明打印处理程序进行的元素树生成处理的流程图。

图45是生成的元素树的示例图。

图46是从元素树变换出的使用XML的符合SOAP的HTTP响应的描述示例图。

具体实施方式

以下，根据附图来详细说明本发明的实施方式。

[第一实施例]

融合多种图像形成功能的本发明第一实施例的图像形成装置(以下称为融合机)例如具有图1所示的功能结构。图1是本发明一实施例的融合多种图像形成功能的融合机的功能结构的方框图。

在图1中，融合机1200具有绘图仪1201、扫描仪1202、以及其他硬件资源1203等，并且包括由平台1220和应用程序1230构成的软件包1210、和融合机起动部1240。

融合机起动部1240在融合机1200的电源接通时首先作用，起动平台1220和应用程序1230。

平台1220具有：解释应用程序1230的处理请求、产生硬件资源的获得请求的下述控制服务1250；管理一个或多个硬件资源、仲裁控制服务1250的获得请求的系统资源管理器(SRM(System Resource Manager))1223；以及OS(Operating System，操作系统)1221。

该控制服务1250由多个服务模块形成，具体地说，有SCS(System ControlService，系统控制服务)1222、ECS(Engine Control Service，引擎控制服务)1224、MCS(Memory Control Service，存储器控制服务)1225、OCS(Operation panel Control Service，操作面板控制服务)1226、FCS(FAX ControlService，传真控制服务)1227、NCS(Network Control Service，网络控制服务)1228、以及IMH(Imaging Memory Handler，成像存储器处理程序)1229。其中，该平台1220具有能够通过预先定义的函数来接收来自上述应用程序的处理请求的应用程序接口。

OS 1221是UNIX(注册商标)等操作系统，将平台1220以及应用程序1230的各软件分别作为进程来并行执行。通过使用开放源码的UNIX(注册商标)，能够确保程序的安全性，并且能够支持网络，容易得到源码。再者，无需OS、TCP/IP的使用费，也容易外包。

SRM 1223用于与SCS 1222一起控制系统及管理资源，根据来自利用扫描仪或绘图仪等引擎部、存储器、HDD文件、主I/O(Centronics接口、网络接口、IEEE1394接口、RS232C接口等)的硬件资源的高层的请求来进行仲裁，进行执行控制。

具体地说，该SRM 1223判断请求的硬件资源是否可用(是否未被其他请求利用)，如果可用，则将请求的硬件资源可用的意思传达给高层。此外，也可以针对来自高层的请求来调度硬件资源的利用，直接实施请求内容(例如打印机引擎进行的送纸和成像动作、存储器保留、文件生成等)。

SCS 1222完成应用程序管理(功能1)、操作部控制(功能2)、系统画面显示(作业表画面、计数器显示画面等)(功能3)、LED显示(功能4)、资源管理(功能5)、中断应用程序控制(功能6)等多个功能。具体地说，在应用程序管理(功能1)中，进行注册应用程序、将该信息通知给其他应用程序的处理。在操作部控制(功能2)中，进行应用程序的操作部使用权的排他控制。在系统画面显示(功能3)中，按照来自具有操作部使用权的应用程序的请求内容，来显示与引擎部的状态对应的警告画面。在LED显示(功能4)中，控制警告LED、应用程序键等系统LED的显示。在资源管理(功能5)中，在应用程序用ECS来执行作业时，进行用于必须排他的引擎资源(扫描仪、订书机等)的排他控制的服务。在中断应用程序控制(功能6)中，进行用于使特定应用程序优先工作的控制及服务。

ECS 1224用于控制绘图仪1201、扫描仪1202、其他硬件资源1203等引擎部，进行图像读入和打印动作、状态通知、卡纸恢复等。

MCS 1225用于进行存储器控制，具体地说，进行图像存储器的取得及释放、硬盘驱动器(HDD)的利用、图像数据的压缩及解压等。

OCS 1226是控制操作者和主体控制间的信息传递单元-操作面板的模块，进行将操作者的键操作事件通知给主体控制的处理、提供各应用程序用于构筑GUI的库函数的处理、按各应用程序来分别管理构筑的GUI信息的处理、将显示反映到操作面板上的处理等。

FCS 1227从系统控制器的各应用程序层提供用于进行使用PSTN/ISDN网的传真发送接收、BKM(后备SRAM)管理的各种传真数据的注册/引用、传真读取、传真接收打印、融合发送接收的API (Application Program Interface，应用程序接口)。

NCS 1228是用于向需要网络I/O的应用程序提供能够公用的服务的模块组，进行将从网络一侧根据各协议接收到的数据分配给各应用程序、或者从应用程序将数据发送到网络一侧时的中介。

在本实施例中，NCS 1228用多个协议中的http(Hypertext TransferProtocol，超文本传送协议)守护程序，按HTTP(Hypertext Transfer Protocol，超文本传送协议)来控制与经因特网连接的网络设备之间的数据通信，通过函数调用来起动HTTP请求头指定的处理所需的多个Web服务，将该多个Web服务的处理结果用HTTP响应通知给该网络设备。Web服务例如根据用XML(eXtensible Markup Language，可扩展标记语言)描述的消息来进行处理。

IMH 1229将图像数据从虚拟存储区(用户虚拟空间)映射到物理存储器。按照进程的起动来进行系统调用，进行映射进程用的虚拟存储区、或者在进程结束时释放映射的虚拟存储区的处理等。

应用程序1230具有：具有页面描述语言(PDL)、PCL及脚本(PS)的打印机用应用程序-打印机应用程序1211；复印机用应用程序-复印机应用程序1212；传真机用应用程序-传真机应用程序1213；扫描仪用应用程序-扫描仪应用程序1214；网络文件用应用程序-网络文件应用程序1215；工序检查用应用程序-工序检查应用程序1216；分发用应用程序-分发应用程序1217；以及提供执行的处理结果作为Web服务的Web服务应用程序1218。各应用程序1211～1218能利用平台1220上的各进程来执行动作，所以进行画面控制、键操作控制及作业生成等的画面显示控制程序为其主体。其中，也可以经通过NCS 1228连接的网络来加载新应用程序。此外，各应用程序可以逐个添加或删除。

这里，Web服务应用程序1218是执行与通过NCS 1228通知的HTTP请求对应的处理的应用程序，其处理结果作为HTTP响应提供给通过NCS1228进行了HTTP请求的网络设备。

这样，融合机1200在平台1220上一元地进行各应用程序共同需要的处理。

接着，说明融合机1200的硬件结构。图2是图1所示的融合机的硬件结构的方框图。如图2所示，该融合机1200将操作面板1310、FCU(传真控制单元)1320、由绘图仪1201、扫描仪1202及其他硬件构成的引擎部1350、以及控制器1300的ASIC 1301通过PCI(Peripheral Component Interconnect，外部设备互连)总线等相连。FCU 1320具有用于保存接收到的传真数据的非易失性存储器1321、和用于计测FCU 1320内的时间的RTC(Real Time Clock，实时时钟)1322，通常根据G3标准来发送接收传真数据。FCU 1320还可以任选地加载G3标准和G4标准。

控制器1300在ASIC 1301上连接MEM-C 1302、HDD(Hard Disk Drive，硬盘驱动器)1303等，并且将该ASIC 1301和CPU 1304经CPU芯片组的NB1305相连。这样经NB 1305相连的理由在于，CPU 1304本身的接口未公开。

这里，该ASIC 1301和NB 1305不仅经PCI相连，而且经AGP 1308相连。这样经AGP 1308相连的理由在于，由于该融合机1200控制形成平台1220和应用程序1230的多个进程的执行，所以如果将它们通过低速的PCI相连，则性能降低。

CPU 1304用于进行融合机1200的整体控制，具体地说，在OS 1221上将形成平台1220的SCS 1222、SRM 1223、ECS 1224、MCS 1225、OCS 1226、FCS 1227、NCS 1228分别作为进程来起动执行，并且起动执行形成应用程序1230的打印机应用程序1211、复印机应用程序1212、传真机应用程序1213、扫描仪应用程序1214、网络文件应用程序1215、工序检查应用程序1216、分发应用程序1217、Web服务应用程序1218。

NB 1305是用于连接CPU 1304和MEM-P 1306、SB 1307、ASIC 1301的桥接器，MEM-P 1306是用作融合机的绘制存储器等的系统存储器，MEM-C1302是用作复印图像缓冲器、编码缓冲器的局部存储器，ASIC 1301是具有图像处理用的硬件元件的图像处理专用IC。

NB 1305经PCI总线除了与SB 1307相连之外，还与控制网络通信的NIC(Network Interface Card，网络接口卡)1311、与个人计算机相连并能够发送接收大容量图像数据的USB(Universal Serial Bus，通用串行总线)1312及IEEE1394 1313、以及可通过并行线缆连接的Centronics 1314相连。SB 1307是用于连接NB 1305和ROM、PCI设备、外围设备的桥接器。SB 1307具有计测控制器1300中的时间的RTC(Real Time Clock，实时时钟)1323。

HDD 1310是用于存储图像数据、存储程序、存储字体数据、存储表格的存储设备，操作面板1310是接受操作者的输入操作以及向操作者进行显示的操作部。

因此，在ASIC 1301中设有用于连接MEM-C 1302的RAM接口、和用于连接HDD 1310的硬盘接口，在向/从这些存储部输入/输出图像数据的情况下，输入输出目的地被切换为RAM接口或硬盘接口。

AGP 1308是为了加快图形处理而提出的图形加速卡用的总线接口，通过以高吞吐率直接存取系统存储器，使图形加速卡高速。

接着，说明应用程序1230和NCS 1228间的数据发送接收控制。

图3是在进行通信控制的进程和应用程序之间进行中介的进程的处理的整体概要图。在图3中，只图示了图1所示的融合机1200的功能结构中的主要功能结构，省略了其他功能结构。在图3中，融合机1200具有执行各种图像形成处理的应用程序1230、具有控制各种通信协议的多个通信控制守护程序的NCS 1228、以及进行NCS 1228和应用程序1230之间的接口的NAI 8，被连接在网络15上。NCS 1228具有中介守护程序9和应用程序1230的请求中介守护程序7、和由各种通信协议守护程序构成的协议控制守护程序9。协议控制守护程序9具有http守护程序2、ipp守护程序91、ftp守护程序92、USB守护程序93、IEEE1394守护程序94、以及Centronics守护程序95。

http守护程序2例如根据HTTP(Hypertext Transfer Protocol，超文本传送协议)来进行通信控制，设置网络，监视设备的状态，及与应用程序合作来发送接收基于XML的设备控制命令。ipp守护程序91根据基于HTTP的打印协议-IPP(Internet Printing Protocol)来控制打印数据的接收。ftp守护程序92根据FTP(File Transfer Protocol)来控制服务的提供。

USB守护程序93控制从用USB线缆直接连接的设备接收打印数据。IEEE1394守护程序94控制从用IEEE1394专用线缆直接连接的设备接收打印数据。Centronics守护程序95控制从用并行线缆直接连接的设备接收打印数据。

根据图3，应用程序1230经NAI 8向NCS 1228的请求中介守护程序7注册应用程序(步骤S0)。经网络15接收到连接请求后(步骤S1)，NCS 1228的协议控制守护程序9通知给请求中介守护程序7(步骤S2)。请求中介守护程序7经NAI 8向应用程序1230通知连接请求(步骤S3)。应用程序1230经NAI 8连接到协议控制守护程序9(步骤S4)。协议控制守护程序9通过与应用程序1230的连接来经网络15与应用程序1230发送接收数据(步骤S5)。

根据上述，NCS 1228与控制服务1250的其他服务的不同点在于，通过请求中介守护程序7和协议控制守护程序9这2个进程来进行通信。

NCS 1228将共享存储器用作在进程间传送大量数据的手段。共享存储器是能够从多个不同进程来存取的存储区，是NetBSD(注册商标)具备的标准功能。为了从多个进程排他地存取共享存储器，需要相互交换与数据的读写有关的信息。

用图4至图8来详细说明在图3所示的处理的整体概要中用于在NCS1228和应用程序1230间传递大量数据的序列。

图4是注册应用程序的注册序列图。在图4中，应用程序1230查询请求中介守护程序7(步骤S101)，从请求中介守护程序7收到支持的服务的通知后(步骤S102)，通过通知应用程序1230进行的服务的内容来向请求中介守护程序7注册应用程序(步骤S103)。例如，作为“数据接收服务”，注册应用程序名、假脱机功能“无”、及作业功能“无”等。

通过该注册，请求中介守护程序7在从协议控制守护程序9收到连接的通知时，能够知道应该中介哪个应用程序和哪个通知协议守护程序之间的连接。

图5是注册应用程序缓冲器的缓冲器注册序列图。在图5中，应用程序1230执行发送接收缓冲器获得处理。应用程序1230向请求中介守护程序7注册用于应用程序1230的多个发送接收缓冲器(步骤S111)，进而，打开注册过的发送接收缓冲器(步骤S112)，从请求中介守护程序7取得发送接收缓冲器管理信息(步骤S113)。此时，应用程序1230在共享存储器内保留多个发送接收缓冲器供自己专用。

图6是向应用程序通知请求的请求通知序列图。在图6中，协议控制守护程序9经网络15接收到连接后(步骤S11)，向请求中介守护程序7通知连接(步骤S12)。按照来自协议控制守护程序9的连接通知，请求中介守护程序7分配应用程序1230注册的多个发送接收缓冲器之一，通知给协议控制守护程序9(步骤S13)。

进而，请求中介守护程序7向应用程序1230通知连接，通知连接目的地(步骤S14)。按照该连接通知，应用程序1230向请求中介守护程序7许可连接(步骤S15)。然后，应用程序1230与协议控制守护程序9相连(步骤S16)。与应用程序1230相连的协议控制守护程序9是图3所示的守护程序2、91～95中的某一个。进而，应用程序1230向协议控制守护程序9设置通知定时(步骤S17)，请求开始接收来自连接目的地的数据(步骤S18)。

图7是数据发送接收序列图。在图7中，NCS 1230的协议控制守护程序9将接收数据写入到共享存储器99内的接收缓冲器97中后(步骤S21)，将写入指针移动与接收数据对应的量(步骤S22)。协议控制守护程序9向应用程序1230通知已写入到接收缓冲器中(步骤S23)。通过该通知，来通知开始写入的开始指针和结束写入的结束指针。

收到来自协议控制守护程序9的通知，应用程序1230将接收数据从共享存储器99中读出(步骤S24)，将读出指针移动与接收数据对应的量(步骤S25)。然后，应用程序1230向协议控制守护程序9通知已从接收缓冲器中读出(步骤S26)。

下面说明从应用程序1230向网络15发送数据的情况。应用程序1230将发送数据写入到共享存储器99内的发送缓冲器98中后(步骤S27)，将写入指针移动与发送数据对应的量(步骤S27-2)。应用程序1230向协议控制守护程序9通知已写入到发送缓冲器中(步骤S28)。通过该通知，来通知开始写入的开始指针和结束写入的结束指针。

收到来自应用程序1230的通知，协议控制守护程序9将发送数据从共享存储器99中读出并发送到连接目的地(步骤S29)，移动读出指针(步骤S30)。然后，协议控制守护程序9向应用程序1230通知已从发送缓冲器中读出(步骤S30-2)。

在图7中，为了便于说明，说明了在写入接收数据之后进行读出，但是也可以同时进行写入和读出。写入及读出发送数据也同样。

图8是结束应用程序的连接的连接结束序列图。在图8中，协议控制守护程序9向应用程序1230通知数据接收已完成(步骤S31)。该通知例如在网络上的连接被切断时进行。收到通知的应用程序1230判断出是切断状态，向协议控制守护程序9请求与接收到数据的守护程序切断(步骤S32)。协议控制守护程序9进行结束处理，向请求中介守护程序7通知结束(步骤S33)。

根据上述，通过在应用程序1230和协议控制守护程序9之间相互交换与数据的读写有关的信息，能够从多个进程排他地存取共享存储器99。

根据上述，根据本发明，在融合机1200中，构成用请求中介守护程序7及共享存储器来控制数据发送接收的协议控制守护程序9，该请求中介守护程序7通过控制与经多种多样的接口连接的设备进行的打印数据及图像数据的发送接收，来中介多种多样的通信协议和进行互不相同的图像形成处理的多个应用程序之间的连接。因此，多个通信协议的接口和各应用程序无需意识到相互的存在。因此，能够容易地向这种融合机1200中添加通信协议及应用程序。

如以上用第一实施例说明过的那样，根据本发明，在图像形成装置内构成中介处理单元，该中介处理单元通过控制与经多种多样的接口连接的设备进行的打印数据及图像数据的发送接收，来中介多种多样的通信协议和进行互不相同的图像形成处理的多个应用程序，所以多个通信协议的接口和各应用程序无需意识到相互的存在。因此，能够容易地向本发明的图像形成装置中添加通信协议及应用程序。

在本发明中，中介多种多样的通信协议和执行与图像形成有关的处理的应用程序之间的连接的连接请求中介单元可以具有：注册单元，按照来自上述应用程序的注册请求来注册该应用程序；和缓冲器注册单元，按照来自上述应用程序的注册发送接收缓冲器的请求，来注册该应用程序专用的接收缓冲器及发送缓冲器并将其设为可用状态。

此外，上述连接请求中介单元可以具有：发送接收缓冲器分配单元，收到来自上述各通信协议守护程序的连接通知后，在上述共享存储器内分配上述连接中使用的接收缓冲器和发送缓冲器，通知给上述通信协议守护程序。

再者，应用程序1230可以具有：连接处理单元，从上述连接请求中介单元接收到连接的通知后，向该连接请求中介单元通知连接许可，并且与上述通信协议守护程序相连；和数据接收开始请求单元，请求上述通信协议守护程序开始接收数据。

此外，各通信协议守护程序可以具有：接收数据写入单元，上述通信协议守护程序将接收数据写入到上述发送接收缓冲器分配单元分配的上述接收缓冲器中，将写入开始位置移动与数据长度对应的量；和接收写入通知单元，向上述应用程序通知已向上述接收缓冲器中写入上述接收数据，并且进行指定该接收数据的写入开始位置和写入结束位置的写入通知。

进而，应用程序1230可以具有：接收数据读入单元，从上述通信协议守护程序接收到上述接收数据的写入通知后，从该写入通知指定的上述写入开始位置至上述写入结束位置从上述接收缓冲器中读出上述接收数据，将读出开始位置移动到该写入结束位置；和接收读出通知单元，向上述通信协议守护程序通知已从上述接收缓冲器中读出上述接收数据。

此外，应用程序1230可以具有：发送数据写入单元，向上述缓冲器注册单元注册过的上述发送缓冲器中写入发送数据，将写入开始位置移动与数据长度对应的量；和发送写入通知单元，向上述通信协议守护程序通知已向上述发送缓冲器中写入上述发送数据，并且进行指定该发送数据的写入开始位置和写入结束位置的写入通知。

再者，上述各通信协议守护程序可以具有：发送数据读出单元，从上述应用程序接收到上述发送数据的写入通知后，从该写入通知指定的上述写入开始位置至上述写入结束位置从上述发送缓冲器中读出上述发送数据，使与上述应用程序相连的上述通信协议守护程序发送该发送数据；读出开始位置移动单元，将上述读出开始位置移动到上述写入结束位置；以及发送读出通知单元，向上述应用程序通知已从上述发送缓冲器中读出上述发送数据。

[第二实施例]

在第二实施例中，融合机1200的功能结构及硬件结构与第一实施例中的功能结构及硬件结构相同，所以省略其说明。

除了上述第一实施例的功能结构及硬件结构之外，还考虑到下述方法：将与NCS 1228和应用程序1230之间进行的数据发送接收有关的处理作为序列控制库来公用，并且在执行Web服务功能时进行同样的几个处理，所以将这些同样的处理单元化来公用。

以下，用图9来说明作为序列控制库来公用的情况下的基本结构。图9是容易开发及添加应用程序的融合机的基本结构示例图。在图9中，只图示了图1所示的融合机1200的功能结构中的主要功能结构，省略了其他功能结构。在图9中，应用程序1230和NCS 1228经作为中间层的序列控制库100来传递接收数据及发送数据。这里，说明通过HTTP守护程序2来控制通信的情况。在通过其他守护程序来控制通信的情况下也同样由序列控制库100来进行。

应用程序1230对指定数据的发送方法的每种方法(メソツド)具有处理单元，例如，具有进行POST方法的处理的POST方法处理单元103、进行GET方法的处理的GET方法处理单元104、进行POST方法及GET方法以外的方法的处理的其他方法处理单元199。各处理单元103、104及199进行方法特有的解析处理，并且根据处理请求来进行处理，提供其处理结果作为Web服务。

序列控制库100具有根据HTTP来管理连接的HTTP连接管理单元、和通过根据HTTP发送接收数据来执行服务的HTTP服务执行单元102。

由于为HTTP服务的每个请求分别确立连接，所以生成多个HTTP服务执行单元102作为线程(或进程)。HTTP服务执行单元102根据HTTP头中指定数据发送方法的方法(メソツド)，向GET方法处理单元104、POST方法处理单元103、其他方法处理单元199分配处理。

NCS 1228具有：HTTP守护程序2，经网络15根据HTTP对数据发送接收进行通信控制；以及请求中介守护程序7，收到来自HTTP守护程序2的连接及切断的通知后，与HTTP连接管理单元101进行连接及切断的处理。

HTTP连接管理单元101从请求中介守护程序7收到第一个连接通知后，进行共享存储器99的初始化，注册与可能的连接数对应的接收缓冲器97及发送缓冲器98，设为可发送接收数据状态。此外，通过该初始化，能够接受多个连接请求，为每个连接生成HTTP服务执行单元102作为线程，能够为每个连接提供HTTP服务。

例如，假设HTTP守护程序2能够同时接受的连接请求的最大数是3，则通过预先驻留3个线程，能够提高处理性能。另一方面，也可以为每个连接生成1个线程，在处理结束的时刻使其结束。

应用程序1230的各处理单元103、104及199不是与HTTP守护程序2及请求中介守护程序7直接交换数据，而是从HTTP服务执行单元102接受处理请求，将处理结果经共享存储器99通知给HTTP服务执行单元102。

各处理单元103、104及199例如在接收到来自HTTP服务执行单元102的处理请求后，将待处理的打印数据(以MB为单位的数据)从共享存储器99中读入，对打印数据进行与处理请求相应的处理，将处理结果写入到共享存储器99中，作为Web服务经HTTP服务执行单元102提供给处理请求者。处理结果例如是通过对该打印数据进行图像形成处理而生成的图像数据(以MB为单位的数据)、或表示与图像形成处理有关状态的状态信息等。

即，应用程序1230的各处理单元103、104及199只要是能够用HTTP服务执行单元102来分配处理请求的处理单元即可。

同样，也能够容易地添加各种应用程序，即，将与方法对应的处理单元添加到融合机1200中。

在图9中，说明了能够为用于提供Web服务的每种方法容易地添加处理单元的基本结构例。但是，在这种每种方法的处理单元中，在提供方法相同的不同Web服务的情况下，需要为每种Web服务准备在执行用于进行Web服务的实际处理前所需的方法特有的处理。可以公用方法特有的处理。

用图10来说明将与上述NCS 1228和应用程序1230之间进行的数据发送接收有关的处理作为序列控制库来公用、并且公用方法特有的处理的情况下的结构。此外，用图11及图12来详述其处理流程。

图10是容易开发及添加应用程序的融合机的第一结构示例图。在图10中，只图示了图1所示的融合机1200的功能结构中的主要功能结构，省略了其他功能结构。在图10中，对与图9同样的处理单元附以同一标号，省略其说明。

与图9所示的基本结构例的不同点在于，在应用程序1230的POST方法处理单元103中，Web服务应用程序1218-1和Web服务应用程序1218-2共享POST方法特有的解析基于XML的消息及生成基于XML的消息的XML处理单元103-2、和具有解析及生成XML所需的单元的XML解析单元103-3。

从HTTP服务执行单元102向POST方法处理单元103分配处理后，在处理请求用XML消息来描述的情况下，POST方法处理单元103都使XML处理单元103-2解析XML消息，用XML处理单元103-2将实际进行与请求相应的处理作为Web服务的Web服务应用程序1218-1及1218-2的响应描述为XML消息。XML处理单元103-2在必要时执行XML解析单元103-3，解析及生成XML消息。

在这种第一结构例中，各Web服务应用程序1218-1及1218-2无需解析及生成XML消息，所以开发者只开发通过POST方法来实际进行Web服务的处理单元分即可，所以能够容易地将新Web服务应用程序添加到融合机1200中。

用图11及图12来说明在图10所示的第一结构例中执行Web服务应用程序1218作为Web服务、将其处理结果通知给HTTP守护程序2之前的处理流程。图11及图12是图10的第一结构例的处理流程图。在图11中，请求中介守护程序7向HTTP连接管理单元101通知连接后(步骤S40)，HTTP连接管理单元101向连接通知队列中105中添加该通知(步骤S41)。HTTP服务执行单元102向HTTP连接管理单元101请求取得连接(步骤S42)。HTTP连接管理单元101按照该请求向连接通知队列105请求取得通知(步骤S43)，从连接通知队列105取得连接通知(步骤S44)。

HTTP连接管理单元101根据从连接通知队列105取得的连接通知，与HTTP守护程序2相连。此外，HTTP连接管理单元101生成连接管理信息并保存到连接处理单元89中(步骤S46)。连接处理单元89是HTTP服务执行单元102进行的处理的一部分。另一方面，按照来自HTTP连接管理单元101的连接，HTTP守护程序2将HTTP头信息保存到连接处理单元89中(步骤S47)。

HTTP连接管理单元101向HTTP服务执行单元102通知连接管理信息(步骤S48)，在连接管理信息指定了POST方法的情况下，HTTP服务执行单元102委托POST方法处理单元103进行处理(步骤S49)。POST方法处理单元103在指定了text/xml作为Content-Type的情况下，为了解析XML消息，委托XML处理单元103-2进行处理(步骤S50)。

XML处理单元103-2请求连接处理单元89读入数据(步骤S51)。HTTP守护程序2通知连接处理单元89已向接收缓冲器97中写入接收数据(步骤S52)。连接处理单元89将接收数据通知给XML处理单元103-2(步骤S53)。

XML处理单元103-2委托XML解析单元103-3解析接收数据中的XML消息的部分(步骤S54)。然后，XML处理单元103-2向XML解析单元103-3请求取得结果后，XML解析单元103-3将元素树作为XML消息的句法解析结果通知给XML处理单元103-2(步骤S56)。

XML处理单元103-2委托Web服务应用程序1218根据XML解析单元103-3通知的元素树来进行处理(步骤S57)。Web服务应用程序1218按照委托来执行处理，将其处理结果通过元素树通知给XML处理单元103-2(步骤S58)。

XML处理单元103-2根据通知的元素树，通过将Web服务应用程序1218的处理结果用XML写出到连接管理单元87来生成XML消息(步骤S59)。然后，连接处理单元89将XML消息写入到发送缓冲器98中，向HTTP守护程序2通知已写入到发送缓冲器98(步骤S60)。

此外，XML处理单元103-2向连接处理单元89通知结束(步骤S61)。按照该结束通知，连接处理单元89切断与HTTP守护程序2之间的连接(步骤S62)。进而，XML处理单元103-2向连接处理单元89通知结束处理(步骤S63)，连接处理单元89向HTTP服务执行单元102通知结束处理(步骤S64)。然后，HTTP服务执行单元102向HTTP连接管理单元101通知处理已结束(步骤S65)。

在上述处理流程中，Web服务应用程序1218只是在步骤S57及S58中只与XML处理单元103-2进行相互的处理。这样，通过序列控制库100、以及应用程序1230的POST方法处理单元103内的XML处理单元103-2及XML解析单元103-3等单元化、共享化而成的处理单元，能够容易地开发基于新POST方法的Web服务应用程序。

进而，用图13及图14来说明通过用共享存储器99来实现发送接收数据的交换的序列控制库而生成的线程的结构。图13及图14是序列控制库的线程结构的示例图。

在图13中，融合机1200起动后，生成的初始化线程191生成中介守护程序用客户线程192(步骤S61)。中介守护程序用客户线程192是HTTP连接管理单元101的处理单位，作为HTTP连接管理单元101来工作。然后，初始化线程191向请求中介守护程序7注册应用程序(步骤S62)。进而，初始化线程191生成至少1个以上的HTTP服务执行线程193(步骤S63)。HTTP服务执行线程193是HTTP服务执行单元102的处理单位，作为HTTP服务执行单元102来工作。

中介守护程序用客户线程192从请求中介守护程序7收到连接通知后(步骤S64)，向连接通知队列105中添加连接通知，向HTTP服务执行线程193之一通知连接(步骤S65)。收到连接通知的HTTP服务执行线程193生成HTTP守护程序用客户线程194(步骤S66)。HTTP服务执行线程193与HTTP守护程序2相连(步骤S67)。

请求中介守护程序7向HTTP守护程序用客户线程194通知已向接收缓冲器94中写入接收数据(步骤S68)。然后，HTTP守护程序用客户线程194向HTTP服务执行线程193通知已写入接收数据(步骤S69)。HTTP服务执行线程193将请求中介守护程序7写入的接收数据从接收缓冲器97中读出(步骤S70)。

HTTP服务执行线程193将发送数据写入到发送缓冲器98中，向请求中介守护程序7通知已写入到发送缓冲器中(步骤S71)。请求中介守护程序7从发送缓冲器98中取出发送数据(步骤S72)。HTTP服务执行线程193切断与请求中介守护程序7之间的连接(步骤S73)。

通过序列控制库100中的线程的处理，能够使用共享存储器99来存取大量数据，并且能够将应用程序1230中安装的Web服务功能作为从与实际进行的Web服务应用程序1218分离的处理来实现。图10所示的GET方法处理单元104及其他方法处理单元199中实际进行Web服务功能的Web服务应用程序也同样。因此，Web服务功能的开发者无需与NCS 1228和应用程序1230之间进行的数据发送接收有关的处理的知识，就能够开发Web服务功能。

在图10所示的第一结构例中，说明了通过POST方法用XML消息来委托及响应处理的情况，但是在POST方法中，有与内容类型相应的各种处理形态。用图15来说明按这种POST方法中的每种处理形态来公用的情况。图15是容易开发及添加应用程序的融合机的第二结构示例图。在图15中，对与图10同样的处理单元附以同一标号，省略其说明。

在图15中，POST方法处理单元103除了具有与图10所示的处理单元103-2及103-3和1218-1至1218-2相当的处理单元103-2及103-3和1218-4之外，作为公用的处理单元，还具有根据内容类型来分配处理的内容类型分配处理单元113-1、解析将FORM指定为内容类型的处理请求的FORM数据解析单元113-2、以及解析将多部分(マルチパ-ト)指定为内容类型的处理请求的多部分解析单元113-4；作为提供Web服务的处理单元，具有进行用于实际上载多部分指定的数据文件的处理的Web服务应用程序1218-5。

内容类型分配处理单元113-1在将“application/x-www-form-urlencoded”指定为内容类型的情况下，向FORM数据解析单元113-2分配处理请求；在将“multipart/form-data”指定为内容类型的情况下，向多部分解析单元113-4分配处理请求；在将“text/xml”指定为内容类型的情况下，向XML处理单元103-2分配处理请求。

分配处理请求后，FORM数据解析单元113-2、多部分解析单元113-4及XML处理单元103-2分别进行处理的解析处理后，使与处理请求对应的Web服务应用程序1218-3、1218-5、1218-4进行处理。

这样，通过共享与用POST方法处理的内容类型相应的规定的解析处理，开发者无需与内容类型相应的规定的解析处理的有关知识，就能够开发新Web服务应用程序1218，并且能够容易地向融合机1200中添加新Web服务应用程序1218。

接着，用图16来说明在GET方法处理单元104中共享GET方法特有的处理的结构。图16是容易开发及添加应用程序的融合机的第三结构示例图。在图16中，对与图9同样的处理单元附以同一标号，省略其说明。

在图16中，GET方法处理单元104具有根据标识Web服务的URL(Uniform Resource Locator，统一资源定位符)来分配处理请求的URL分配处理单元104-1作为公用的处理单元；具有多个Web服务应用程序1218-6至1218-8作为提供Web服务的处理单元。

这样，通过共享用GET方法处理的URL的规定的解析处理，开发者无需与URL的规定的解析处理有关的知识，就能够开发新Web服务应用程序1218，并且能够容易地向融合机1200中添加新Web服务应用程序1218。

此外，通过使融合机1200具有图15所示的POST方法处理单元103、和图16所示的GET方法处理单元104，在POST方法及GET方法的任一个中，都能够容易地开发及添加Web服务应用程序1218。

根据本发明，融合机1200能够将提供Web服务所需的处理单元单元化而由多个应用程序共享。因此，能够将提供Web服务所需的相同的功能集中而单元化，由安装的应用程序来重用这些单元化了的功能(处理单元)，所以能容易地开发应用程序及向融合机1200中添加该应用程序。

如以上用第二实施例说明过的那样，根据本发明，能够提供一种图像形成装置，能够将提供Web服务所需的处理单元单元化而由多个应用程序共享，所以容易开发提供Web服务的应用程序。

在本发明中，可以使生成上述连接管理信息并进行连接处理的连接处理单元从上述处理请求被分配给的上述方法处理单元接收到处理通知后，切断与上述Web通信协议守护程序之间的连接。

此外，可以使上述连接处理单元向上述Web服务执行单元通知已结束与上述处理请求相应的处理，上述Web服务执行单元向上述Web连接管理单元通知上述处理已结束。

再者，可以做成用于使计算机执行下述步骤的程序：多个方法处理步骤，根据方法来进行规定的处理；以及Web服务执行步骤，通过按照处理请求向与该处理请求指定的上述方法对应的上述方法处理步骤分配该处理请求来执行Web服务。

[第三实施例]

本发明一实施例的处理程序自动生成装置具有图17所示的功能结构。图17是本发明一实施例的处理程序自动生成装置的功能结构的方框图。在图17中，处理程序自动生成装置500是计算机装置，具有存储媒体(例如硬盘驱动器(HDD))，该存储媒体用于存储生成吸收消息的数据形式和Web服务功能中的程序语言可处理的数据形式之间的差异的程序处理程序自动生成部510、基于WSDL(Web Service Description Language)的接口定义521、以及执行处理程序所需的源码531。

处理程序自动生成部510是下述处理单元：输入基于WSDL(Web ServiceDescription Language)的接口定义521，解析用XML(eXtensible MarkupLanguage，可扩展标记语言)描述的请求消息的句法来生成元素树，根据元素树来设置用于对Web服务功能(WSF)进行函数调用的变元，并且生成处理程序处理单元的源码并输出，该处理程序处理单元生成用于描述包含Web服务功能的返回值的基于XML的响应消息的元素树。

处理程序自动生成部510具有XML解析单元511、类型库生成部512、处理程序源码生成部513、XML模式解析单元514、类型元素解析单元515、消息元素解析单元516、操作元素解析单元517、输入接口定义521的文件输入部520、以及输出源码531的文件输出部530。

接口定义521定义用什么接口来提供1个Web服务，由基于WSDL的接口定义文件522、和通过从接口定义文件522进口而取入的类型定义文件523构成。在不能用接口定义文件522通过进口而取入类型定义文件523的情况下，不存在类型定义文件523。

源码531例如是C语言的源码，由处理程序处理单元的头文件和程序文件构成的处理程序源码532、和从处理程序源码532引用的类型库533构成。类型库533由头文件和程序文件构成。

文件输入部520将用户指定的接口定义521输入到处理程序自动生成部510中(步骤S81)，通知给XML解析单元511(步骤S82)。XML解析单元511根据从文件输入部520收到的接口定义521，来解析XML的句法并生成元素树。然后，XML解析单元511将该元素树通知给类型元素解析单元515(步骤S83-1)，并且通知给消息元素解析单元516(步骤S83-2)，还通知给操作元素解析单元517(步骤S83-3)。

类型元素解析单元515是为了生成类型库而解析元素树内的typcs元素的处理单元，解析元素树来检测表示类型定义的types元素，使XML模式解析单元514解析检测出的types元素(步骤S84-1)。然后，类型元素解析单元515将XML模式解析单元514的解析结果通知给类型库生成部512(步骤S85-1)。

消息元素解析单元516是为了生成处理程序源码而解析元素树内的message元素的处理单元，将其解析结果通知给处理程序源码生成部513(步骤S85-2)。操作元素解析单元517是为了生成处理程序源码而解析元素树内的operation元素的处理单元，将其解析结果通知给处理程序源码生成部513(步骤S85-3)。

类型库生成部512是根据类型元素解析单元515通知的解析结果来生成类型库的处理单元，生成的类型库被通知给文件输出部530(步骤S86-1)。处理程序源码生成部513根据消息元素解析单元516及操作元素解析单元517通知的解析结果，来生成源码并通知给文件输出部(步骤S86-2)。文件输出部530将处理程序源码生成部513通知的源码作为处理程序源码532，并且将类型库生成部512通知的类型库作为类型库533，来输出源码531(步骤S87)。

这样，处理程序自动生成装置500能够通过输入定义Web服务的接口定义521，来自动输出处理程序处理单元的源码531。

这种处理程序自动生成装置500具有图18所示的硬件结构。图18是本发明一实施例的处理程序自动生成装置的硬件结构的方框图。

在图18中，处理程序自动生成装置500是由计算机控制、执行处理程序自动生成部510的装置，由CPU(中央处理单元)551、存储器单元552、显示单元553、输入单元554、存储装置556、驱动器557构成，被连接在系统总线B上。

CPU 551根据存储器单元552中保存的程序来控制处理程序自动生成装置500。存储器单元552由RAM及ROM等构成，保存CPU 551执行的程序、CPU 551的处理所需的数据、CPU 551的处理中得到的数据等。此外，存储器单元552的一部分区域被分配为CPU 551的处理所用的工作区。

显示单元553在CPU 551的控制下显示所需的各种信息。输入单元具有鼠标、键盘等，用于使用户输入处理程序自动生成装置500进行处理所需的各种信息。存储装置556例如由硬盘单元构成，保存图17所示的接口定义521及源码531、生成处理程序处理单元所需的数据等。

在处理程序自动生成装置500中实现处理程序自动生成部510进行的自动生成处理的程序例如通过CD-ROM等存储媒体558提供给处理程序自动生成装置500。即，将保存着程序的存储媒体558放入驱动器557中后，驱动器从存储媒体558中读出程序，将该读出的程序经系统总线B安装到存储装置556中。然后，起动程序后，CPU 551根据存储装置556中安装的程序来开始其处理。其中，保存程序的媒体不限于CD-ROM，只要是计算机可读的媒体即可。

下面说明处理程序自动生成部510执行的整个处理程序自动生成处理。图19是说明整个处理程序自动生成处理的流程图。在图19中，用文件输入部520来读入接口定义文件521(步骤S501)，XML解析单元511解析基于XML的描述并生成元素树(步骤S502)。

处理程序自动生成部510判断解析是否成功(步骤S503)。在解析失败的情况下，将出错显示在显示单元553上(步骤S504)，结束处理程序生成处理。在解析成功的情况下，用类型库512来生成类型库(步骤S505)。此外，用处理程序源码生成部513来生成处理程序源码(步骤S506)，结束处理程序生成处理。

下面详述类型库生成部512进行的类型库生成处理(步骤S505)。图20是说明类型库生成处理的流程图。在图20中，类型元素解析单元515从XML解析单元511通知的元素树中搜索types元素(步骤S511)。

类型元素解析单元515判断是否找到types元素(步骤S512)。在未找到的情况下，结束类型库生成处理。而在找到的情况下，判断是否是空元素(步骤S513)。在是空元素的情况下，结束类型库生成处理。而在不是空元素的情况下，判断是否是外部文件的进口(步骤S514)。即，判断在图17中接口定义文件522是否进口了类型定义文件523。在未进口外部文件(类型定义文件523)的情况下，进至步骤S516。而在进口了外部文件(类型定义文件523)的情况下，读入模式定义文件(类型定义文件523)(步骤S515)。

XML模式解析单元514解析接口定义文件522的XML模式(步骤S516)，生成源码(步骤S517)。然后，由文件输出部530作为由头文件和程序文件构成的类型库533来输出。

用图21至图27来说明步骤S517的源码生成处理。首先，说明在types元素中用枚举类型定义了数据类型的情况。图21是源码生成处理中的枚举类型定义生成处理的说明图。

在图21中，XML模式601是用枚举类型来定义数据类型的基于XML的描述例。XML描述601由基于标记simpleType的描述602定义为具有“SomeValueEnum”这一名称的简单类型的数据类型。进而，通过基于标记restriction的描述603，描述604由base指定的“string”将基类型限制为字符串。例如，在描述604中，用enumeration标记枚举了字符串为“VALUE1”、“VALUE2”、“VALUE3”的3个值。在此情况下，名称“SomeValueEnum”的数据类型被定义为具有3个字符串。

C代码701是根据用枚举类型来定义数据类型的XML模式601生成的C语言的源码。在C代码701中，描述702根据描述602来定义“_SomeValueEnum”是枚举类型，根据描述603及描述604来生成描述704。用枚举了“SomeValueEnum_VALUE1”、“SomeValueEnum_VALUE2”、“SomeValueEnum_VALUE3”这3个的描述704来定义具有3个字符串。而描述705表示定义“SomeValueEnum”是与“enum_SomeValueEnum”相同的数据类型。

这样，根据用types元素来描述枚举类型的XML模式601生成了C代码701。

接着，说明在types元素中用结构体定义了数据类型的情况。图22是源码生成处理中的结构体的类型定义生成处理的说明图。

在图22中，XML模式611是用结构体来定义数据类型的基于XML的描述例。XML模式611由基于标记complexType的描述612定义为具有“SomeStruct”这一名称的复合型的数据类型。用基于标记sequence的描述613来规定数据顺序。用基于标记element的描述614来定义结构体成员“strParam”是字符串，用基于标记element的描述615来定义结构体成员“intParam”是整数。

C代码711是根据用结构体定义了数据类型的XML模式611生成的C语言的源码。在C代码711中，描述712根据描述612来定义“_SomeStruct”是结构体，根据描述614及描述615来生成基于描述714的“char^*strParam”及基于描述715的“int intParam”。而描述715表示定义“SomeStruct”是与“struct_SomeStruct”相同的数据类型。

这样，根据用types元素描述了结构体的XML模式来生成C代码711。

接着，说明在types元素中用数组定义了数据类型的情况。图23是源码生成处理中的数组的类型定义生成处理的说明图。

在图23中，XML模式621是用数组来定义数据类型的基于XML的描述例。XML描述621由基于标记complexType的描述622定义为具有“ArrayOfString”这一名称的复合型的数据类型。进而，通过基于标记restriction的描述624，用base指定的“soapEnc:Array”限制为符合SOAP编码的数组。此外，用基于标记sequence的描述625来规定基于描述626的数据顺序。用基于标记element的描述626来定义“item”是字符串，可省略，出现次数没有上限。基于标记attribute的描述627如下定义属性：引用“soapEnc:arrayType”，该数组的类型由“Wsdl:arrayType＝”xs:string[]””定义为字符串的数组。

C代码721是根据用数组来定义数据类型的XML模式621生成的C语言的源码。在C代码721中，描述722根据描述622来定义“_ArrayOfString”是结构体，根据描述626及描述627来生成基于描述723及描述724的表示元素数的“int length；”及基于描述715的“char^*”的数组的指针-“char^**array；”。而描述725表示定义“ArrayOfString”是与“struct_ArrayOfString”相同的数据类型。

用图24至图26来说明根据types元素的simpleType及complexType的定义来生成C语言的函数声明的例子。在图24至图26中，假设C语言代码内的Document及Element是将用DOM(Document Object Model，文档对象模型)定义的类型映射为C语言的结构体而成的。此外，在图24至图26中，串行化器及并行化器是在变换元素树和与各类型对应的结构体数据时执行的程序，串行化器是将结构体数据变换为元素树的程序，并行化器是将元素树变换为结构体数据的程序。此外，构造函数是生成结构体数据时执行的程序，析构函数是释放结构体数据的程序。

图24是源码生成处理中的枚举类型的函数声明处理的说明图。在图24中，“Element ^*SomeValueEnum_serialize(Document ^*doc，char ^*tagName，SomeValueEnum value)；”所示的串行化器801用“SomeValueEnum value”来接受枚举值作为输入，用“char ^*tagName”来生成以tagname为标记名的元素(Element)并输出。此外，“SomeValueEnum SomeValueEnum deserialize(Element^*element)；”所示的并行化器811接受元素(Element)作为输入，解析它并输出枚举值。

串行化器801及并行化器811根据XML模式601来生成。

图25是源码生成处理中的结构体的函数声明处理的说明图。在图25中，“SomeStruct ^*SomeStruct_create(char ^*strParam，int intParam)；”所示的构造函数821接受结构体成员的值作为输入，生成结构体并输出。“voidSomeStruct_free(SomeStruct^*st)；”所示的析构函数831接受结构体作为输入，释放其使用的存储区。此外，也递归地释放结构体成员使用的存储区。“Element ^*SomeStruct_serialize(Document ^*doc，char ^*tagName，SomeStruct^*st)；”所示的串行化器841用“SomeStruct ^*st”来接受结构体作为输入，用“char^*tagName”来生成以tagname为标记名的元素(Element)并输出。此外，“SomeStruct ^*SomeStruct_deserialize(Element ^*element)；”所示的并行化器851接受元素(Element)作为输入，解析它来生成结构体并输出。

因此，通过对用XML描述的表示输入值的元素使用并行化器851和构造函数821，能够将输入值设置到Web服务功能可处理的结构体中。此外，通过对Web服务功能的返回值(作为处理结果的输出值)使用串行化器841，能够对应于用XML描述的元素来设置处理结果。

构造函数821、析构函数831、串行化器841及并行化器851根据XML模式611来生成。

图26是源码生成处理中的数组的函数声明处理的说明图。在图26中，“ArrayOfString ^*ArrayOfString_create(int length，char ^**array)；”所示的构造函数861接受数组长度、和数组作为输入，来生成保存数组的结构体并输出。“void ArrayOfString_free(ArrayOfString ^*st)；”所示的析构函数871接受保持数组的结构体作为输入，释放其使用的存储区。此外，也递归地释放数组成员使用的存储区。“Element ^*ArrayOfString_serialize(Document ^*doc，char^*tagName，ArrayOfString ^*st)；”所示的串行化器881用“ArrayOfString ^*st”来接受保持数组的结构体作为输入，用“char ^*tagname”来生成以tagname为标记名的元素(Element)并输出。此外，“SomeStruct ^*SomeStruct_deserialize(Element^*element)；”所示的并行化器891接受元素(Element)作为输入，解析它来生成保持数组的结构体并输出。

因此，通过对用XML描述的表示输入值的元素使用并行化器891和构造函数861，能够将输入值设置到Web服务功能可处理的数组中。此外，通过对Web服务功能的返回值(作为处理结果的输出值)使用串行化器881，能够对应于用XML描述的元素来设置处理结果。

构造函数861、析构函数871、串行化器881及并行化器891根据XML模式621来生成。

这样生成的C语言的函数声明被输出到类型库533的头文件中。此外，各函数的处理被输出到程序文件中。

接着，用图27及图28来详述处理程序自动生成部510进行的处理程序生成处理。图27及图28是说明处理程序生成处理的流程图。在图27中，处理程序自动生成部510从service元素的name属性中取得服务名(步骤S521)。然后，按service元素、binding元素、porttype元素的顺序遍历来搜索各元素(步骤S522)。

搜索porttype元素的子元素-operation元素，从name属性中取得操作名(步骤S523)。搜索operation元素的子元素-input元素，从name属性中取得输入消息名(步骤S524)。搜索operation元素的子元素-output元素，从name属性中取得输出消息名(步骤S525)。然后，生成处理程序处理单元和Web服务功能(WSF)的函数声明(步骤S526)。

搜索输入消息的message元素(步骤S527)。搜索message元素的子元素-part元素，从name属性中取得参数名，从types属性中取得类型(步骤S528)。然后，将类型映射为C语言的类型(步骤S529)。判断是否还有part元素(步骤S530)。在有part元素的情况下，返回到步骤S528，重复上述处理。而在没有part元素的情况下，结束将输入消息映射为C语言的类型，将输出消息映射为C语言的类型。

搜索输出消息的message元素(步骤S531)。搜索message元素的子元素-part元素，从name属性中取出参数名，从types属性中取得类型(步骤S532)。然后，将类型映射为C语言的类型(步骤S533)。判断是否还有part元素(步骤S534)。在有part元素的情况下，返回到步骤S532，重复上述处理。而在没有part元素的情况下，结束将输出消息映射为C语言的类型。

接着，生成输入消息的结构体定义(步骤S535)。此外，生成输出消息的结构体定义(步骤S536)。生成处理程序处理单元的程序(步骤S537)。将输入消息的结构体定义及输出消息的结构体定义输出到头文件中，将处理程序处理单元的程序输出到程序文件中(步骤S538)。然后，判断是否还有operation元素(步骤S539)。在有operation元素的情况下，返回到步骤S523，重复与上述同样的处理。在没有operation元素的情况下，结束处理程序生成处理。

用图29及图30来说明输入到处理程序自动生成部510的接口定义文件(WSDL)的描述例。图29及图30是基于WSDL的接口定义的描述示例图。在图29及图30中，假设本来用<type>标记描述的数据类型的定义由“foo.bar.com/types.xsd”标识的类型定义文件523来定义。在本描述例中，定义用于描述消息的数据类型，省略了设置模式的定义的<type>标记，代之以用描述40从“foo.bar.com/types.xsd”进口。

在用定义消息的格式的<message>标记41(描述<messagename＝″printInput″>)定义的定义信息42中，用描述<part name＝″fileId″type＝″xs:unsignedInt″/>及描述<part name＝″count″type＝″xs:unsignedInt″/>来定义打印请求的输入参数(printInput)由无符号整数(unsignedInt)的fileId及无符号整数(unsignedInt)的count构成。此外，在用定义消息的格式的<message>标记43(描述<message name＝″printOutput″>)定义的定义信息44中，用描述<part name＝″requestId″ type＝″xs:unsignedInt″/>来定义打印请求的输出参数(printOutput)由无符号整数(unsignedInt)的requestId构成。

在用定义操作(operation)的集合的<portType>标记45(描述<portTypename＝″netdocPortType″>)定义的定义信息46中，定义每个操作的输入消息及输出消息。例如，在用<operation>标记47(描述<operation name＝″print″>)定义的定义信息48中，用描述<input message＝″tns:printInput″/>来定义输入消息是printInput，而用描述<output message＝″tns:printOutput″/>来定义输出消息是printOutput。在此情况下，只定义打印(print)。

在将用<portType>标记45定义的操作和消息映射为具体的协议和数据格式的用<binding>标记49(描述<binding  name＝″netdocHttpBinding″type＝″tns:netdocPortType″>)定义的定义信息50中，对用netdocPortType定义的端口类型，定义操作和消息向协议和数据格式的映射。

在定义信息50中，用<sb:binding>标记51(描述<sb:bindingtransport＝″http://schemas.xmlsoap.org/soap/http″style＝″rpc″/>)来定义基于SOAP HTTP绑定的RPC(Remote Procedure Call，远程步骤调用)的使用。用<operation>标记52(描述<operation name＝″print″>)如下定义与打印(print)有关的SOAP消息。

首先，用<sb:operation>标记53(描述<sb:operationsoapAction＝″http://foo.bar.com/netdoc/[print″/>)来定义打印(print)请求时的SOAPAction头的值是“http://foo.bar.com/netdoc/print”。

接着，在用<input>标记54定义的定义信息55中，用描述<sb:bodyencodingStyle＝″http://schemas.xmlsoap.org/soap/encoding/″usc＝″litcral″namespace＝″http://foo.bar.com/netdoc/″/>来定义输入时的编码形式，在用<output>标记56定义的定义信息57中，用描述<sb:bodyencodingStyle＝″http://schemas.xmlsoap.org/soap/encoding/″use＝″literal″namespace＝″http://foo.bar.com/netdoc/″/>来定义输出时的编码形式。

然后，在用定义网络的端点的集合的<service>标记58(描述<servicename＝″netdoc″>)定义的定义信息59中，用<port>标记60(描述<portname＝″netdocPort″binding＝″tns:netdocHttpBindin g″>)来定义网络的端点之一-netdocPort，进而用描述<sb:addresslocation＝″http://printer.foo.bar.com/netdoc″/>来定义该网络的端点的地址位置。即，定义了服务名“netdoc”的绑定是“netdocHttpBinding”，服务的URL(Uniform Resource Locator，统一资源定位符)是“http://printer.foo.bar.com/netdoc”。

这样用WSDL定义的接口定义文件522及类型定义文件523来决定数据类型，决定操作，并且决定URL及SOAPAction头。

接着，说明输入了图29及图30所示的接口定义的情况下的处理程序处理单元及Web服务功能的声明、和输入消息及输出消息的结构体定义。首先，用图31及图32来说明用图27的步骤S526生成的处理程序处理单元和Web服务功能的函数声明。

图31是处理程序处理单元的函数声明的说明图。在图31中，处理程序处理单元的函数声明例如将由表示服务名的“netdoc”和表示操作名的“print”、以及表示处理程序处理单元的“handler”构成的“netdoc_print_handler”作为函数名，将其作为处理程序处理单元的函数来声明。在本例中，用“netdoc_print_handler”来表示与进行打印操作的服务对应的处理程序处理单元。处理程序处理单元的函数声明被输出到处理程序源码532的头文件中。

图32是Web服务功能的函数声明的说明图。在图32中，Web服务功能的函数声明例如将由表示服务名的“netdoc”和表示操作名的“print”构成的“netdoc_print”作为函数名，将其作为Web服务功能的函数来声明。此外，Web服务功能的函数的变元用由表示服务名的“Netdoc”和表示输入消息名的“printInput”构成的“Netdoc_printInput”来指定输入消息的结构体，而用由表示服务名的“Netdoc”和表示输出消息名的“printOutput”构成的“Netdoc_printOutput”来指定输出消息的结构体。Web服务功能的函数声明被输出到处理程序源码532的头文件中。

用图33来说明图28的步骤S535中生成的输入消息的结构体定义。图33是输入消息的结构体定义的说明图。在图33中，输入消息的结构体例如将由表示服务名的“Netdoc”和表示输入消息名的“printInput”构成的“_Netdoc_printInput”定义为结构体。此外，结构体“_Netdoc_printInput”由用“unsigned int”将参数类型设为无符号整数的参数名“fileId”、和用“unsigned int”将参数类型设为无符号整数的参数名“count”构成。输入消息的结构体被输出到处理程序源码532的头文件中。

用图34来说明图28的步骤S536中生成的输出消息的结构体定义。图34是输出消息的结构体定义的说明图。在图34中，输出消息的结构体例如将由表示服务名的“Netdoc”和表示输出消息名的“printOutput”构成的“_Netdoc_printOutput”定义为结构体。此外，结构体“_Netdoc_printOutput”由用“unsigned int”将参数类型设为无符号整数的参数名“requestId”构成。输出消息的结构体被输出到处理程序源码532的头文件中。

用图35来说明根据图29及图30所示的接口定义自动生成的处理程序处理单元532的程序的例子。图35是自动生成的处理程序源码的示例图。在图35中，不记载实际的源码，而记载每个步骤的处理概要。

在图35所示的处理程序源码中，如描述901所示，首先描述图31所示的声明过的处理程序处理单元的函数名。该处理程序处理单元是用于作为Web服务功能的打印功能的处理程序。以下称为打印处理程序。步骤S120至S131的代码是根据元素树来解析表示处理请求的SOAP封装的代码。此外，步骤S140至S148的代码是生成用于创建表示处理响应的SOAP封装的元素树的代码。

在用打印处理程序局部定义的变量的描述之后，记载了打印处理程序用于取得根元素的步骤S120。作为执行步骤S120的结果，取得根元素(Envelope元素)。记载了取得子节点表的步骤S121。作为执行步骤S121的结果，打印处理程序从元素树中取得“Header”及“Body”。

描述了从子节点表中搜索并取得标记名为Body的元素的步骤S122。描述了取得Body元素的第一个子节点的步骤S123。作为执行步骤S123的结果，打印处理程序取得表示操作名的print元素。描述了取得print元素的子节点表的步骤S124。描述了从取得的子节点表中依次取得标记名的步骤S125(将重复的判断作为步骤S132)。

描述了判断标记名是否是fileID的步骤S126。描述了在标记名是fileID的情况下取得标记名为fileID的第一个子节点的步骤S127。作为执行步骤S127的结果，打印处理程序取得文本节点。描述了从取得的文本节点中提取文本数据并变换为整数的步骤S128。作为执行步骤S128的结果，打印处理程序将值作为文件ID参数设置到规定的结构体中。

描述了判断标记名是否是count的步骤S129。描述了在标记名是count的情况下取得标记名为count的第一个子节点的步骤S130。作为执行步骤S130的结果，打印处理程序取得文本节点。描述了提取取得的文本节点并变换为整数的步骤S131。作为执行步骤S131的结果，打印处理程序将值作为份数参数设置到规定的结构体中。

上述步骤S126至S131的描述902是打印处理程序的例子，但是在其他处理程序中，每个标记名的判断及对标记名的处理根据输入消息的参数定义来变化。

描述了将执行了描述902的情况下取得的各参数的值作为输入消息的结构体数据来生成，设置为数据名“in”的步骤S133。

描述了调用将输入消息的结构体数据作为变元的图32所示的声明过的Web服务功能的函数“netdoc_print(in，out)”的步骤S134。

描述了在执行了步骤S134的情况下，判断返回值是否是出错，在是出错的情况下，将SOAPFault设置为responseDocument的步骤S135。

以下步骤S140至S148描述了执行Web服务功能的函数“netdoc_print(in，out)”的结果不是出错的情况下生成用于生成处理响应的元素树的步骤。

描述了生成Envelope元素的步骤S140。描述了生成Body元素的步骤S141。描述了将Body元素连接到Envelope元素上的步骤S142。描述了生成printResponse元素的步骤S143。描述了将printResponse元素连接到Body元素上的步骤S144。描述了生成requestId元素的步骤S145。描述了将printResponse元素连接到Body元素上的步骤S146。

描述了用作为执行步骤S134的结果而得到的请求ID来生成文本节点的步骤S147。描述了将文本节点连接到requestId元素上的步骤S148。

描述了将表示打印处理程序的处理结果的responseDocument作为返回值的步骤S149。

这样描述的处理程序源码532并不限于打印处理程序，可以对应于其他操作来生成同样的步骤。因此，上述处理程序源码中的操作名“print”根据定义来变化。

这样，通过自动生成处理程序源码532，能够大量生成简单、相同的代码，所以能够消除因开发者的简单错误而混入程序错误等问题。此外，能够在短时间内生成处理程序源码532，所以能够减轻开发者的负担。再者，开发者无需意识到基于XML的消息的数据形式和Web服务功能中的程序语言可处理的数据形式之间的差异，就能够开发Web服务功能。

这样用处理程序自动生成部510根据接口定义521对应于各Web服务功能的函数来自动生成的处理程序源码532及类型库533与Web服务功能的函数及构成所需的处理单元的源码一起被编译。

如以上用第三实施例说明过的那样，根据本发明，自动生成用于变换设备间的符合消息交换协议的消息的数据形式的程序。因此，能够消除因开发者的简单错误而混入程序错误等问题。此外，通过将这样自动生成的程序安装到图像形成装置中，即使是通过与以往同样的方法开发的Web服务功能，也能够处理该消息。因此，能够容易地开发图像形成装置中的Web服务功能。此外，能够扩大与可连接在图像形成装置上的其他系统之间的合作。

在本发明的程序生成方法中，计算机可以执行：元素树生成步骤，解析定义Web服务的接口的接口定义，生成表示构成该接口定义的多个元素间的关联的第一元素树；和变换程序生成步骤，生成变换程序，该变换程序根据上述第一元素树，来进行变换为执行上述Web服务的Web服务功能可处理的输入输出数据形式和用规定描述形式描述的与该Web服务有关的请求及响应消息的处理。

此外，上述变换程序生成步骤可以具有：第一程序生成步骤，生成数据类型变换程序，该数据类型变换程序进行上述Web服务功能可处理的上述输入输出数据形式和用上述规定描述形式描述的上述请求及响应消息设置的输入输出消息之间的变换；和第二程序生成步骤，生成第二程序，该第二程序解析用上述规定描述形式描述的上述请求消息，并且生成上述响应消息。

在本发明的存储媒体中，存储着用于使计算机执行下述步骤的计算机可读程序：元素树生成步骤，解析定义Web服务的接口的接口定义，生成表示构成该接口定义的多个元素间的关联的第一元素树；和变换程序生成步骤，生成变换程序，该变换程序根据上述第一元素树，来进行变换为执行上述Web服务的Web服务功能可处理的输入输出数据形式和用规定描述形式描述的与该Web服务有关的请求及响应消息的处理。

此外，上述变换程序生成步骤可以具有：第一程序生成步骤，生成进行上述Web服务功能可处理的上述输入输出数据形式和用上述规定描述形式描述的上述请求及响应消息设置的输入输出消息之间的变换的数据类型变换程序；和第二程序生成步骤，解析用上述规定描述形式描述的上述请求消息，并且生成用于生成上述响应消息的第二程序。

[第四实施例]

以下，说明包含第三实施例中说明过的自动生成的处理程序处理单元的图像形成装置-融合机1200的实施例。

在第四实施例中，融合机1200的功能结构及硬件结构与第一实施例中的功能结构及硬件结构相同，所以省略其说明。

接着，详述能够在融合机1200中根据基于XML(eXtensible MarkupLanguage，可扩展标记语言)的SOAP(Simple Object Access Protoco1，简单对象访问协议)来提供Web服务的结构。Web服务功能×例如是用C语言等程序语言描述的软件(应用程序)。为了使Web服务功能×能够将根据SOAP来描述的基于XML的处理内容作为消息来理解，需要在句法不同的XML和程序语言之间进行处理的处理单元(处理程序)。以下，以进行打印的打印Web服务、取得文档表的文档表取得Web服务、取得文档信息的文档信息取得Web服务为例用图36来进行说明。

图36是用于实现Web服务的结构示例图。在图37中，示出用Web服务应用程序1218来提供打印Web服务、文档表取得Web服务、文档信息取得Web服务的情况。这些Web服务也可以作为应用程序1230的其他功能而与Web服务应用程序1218独立。在图36中，只图示了图34所示的融合机1200的功能结构中的主要功能结构，省略了其他功能结构。

在图36中，为了实现Web服务，在控制服务1250和Web服务应用程序1218之间，构成控制与连接的设备进行的数据发送接收的中间层。

控制服务1250具有ECS 1224、MCS 1225、以及NCS 1228，作为实现Web服务应用程序1218进行的Web服务的构件。NCS 1228具有控制HTTP的HTTP守护程序2、中介HTTP守护程序2和Web服务应用程序1218之间的连接处理的请求中介守护程序7。

此外，中间层1255具有序列控制库100、XML库110、SOAP库120、作业管理单元310、以及文件管理单元311，作为吸收与连接的设备进行的数据的发送接收控制的构件。序列控制库100还具有HTTP连接管理单元101、HTTP服务执行单元102、以及POST方法分配处理单元105。XML库110具有XML处理单元115、XML处理器116、以及XML串行化器117。SOAP库120具有SOAP动作分配处理单元121。

再者，Web服务应用程序1218具有元素树解析/生成处理程序200、和Web服务功能(WSF)300，作为用于实现Web服务的构件。元素树解析/生成处理程序200是解析设备间的符合SOAP的消息的数据形式的句法、变换为Web服务功能300可处理的数据形式的处理单元，具有多个元素树解析/生成处理程序，例如具有打印处理程序201、文档表取得处理程序202、以及文档信息取得处理程序203。这里，打印处理程序201、文档表取得处理程序202、文档信息取得处理程序203分别是基于第三实施例中的图17所示的处理程序自动生成部510自动生成的源码531的处理程序源码532及类型库533的处理程序处理单元。

Web服务功能300具有多个Web服务功能，例如，具有打印功能301、文档表取得功能302、以及文档信息取得功能303。在此情况下，打印处理程序201对表示打印功能301的处理内容的符合SOAP的消息的数据形式进行句法解析，变换为打印功能301可处理的数据形式并请求打印功能301进行处理。此外，打印处理程序201用符合SOAP的数据形式来生成来自打印功能301的响应作为消息。文档表取得处理程序202及文档信息取得处理程序203分别对文档表取得功能302及文档信息取得功能303进行同样的处理。

打印功能301接受文件ID和份数作为输入参数，指定作业管理单元文件ID和份数并向作业管理单元310发出打印请求。将从作业管理单元310接受的请求ID作为输出参数来返回。文档表取得功能302向文件管理单元311请求文件表，将从文件管理单元311接受的ID表作为输出参数来返回。文档信息取得功能303接受文件ID作为输入参数，向文件管理单元311指定文件ID并请求文件信息。将从文件管理单元311接受的文件信息作为输出参数来返回。

作业管理单元310管理作业的队列及执行结果。此外，与ECS 1224及MCS 1125进行通信来执行存储文档的打印处理。文件管理单元311与MCS1225进行通信来取得文件信息。

以下，参照图37及图38来说明从接收到HTTP请求后直至发送HTTP响应的处理。图37及图38是说明基于SOAP的Web服务提供处理的流程图。

NCS 1228的HTTP守护程序2接收来自网络15的连接请求(步骤S1100)。该连接请求经请求中介守护程序7被通知给Web服务应用程序1218的HTTP连接管理单元101。然后，HTTP连接管理单元101将该连接请求根据HTTP通知给提供服务的HTTP服务执行单元102。收到通知的HTTP服务执行单元102连接到HTTP守护程序2，取得HTTP请求。通过用NCS 1228进行这种控制，能够只在必要时进行基于HTTP的通信控制。因此，与始终进行HTTP通信控制的情况相比，能够高效地利用通信控制所需的资源。

HTTP服务执行单元102根据经网络15接收到的HTTP请求来解析表示数据发送方法的HTTP方法，检查是否是GET方法(步骤S1101)。在是GET方法的情况下，提供基于GET方法的Web服务(步骤S1102)。即，提供基于SOAP的Web服务以外的Web服务。

另一方面，在不是GET方法的情况下，检查是否是POST方法(步骤S1103)。在不是POST方法的情况下，进至步骤S1107，进行出错处理，结束提供基于SOAP的Web服务的处理。在是POST方法的情况下，调用POST方法分配处理单元105。POST方法分配处理单元105解析HTTP请求头信息，确认HTTP主体的描述形式是XML(步骤S1104)。即，判断HTTP响应头的Content-Type是否指定了text/xml。在不是XML的情况下，进至步骤S1107，进行出错处理。而在XML的情况下，调用XML内容处理程序111。

XML处理单元115作为POST方法处理程序，用XML处理器116来解析HTTP主体的XML的句法，创建用树结构来表示用XML描述的标记间的关联的请求的元素树(步骤S1105)。判断句法解析结果是否是出错(步骤S1106)。在句法解析结果是出错的情况下，进至步骤S1107，进行出错处理。而在句法解析结果是正常的情况下，进至图38的步骤S1109。

SOAP动作分配处理单元121解析HTTP请求的SOAPAction头，向因URI(Uniform Resource Indicator，统一资源指示符)而异的元素树解析/生成处理程序200分配HTTP请求(步骤S1109)。在此情况下，对指定打印Web服务的URI向打印处理程序201分配HTTP请求及元素树，对指定文档表取得Web服务的URI向文档表取得处理程序202分配HTTP请求及元素树，对指定文档信息取得Web服务的URI向文档信息取得处理程序203分配HTTP请求及元素树。

各元素树解析/生成处理程序200解析请求的元素树并变换为C语言的结构体数据(步骤S1110)。然后，以变换出的结构体数据为变元，来调用与HTTP请求指定的URI对应的Web服务功能300(步骤S1111)。在此情况下，打印处理程序201调用打印功能301，文档表取得处理程序202调用文档表取得功能302，文档信息取得处理程序203调用文档信息取得功能303。

Web服务功能300执行规定的Web服务的逻辑，以结构体数据来返回结果(步骤S1112)。在此情况下，打印功能301、文档表取得功能302、文档信息取得功能303执行各Web服务的逻辑，返回其结果。返回的结果是程序语言可处理的数据形式(例如C语言的结构体)。

各元素树解析/生成处理程序200根据接受的结果的结构体数据来生成响应的元素树(步骤S1113)。各元素树解析/生成处理程序200生成的元素树例如通过从标记到标记的基于指针的链接来表示XML的标记间的关系的数据结构。然后，经SOAP动作分配处理单元121，用XML串行化器117将响应的元素树变换为XML。XML串行化器117将元素树变换为用文本来表示的XML。变换出的XML构成符合SOAP的HTTP主体，被附加了规定的HTTP头后，作为HTTP响应来发送(步骤S1114)。

根据上述，元素树解析/生成处理程序200按照C语言的结构体对元素树进行数据变换。此外，将C语言的结构体数据变换为元素树。开发者即使没有SOAP及XML的知识，也能够用程序语言来开发Web服务。

在起动Web服务功能300时的初始化处理中，进行模块间的(直线所示的)连接，如图36所示来构成。在初始化处理中，POST方法分配处理单元105作为POST方法处理程序，通过连接到序列控制库100来开始，向XML处理单元15的POST方法分配处理单元105进行注册，向SOAP动作分配处理单元121的XML处理单元115进行注册，向元素树解析/生成处理程序200的SOAP动作分配处理单元121进行注册。

接着，以元素树解析/生成处理程序200的打印处理程序201为例，用图39、图40及图41来说明打印处理程序201中的元素树解析处理。图39是使用XML的符合SOAP的HTTP请求的描述示例图。图40是XML处理器变换出的元素树的示例图。图41是用于说明打印处理程序进行的元素树解析处理的流程图。

在委托打印Web服务的、图39所示的HTTP请求的情况下，XML处理器112将以<SOAP-ENV:Envelope>开始的HTTP主体20变换为元素树。将标记名21“Envelope”作为根元素，将标记名22“Header”及标记名23“Body”作为根元素的子节点来相关联。进而，将标记名23“Body”的子节点设为标记名24“print”，进而，将标记名25“fleID”及标记名26“count”作为标记名24“print”的子节点来相关联。然后，分别将文本数据27“123”及文本数据28“2”与标记名25“fileID”及标记名26“count”相关联。这样相关联的元素树结构例如为图40所示的数据结构。在图40中，用椭圆来表示标记名21至26及文本数据27至28，用箭头来表示相关联。

数据结构如图40所示的元素树由打印处理程序201根据图41所示的流程图来生成基于打印功能301可处理的程序语言的结构体数据。图41中的步骤号码对应于图35中的步骤号码。在图41中，打印处理程序201取得根元素(步骤S120)。在此情况下，根元素为Envelope元素。取得子节点表(步骤S121)。即，取得标记名22“Header”及23“Body”。从子节点表中搜索并取得标记名为Body的元素(步骤S122)。取得Body元素的第一个子节点(步骤S123)。在此情况下，取得print元素。取得print元素的子节点表(步骤S124)。从取得的子节点表中依次取得标记名(步骤S125)。

判断标记名是否是fileID(步骤S126)。在标记名不是fileID的情况下，进至步骤S129。而在标记名是fileID的情况下，取得标记名为fileID的第一个子节点(步骤S127)。即，取得文本节点。提取取得的文本节点并变换为整数(步骤S128)。即，作为文件ID参数，将值“123”设置到规定的结构体中。进而，判断标记名是否是count(步骤S129)。在标记名不是count的情况下，进至步骤S132。而在标记名是count的情况下，取得标记名为count的第一个子节点(步骤S130)。即，取得文本节点。提取取得的文本节点并变换为整数(步骤S131)。即，作为份数参数，将值“2”设置到规定的结构体中。

打印处理程序201根据步骤S125中取得的子节点表来判断是否有下一个子节点(步骤S132)。在有下一个子节点的情况下，返回到步骤S125，取得下一个子节点，进行与上述同样的处理。在没有下一个子节点的情况下，结束元素树解析处理。

这样解析出的元素树由打印处理程序201将值设置到图42所示的基于程序语言的结构体的参数中。图42是Web服务功能的函数的变元的设置示例图。在图42中，在结构体29(“struct Netdoc_printInput”)的参数“unsigned intfileID”中，通过步骤S128设置了值“123”。此外，在参数“unsigned int count”中，通过步骤S131设置了值“2”。

Web服务功能300的打印功能301是处理程序自动生成部510作为Web服务功能的函数而声明的“netdoc_print”函数(请参照图32)，所以像“structNetdoc_printInput^*in”那样，由处理程序自动生成部510作为输入消息的结构体而定义的结构体29的结构体名“struct Netdoc_printInput”和指向该结构体29的指针“in”被设置为变元30。调用打印功能301(“netdoc_print”函数)后，打印功能301的处理结果例如以表示指向结构体名“struct Netdoc_printOutput”的指针“out”的、“struct Netdoc_printOutput^*out”这样的变元31来返回。

图43是打印处理程序的处理结果的设置示例图。在图43中，打印处理程序201用变元31的指针“out”，取得用来设置处理结果的结构体39。结构体39是处理程序自动生成部510作为输出消息的结构体而定义的结构体(请参照图34)。例如，在结构体39中，作为处理结果，将值“100”设置到参数“unsigned int request Id”中。

接着，用图44及图45来声明根据表示处理结果的结构体39来生成元素树的元素树生成处理。图44中的步骤号码对应于图35中的步骤号码。图44是用于说明打印处理程序进行的元素树生成处理的流程图。图45是生成的元素树的示例图。

参照图45来说明打印处理程序进行的元素树生成处理。在图44中，打印处理程序201生成Envelope元素32(步骤S140)。生成Body元素33(步骤S141)。然后，将Body元素33连接到Envelope元素32上(步骤S142)。通过这些步骤S140至S142的处理，来设置基于SOAP的HTTP响应的HTTP主体。

然后，打印处理程序201生成printResponse元素34(步骤S143)，将printResponse元素34连接到Body元素33上(步骤S144)。进而，生成requestId元素35(步骤S145)，将requestId元素35连接到printResponse元素34上(步骤S146)。

打印处理程序201根据作为结果而得到的请求ID来生成文本节点36(步骤S147)，将文本节点连接到requestId元素35上(步骤S148)。在此情况下，将“100”设置到文本节点36中。

这样生成的元素树由XML处理单元115及XML串行化器112来生成图46所示的HTTP主体32。图46是从元素树变换出的使用XML的符合SOAP的HTTP响应的描述示例图。在图46中，图45所示的各元素32至36被描述在用<>定界的标记内，按符合SOAP的步骤用XML来描述规定的信息。融合机1200用HTTP守护程序2经网络15向发送HTTP请求的设备发送该HTTP响应。这样，融合机1200向经网络15连接的设备提供Web服务。

根据上述实施例，生成将表示基于XML的元素间的关联的元素树变换为基于Web服务功能可处理的程序语言的输入数据、及将基于程序语言的输出数据变换为规定描述形式的元素树的源码531。因此，能够大量生成简单、相同的代码，所以能够消除因开发者的简单错误而混入程序错误等问题。此外，能够在短时间内生成处理程序源码532，所以能够减轻开发者的负担。

此外，通过将由自动生成的源码531构成的元素树解析/生成处理程序200包括在融合机1200中，开发者能够通过与以往同样的开发方法、例如基于C语言的开发方法，来开发作为Web服务功能的应用程序。此外，能够容易地改进已经安装的应用程序来支持Web服务。

此外，在具有元素树解析/生成处理程序200的融合机1200中，编程开发的Web服务功能300能够解释符合SOAP的XML描述的消息，所以能够将Web服务功能300提供给其他系统。因此，不限制融合机1200上连接的系统或计算机终端，所以能够大幅度扩大融合机1200的可用性。

如以上用第四实施例说明过的那样，根据本发明，包括变换设备间的符合消息交换协议的消息的数据形式的处理单元，所以即使是用与以往同样的方法开发出的Web服务功能，也能够处理该消息。因此，能够不依赖于消息的描述形式来容易地开发图像形成装置中的Web服务功能。此外，能够容易地改进已经安装的应用程序来支持Web服务。再者，能够扩大与图像形成装置上可连接的其他系统的合作。

以上说明了本发明的优选实施例，但是本发明并不限于此，在本发明的要点的范围内可用进行各种变形及变更。

本发明的融合机1200可以具有：多个变换单元，分别对应于多个Web服务处理单元，将根据规定消息变换协议接收到的上述请求消息变换为上述Web服务处理单元可处理的处理请求，并且将从该Web服务处理单元输出的上述处理结果变换为符合该消息变换协议的响应消息。

此外，在本发明的融合机1200中，请求消息及响应消息可以根据SimpleObject Access Protocol(简单对象访问协议)用Extensible Markup Language(可扩展单元语言)来描述。

再者，程序语言可处理的第二数据形式及表示Web服务处理单元输出的处理结果的第三数据形式可以表示C语言可处理的结构体。

此外，本发明的融合机1200可以具有：通信控制单元，根据规定通信协议来控制通信；和连接控制单元，通过向连接管理单元通知已经上述网络接收到处理请求，来控制上述通信控制单元和上述服务提供单元之间的连接，该服务提供单元根据上述规定通信协议，根据上述处理请求使上述Web服务处理单元执行处理，将其处理结果作为处理响应提供给上述设备。

再者，上述规定通信协议可以是Hypertext Transfer Protocol(超文本传送协议)。

此外，本发明的融合机1200可以具有：应用程序，具有多个上述Web服务处理单元；控制服务，管理上述图像形成处理中利用的多个硬件资源，并且按照来自上述应用程序的利用请求，来控制对该多个硬件资源的利用；操作系统，控制该应用程序和该控制服务。

可以使本发明的融合机1200具有将上述请求消息变换为表示该请求消息的结构的第一数据形式的第一消息变换步骤；上述变换步骤具有：第一数据形式变换步骤，使上述第一数据形式对应于开发上述Web服务处理步骤的程序语言可处理的第二数据形式。

在本发明的融合机1200进行的Web服务提供方法中，将请求消息变换为表示该请求消息的结构的第一数据形式的第一消息变换步骤可以由上述请求消息根据构成该请求消息的元素和对该元素设置的值来生成元素树，将该元素树作为上述第一数据形式。

此外，在这种Web服务提供方法中，上述第一数据形式变换步骤通过遍历上述元素树的上述元素间的关联，将值设置到上述Web服务处理步骤可处理的上述第二数据形式的元素中。

再者，在Web服务提供方法中，可以具有：第二数据形式变换步骤，将上述规定的程序语言可处理的、表示上述Web服务步骤进行的Web服务的处理结果的第三数据形式变换为表示响应消息的结构的第四数据形式，该响应消息表示该处理结果；和第二消息变换步骤，根据用上述第四数据形式表示的上述响应消息的结构，用上述设备可接收的描述形式来描述该响应消息。

此外，在Web服务提供方法中，上述第二数据形式变换步骤可以根据作为上述处理结果而设置到上述第三数据形式的元素中的值和构成上述响应消息的多个元素来生成元素树，将该元素树作为上述第四数据形式。

以上说明了本发明的优选实施例，但是本发明并不限于此，在本发明的要点的范围内可用进行各种变形及变更。

Claims (40)

1、一种图像形成装置，其特征在于，具有：

应用程序，执行与图像形成有关的处理；

多个通信协议守护程序，根据互不相同的通信协议来发送接收数据；以及

连接请求中介单元，按照来自上述各通信协议守护程序的连接通知，取代该通信协议守护程序，通过向上述应用程序通知该通信协议守护程序有连接请求来中介连接。

2、如权利要求1所述的图像形成装置，其特征在于，具有：共享存储器，由上述应用程序和上述通信协议守护程序共享，用于保存接收数据及发送数据，在上述应用程序和该多个通信协议守护程序之间传递该接收数据及该发送数据。

3、如权利要求1所述的图像形成装置，其特征在于，上述连接请求中介单元具有：

注册单元，按照来自上述应用程序的注册请求来注册该应用程序；和

缓冲器注册单元，按照来自上述应用程序的发送接收缓冲器注册请求，来注册该应用程序专用的接收缓冲器及发送缓冲器并将其设为可用状态。

4、如权利要求2或3中任一项所述的图像形成装置，其特征在于，上述连接请求中介单元具有：

发送接收缓冲器分配单元，收到来自上述各通信协议守护程序的连接通知后，在上述共享存储器内分配上述连接中使用的接收缓冲器和发送缓冲器，通知给上述通信协议守护程序。

5、如权利要求1至4中任一项所述的图像形成装置，其特征在于，上述应用程序具有：

连接处理单元，从上述连接请求中介单元接收到连接的通知后，向该连接请求中介单元通知连接许可，并且与上述通信协议守护程序相连；以及

数据接收开始请求单元，请求上述通信协议守护程序开始接收数据。

6、如权利要求4或5所述的图像形成装置，其特征在于，上述各通信协议守护程序具有：

接收数据写入单元，上述通信协议守护程序将接收数据写入到上述发送接收缓冲器分配单元分配的上述接收缓冲器中，将写入开始位置移动与数据长度对应的量；以及

接收写入通知单元，向上述应用程序通知已向上述接收缓冲器中写入上述接收数据，并且进行指定该接收数据的写入开始位置和写入结束位置的写入通知。

7、如权利要求6所述的图像形成装置，其特征在于，上述应用程序具有：

接收数据读入单元，从上述通信协议守护程序接收到上述接收数据的写入通知后，从该写入通知指定的上述写入开始位置至上述写入结束位置从上述接收缓冲器中读出上述接收数据，将读出开始位置移动到该写入结束位置；以及

接收读出通知单元，向上述通信协议守护程序通知已从上述接收缓冲器中读出上述接收数据。

8、如权利要求4至7中任一项所述的图像形成装置，其特征在于，上述应用程序具有：

发送数据写入单元，向上述缓冲器注册单元注册过的上述发送缓冲器中写入发送数据，将写入开始位置移动与数据长度对应的量；以及

发送写入通知单元，向上述通信协议守护程序通知已向上述发送缓冲器中写入上述发送数据，并且进行指定该发送数据的写入开始位置和写入结束位置的写入通知。

9、如权利要求8所述的图像形成装置，其特征在于，上述各通信协议守护程序具有：发送数据读出单元，从上述应用程序接收到上述发送数据的写入通知后，从该写入通知指定的上述写入开始位置至上述写入结束位置从上述发送缓冲器中读出上述发送数据，使与上述应用程序相连的上述通信协议守护程序发送该发送数据；

读出开始位置移动单元，将上述读出开始位置移动到上述写入结束位置；以及

发送读出通知单元，向上述应用程序通知已从上述发送缓冲器中读出上述发送数据。

10、一种数据发送接收控制方法，控制计算机根据互不相同的通信协议在多个通信协议守护程序和多个应用程序之间进行的数据发送接收，其特征在于，该方法包括：

连接请求中介步骤，按照来自上述各通信协议守护程序的连接通知，取代该通信协议守护程序，通过向上述应用程序通知该通信协议守护程序有连接请求来中介连接；以及

数据发送接收控制步骤，控制经上述多个通信协议守护程序共享的共享存储器与上述应用程序进行的接收数据及发送数据的传递。

11、一种图像形成装置，其特征在于，具有：

多个方法处理单元，根据方法来进行规定的处理；以及

Web服务执行单元，按照处理请求，通过向与该处理请求指定的上述方法对应的上述方法处理单元分配该处理请求来执行Web服务。

12、如权利要求11所述的图像形成装置，其特征在于，具有：多个Wcb服务应用程序，共享同一方法中的处理，进行与图像形成有关的处理作为上述Web服务。

13、如权利要求11或12所述的图像形成装置，其特征在于，

上述多个方法处理单元之一的第一方法处理单元具有：描述处理单元，处理用规定描述形式描述的上述处理请求的主体部；

根据上述描述处理单元的处理结果，来执行上述Web服务应用程序。

14、如权利要求11或12所述的图像形成装置，其特征在于，上述多个方法处理单元之一的第一方法处理单元具有：

多个处理单元，对于指定上述第一方法处理单元的上述第一方法，执行与上述处理请求的指定主体部的描述形式的头对应的规定的处理；以及

第一分配处理单元，向与上述处理请求指定的内容类型对应的上述处理单元分配该处理请求；

在上述处理请求指定了上述第一方法的情况下，上述Web服务执行单元将该处理请求分配给上述第一分配处理单元，上述第一分配处理单元将上述处理请求分配给与上述头对应的上述处理单元，根据该处理单元的处理结果，来执行上述Web服务应用程序。

15、如权利要求11至14中任一项所述的图像形成装置，其特征在于，

上述多个方法处理单元之一的第二方法处理单元具有：

第二分配处理单元，对于指定上述第二方法处理单元的上述第二方法，根据标识上述Web服务应用程序的标识信息，将上述处理请求分配给该Web服务应用程序；

在上述处理请求指定了上述第二方法的情况下，上述Web服务执行单元将该处理请求分配给上述第二分配处理单元。

16、如权利要求12至15中任一项所述的图像形成装置，其特征在于，具有：

Web通信协议守护程序，经Web来进行通信控制；以及

连接处理单元，通过与上述Web通信协议守护程序相连来生成，控制在该Web通信协议守护程序和上述Web服务应用程序之间进行的从规定存储区域中读入接收数据及向该规定存储区域中写入发送数据。

17、如权利要求16所述的图像形成装置，其特征在于，具有：

连接通知队列，将连接通知保存为队列；

Web连接管理单元，用上述连接通知队列，来管理上述Web服务执行单元和上述Web通信协议守护程序之间的连接；以及

连接请求中介单元，替上述Web通信协议守护程序，向上述Web连接管理单元通知已从上述Web通信协议守护程序发出上述连接通知；

上述Web连接管理单元按照来自上述Web服务执行单元的连接请求，替上述Web服务应用程序，从上述连接通知队列中取出上述连接通知，与上述Web通信协议守护程序相连。

18、如权利要求17所述的图像形成装置，其特征在于，

上述Web连接管理单元与上述Web通信协议守护程序相连后，生成上述连接处理单元，向上述Web服务执行单元通知与上述连接有关的连接管理信息；

上述Web服务执行单元接受上述通知，将上述处理请求分配给与该处理请求指定的方法对应的上述方法处理单元。

19、如权利要求12至18中任一项所述的图像形成装置，其特征在于，具有：

控制服务，管理上述图像形成处理中利用的多个硬件资源，并且按照来自上述多个Web服务应用程序的利用请求，来控制对该多个硬件资源的利用；以及

操作系统，控制该多个Web服务应用程序和该控制服务。

20、一种图像形成方法，其特征在于，使计算机执行：

多个方法处理步骤，根据方法来进行规定的处理；以及

Web服务执行步骤，按照处理请求，通过向与该处理请求指定的上述方法对应的上述方法处理步骤分配该处理请求来执行Web服务。

21、一种图像形成装置，其特征在于，具有：

Web服务处理单元，根据来自经网络连接的设备的请求消息来执行处理，提供其处理结果作为Web服务；和

变换单元，将根据规定消息交换协议接收到的上述请求消息变换为上述Web服务处理单元可处理的处理请求，并且将从该Web服务处理单元输出的上述处理结果变换为符合该消息交换协议的响应消息。

22、如权利要求21所述的图像形成装置，其特征在于，具有：

第一消息变换单元，将上述请求消息变换为表示该请求消息的结构的第一数据形式；

上述变换单元具有第一数据形式变换单元，该单元使上述第一数据形式对应于开发上述Web服务处理单元的程序语言可处理的第二数据形式。

23、如权利要求22所述的图像形成装置，其特征在于，上述第一消息变换单元由上述请求消息根据构成该请求消息的元素和对该元素设置的值来生成元素树，将该元素树作为上述第一数据形式。

24、如权利要求23所述的图像形成装置，其特征在于，上述第一数据形式变换单元通过遍历上述元素树的上述元素间的关联，将值设置到上述Web服务处理单元可处理的上述第二数据形式的元素中。

25、如权利要求24所述的图像形成装置，其特征在于，具有：

第二消息变换单元，根据上述响应消息的结构，用上述设备可接收的描述形式来描述该响应消息；

上述变换单元具有第二数据形式变换单元，将上述Web服务处理单元输出的表示上述处理结果的第三数据形式变换为表示响应消息的结构的第四数据形式，该响应消息表示该处理结果；

上述响应消息用上述第四数据形式来表示。

26、如权利要求25所述的图像形成装置，其特征在于，上述第二数据形式变换单元根据作为上述处理结果而设置到上述第三数据形式的元素中的值和构成上述响应消息的多个元素来生成元素树，将该元素树作为上述第四数据形式。

27、如权利要求21至26中任一项所述的图像形成装置，其特征在于，具有：

方法判断单元，判断根据规定通信协议接收到的处理请求是否是通过上述请求消息来进行处理请求的方法；

分配单元，根据上述方法判断单元的判断结果，将上述处理请求分配给上述第一消息变换单元。

28、如权利要求27所述的图像形成装置，其特征在于，具有：

头解析单元，解析上述处理请求的头部来取得指定Web服务的Web服务指定信息；以及

分配单元，根据上述头解析单元的解析结果，通过将上述第一消息变换单元变换出的上述第一数据形式作为变元对应的上述多个变换单元之一进行函数调用，来分配处理。

29、如权利要求27所述的图像形成装置，其特征在于，具有：

Web服务指定信息取得单元，解析上述处理请求的主体部的基于上述规定描述形式的元素名来取得指定Web服务的Web服务指定信息；和

分配单元，根据上述Web服务指定信息取得单元的解析结果，通过将上述第一消息变换单元变换出的上述第一数据形式作为变元对应的上述多个变换单元之一进行函数调用，来分配处理。

30、如权利要求27所述的图像形成装置，其特征在于，具有：

连接管理单元，根据上述规定通信协议，经网络来管理与设备之间的连接；以及

服务提供单元，在从上述连接管理单元接收到上述连接的通知后，根据上述规定通信协议，根据上述处理请求使上述Web服务处理单元执行处理，将其处理结果作为处理响应提供给上述设备。

31、一种Web服务提供方法，其特征在于，使计算机执行：

Web服务处理步骤，根据来自经网络连接的设备的请求消息来执行处理，提供其处理结果作为Web服务；以及

变换步骤，将根据规定消息交换协议接收到的上述请求消息变换为上述Web服务处理步骤可处理的处理请求，并且将从该Web服务处理步骤输出的上述处理结果变换为符合该消息交换协议的响应消息。

32、一种计算机可读的程序，用于使计算机执行：

元素树生成步骤，解析定义Web服务的接口的接口定义，来生成表示构成该接口定义的多个元素间的关联的第一元素树；以及

变换程序生成步骤，根据上述第一元素树，来生成进行执行上述Web服务的Web服务功能可处理的输入输出数据形式和用规定描述形式描述的与该Web服务有关的请求及响应消息之间的变换处理的变换程序。

33、如权利要求32所述的程序，其特征在于，上述变换程序生成步骤具有：

第一程序生成步骤，生成进行上述Web服务功能可处理的上述输入输出数据形式和用上述规定描述形式描述的上述请求及响应消息设置的输入输出消息之间的变换的数据类型变换程序；以及

第二程序生成步骤，解析用上述规定描述形式描述的上述请求消息，并且生成用于生成上述响应消息的第二程序。

34、如权利要求32或33所述的程序，其特征在于，上述第二程序生成步骤具有：

第二代码生成步骤，将表示构成上述请求消息的多个元素间的关联的第二元素树的末端中设置的值，变换为上述Web服务功能可处理的输入数据形式；

第三代码生成步骤，生成对上述Web服务功能进行函数调用的第三代码；以及

第四代码生成步骤，生成表示构成上述响应消息的多个元素间的关联的第三元素树，并且生成将上述Web服务功能的返回值设置到该第三元素树的末端中的第四代码。

35、如权利要求32至34中任一项所述的程序，其特征在于，具有：

第一函数声明步骤，根据上述第一元素树，用上述接口定义指定的服务名和操作名来生成执行通过上述变换程序生成步骤生成的上述变换程序的第一函数的函数名，用该函数名来声明该第一函数；以及

第二函数声明步骤，根据上述第一元素树，用上述接口定义指定的服务名和操作名来生成执行上述Web服务功能的第二函数的函数名，用该接口定义指定的该服务名和输入消息名及输出消息名来决定变元的类型和变元名，用该函数名和变元名来声明该第二函数。

36、如权利要求35所述的程序，其特征在于，具有：

第一结构体定义步骤，根据上述第一元素树，用上述接口定义指定的上述服务名和上述输入消息名来生成输入数据的结构体名，用该接口定义指定的参数类型、和参数名来构成、定义上述Web服务功能可处理的输入数据结构体；以及

第二结构体定义步骤，根据上述第一元素树，用上述接口定义指定的上述服务名和上述输出消息名来生成输出数据的结构体名，用该接口定义指定的参数类型、和参数名来构成、定义上述Web服务功能可处理的输出数据结构体。

37、如权利要求34所述的程序，其特征在于，具有：

类型定义生成步骤，根据上述第一元素树中的数据类型的定义，来生成上述Web服务功能可处理的类型定义；以及

数据类型函数声明生成步骤，生成将上述第二元素树中的保存输入数据的元素变换为上述Web服务功能可处理的定义类型的数据类型变换函数的声明。

38、如权利要求37所述的程序，其特征在于，具有：数据类型函数声明生成步骤，根据上述类型定义，来生成将上述Web服务功能的上述输出数据的数据类型变换为上述第三元素树中的保存输出数据的元素的数据类型变换函数的声明。

39、如权利要求32所述的程序，其特征在于，上述元素树生成步骤解析用Extensible Markup Language(可扩展标记语言)描述的上述接口定义来生成上述第一元素树。

40、如权利要求32至38中任一项所述的程序，其特征在于，上述变换程序生成步骤生成的上述变换程序可在控制进行图像形成处理的应用程序和上述图像形成处理利用的硬件资源的操作系统上执行。

Images