具体实施方式
以下将参照附图详细描述本发明的各种示例性实施例、特征及方面。
首先，以下将对本发明的各示例性实施例中使用的术语的定义进行说明。在本发明中，“打印数据处理”是指用于将用户期望打印的内容转换成可在诸如多功能外围设备(MFP)或打印机的图像形成装置上打印的数据的处理。
“内容”是指包括文档数据(例如文本)和图像数据(例如包括位图(BMP)的光栅图像)的组合的电子数据。另外，“打印数据”是指通过打印数据处理来转换内容而生成的数据。更具体地，打印数据包括页面描述语言(PDL)数据、便携式文档格式(PDF)数据以及光栅图像。
以下将参照图1来详细描述根据本示例性实施例的网络打印系统1000中包含的各个装置。参照图1，网络打印系统1000中包含的各个装置经由网络100相互通信。网络打印系统1000中包含的装置有服务器计算机102、文档服务器103、图像形成装置104、客户计算机105、文档提取服务器107、文档转换服务器108以及打印服务器109。在本示例性实施例中，网络打印系统1000也称作“云计算系统”。
网络100是用于在上述各个装置之间进行数据通信的通信线路。互联网101是用于越过防火墙在上述各个装置之间进行数据通信的通信线路。经由互联网101，能够越过防火墙从包括图像形成装置104和客户计算机105的网络100执行与包括服务器计算机102的网络100的通信。
网络100和互联网101是支持传输控制协议/互联网协议(TCP/IP)的通信网络。经由网络100和互联网101的通信可以是有线的或者无线的。在本发明的示例性实施例中，在图1所示的示例中，尽管服务器计算机102被例示为一台服务器，但是假定服务器计算机102包括多个服务器计算机。
以下将详细描述图1所示的网络打印系统1000中包含的各个装置的示例性内部结构。首先，将在下面参照图2详细描述图像形成装置104的示例性内部结构。图2是例示图像形成装置104的示例性内部结构的框图。
图像形成装置104包括图像处理单元201、打印单元202以及读取单元203。图像处理单元201包括中央处理单元(CPU)204、直接存储单元205、间接存储单元206、用户接口207和外部接口208。
CPU 204是执行预定程序并指示对图像形成装置104的各种控制操作的单元。直接存储单元205是CPU 204在执行程序时使用的工作存储器。由CPU 204执行的程序被加载到直接存储单元205。直接存储单元205由随机存取存储器(RAM)实现。
间接存储单元206存储诸如应用程序和平台程序的各种程序。存储在间接存储单元206上的各种程序在CPU 204执行该程序时，被CPU 204移动至直接存储单元205。间接存储单元206由固态驱动器(SSD)或硬盘驱动器(HDD)实现。多处理器也可以用作CPU 204。
以下将详细描述通过执行平台程序实现的平台。通过实现平台，能够在图像形成装置104上执行用户独创开发的新应用，并定制图像形成装置104的操作画面。
以下将详细描述用于实现平台的示例性方法。CPU 204将存储在间接存储单元206上的平台程序移动至直接存储单元205。当平台程序被完全移动至直接存储单元205时，CPU 204能够执行平台程序。
在本示例性实施例中，当CPU 204执行平台程序时，平台被“起动”。该平台在图像形成装置104的固件上运行。另外，平台程序提供用于执行通过使用面向对象语言来描述的应用程序的环境。
以下将详细描述用于在平台上执行应用程序的方法。在本示例性实施例中，接收打印请求的打印软件在平台上运行。该打印软件通过使用诸如超文本传输协议(HTTP)的通信协议，能够从经由网络连接的设备接收打印数据。
打印软件将接收到的打印数据发送给固件。在接收到打印数据后，固件开始打印数据处理。如果打印数据具有在不执行打印数据处理的情况下就能够对打印数据进行打印的格式，则固件省略打印数据处理。如上所述，本发明的示例性实施例能够通过在平台上执行应用程序，来实现对图像形成装置104的控制。
以下将详细描述用于执行应用程序的示例性方法。平台在被起动后，将存储在间接存储单元206上的应用程序移动至直接存储单元205。在移动应用程序之后，平台就能够执行应用程序。然后，平台执行应用程序。
在本示例性实施例中，平台的上述能够提供用于在平台上执行应用程序的服务的功能被称作“平台应用”。另外，平台能够执行本示例性实施例中记载的各个流程图中例示的各个处理的一部分。
用户接口207是用于接收用户输入的处理请求的单元。更具体地说，用户接口207接收对应于用户经由键盘或鼠标输入的指令的信号。外部接口208能够向外部装置发送数据以及从外部装置接收数据。另外，外部装置可以包括诸如外部HDD或外部通用串行总线(USB)存储器的外部存储设备，或者经由网络连接的单个主计算机或单个图像形成装置。图像形成装置104可以经由网络100及互联网101与客户计算机105及服务器计算机102通信。
打印单元202具有用于将经历了打印数据处理的打印数据打印在记录介质上的功能。读取单元203具有用于读取放置在原稿台上的文档并生成文档图像的功能。在本示例性实施例中，读取单元203是扫描器。
其次，将在下面参照图3详细描述信息处理装置106的示例性内部结构，该信息处理装置106包括服务器计算机102、文档服务器103、客户计算机105、文档提取服务器107、文档转换服务器108以及打印服务器109。图3是例示信息处理装置106的示例性内部结构的框图。
信息处理装置106包括CPU 301、直接存储单元302、间接存储单元303、用户接口304和外部接口305。用户接口304是用于接收用户输入的处理请求的单元。更具体地说，用户接口304接收对应于用户经由键盘或鼠标输入的指令的信号。
CPU 301执行预定的程序，并输入用于控制信息处理装置106的各种指令。直接存储单元302是CPU 301在执行程序时使用的工作存储器。由CPU 301执行的程序被加载到直接存储单元302上。直接存储单元302由RAM实现。
间接存储单元303存储诸如应用程序和操作系统(OS)的各种程序。存储在间接存储单元303上的各个程序在CPU 301执行该程序时，被移动至直接存储单元302。间接存储单元303包括只读存储器(ROM)或HDD。外部接口305连接至网络100。因此，信息处理装置106能够与网络100上的其他装置通信。
以下将参照图4来详细描述根据本示例性实施例的打印系统1000中包含的各个装置的功能。图4是例示打印系统1000中包含的各个装置的功能的示例的框图。
首先，将详细描述服务器计算机102的功能。在本示例性实施例中，服务器计算机102包括诸如请求接收单元401、后端处理单元402、表存储服务403、Blob(大型二进制对象，Binary Large Object)存储服务404以及队列存储服务405等的各种功能。在本示例性实施例中，存在具有请求接收单元401的至少一个服务器计算机。
此外，存在具有后端处理单元402的至少一个服务器计算机。另外，存在具有表存储服务403、Blob存储服务404和队列存储服务405的功能的至少一个服务器计算机。上述功能可以被提供给相互不同的服务器计算机。
请求接收单元401提供用于接收从客户计算机105或图像形成装置104发送的处理请求的功能。后端处理单元402具有用于通过使用处理程序来对处理请求进行处理的功能。在本示例性实施例中，“处理请求”是指由请求接收单元401接收到的处理请求。
后端处理单元402将处理程序加载到当前执行后端处理单元402的服务器计算机的直接存储单元302上并执行。请求接收单元401和后端处理单元402通过CPU 301将存储在间接存储单元303(图3)上的请求接收程序或后端处理程序加载到直接存储单元302上并执行这种程序来实现。以下将详细描述请求接收单元401和后端处理单元402。
表存储服务403提供用于存储诸如由后端处理单元402执行的处理的进行状态等的各种状态信息的功能。表存储服务403通过CPU 301将表存储服务程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。此外，数据被存储在间接存储单元303上。以下将详细描述表存储服务403。
Blob存储服务404提供用于存储诸如由后端处理单元402执行的处理的执行结果数据等的各种数据的功能。Blob存储服务404通过CPU 301将Blob存储服务程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。数据被存储在间接存储单元303上。以下将详细描述Blob存储服务404。
队列存储服务405提供以下两种功能。第一，队列存储服务405具有用于在请求接收单元401和后端处理单元402之间建立异步数据通信的功能。第二，队列存储服务405具有用于使添加到队列中的队列消息变得不可见或可见的功能。“队列”是指由队列存储服务405实现的存储功能。另外，队列通过列表结构“先入先出(FIFO)”来实现。
以下将详细描述第一种功能。请求接收单元401和后端处理单元402通过以下方法相互通信。首先，请求接收单元401在接收到用户输入的处理请求之后，生成与来自用户的处理请求对应的票单(ticket)“队列消息”。
队列消息600被请求接收单元401存储在队列中。在从队列获取队列消息600后，后端处理单元402参照队列消息600并对来自用户的处理请求进行处理。以上述方式，后端处理单元402针对来自用户的处理请求提供解决方案。
通过利用队列服务405，请求接收单元401和后端处理单元402能够异步地相互通信。以下将更加详细地描述第一种功能和第二种功能。
队列存储服务405通过CPU 301将队列存储服务程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。数据被存储在间接存储单元303上。服务器计算机102具有上述功能。以下将更加详细地描述服务器计算机102的功能。
以下将更加详细地描述文档服务器103的示例性功能。文档服务器103具有文档仓库(repository)406的功能。文档仓库406由图3所示的间接存储单元303实现。更具体地说，文档仓库406存储由用户指示的要从客户计算机105或图像形成装置104打印的内容。存储在文档仓库406上的内容包括预先存储的内容以及以下内容。
换句话说，文档仓库406还存储用户经由浏览器407或设备浏览器409(以下将详细描述)通过使用在服务器计算机102上运行的应用而生成的内容。因此，如果通过使用服务器计算机102上的应用来生成内容，则无需在客户计算机105上安装应用就能够容易地打印该内容。
在服务器计算机102上运行的应用是指各种应用，诸如文档生成应用、图像生成应用和表单(form)管理应用。应用被存储在图3所示的间接存储单元303上。当输入用于执行应用的指令时，由CPU 301将应用加载到直接存储单元302上并执行。
以下将详细描述图像形成装置104。图像形成装置104包括设备浏览器409和平台应用408的功能。设备浏览器409具有用于允许用户对存储在经由网络100连接的设备中的数据和信息进行查看的功能。设备浏览器409通过CPU 204将设备浏览器程序从间接存储单元206(图2)加载至直接存储单元205上并执行该程序来实现。
此外，用户能够经由设备浏览器409输入用于打印内容的指令。输入的打印指令被发送至服务器计算机102的请求接收单元401。设备浏览器409例如是Web浏览器。
平台应用408提供用于实现各种服务的功能。平台应用408通过平台上运行的应用程序来实现。在本示例性实施例中，平台应用408提供打印软件服务。如上所述，服务能够将接收到的打印数据发送至固件。
此外，服务对请求接收单元401是否已完成用于生成打印数据的处理进行验证。更具体地说，服务基于请求接收单元401生成的作业标识(ID)，来确定请求接收单元401是否已完成用于生成打印数据的处理。
以下将详细描述客户计算机105。客户计算机105提供浏览器407的功能。浏览器407提供用于允许用户对存储在经由网络100连接的设备中的数据和信息进行查看的功能。浏览器407通过CPU 301将浏览器程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。浏览器407例如是Web浏览器。
以下将详细描述文档提取服务器107。文档提取服务器107提供文档提取服务410的功能。文档提取服务器410通过CPU 301将文档提取程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。文档提取服务410提供用于根据经由外部接口305接收到的文档提取指令来访问文档服务器103、以及用于获取存储在文档仓库406上的内容的功能。如上所述，文档提取服务410提供Web服务。
以下将详细描述文档转换服务器108。文档转换服务器108具有文档转换服务411的功能。文档转换服务411通过CPU 301将文档转换程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。
文档转换服务411包括用于根据经由外部接口305接收到的文档转换指令、将指示的数据(内容)转换成预定数据格式的功能。更具体地说，在本示例性实施例中，文档转换服务411包括用于将内容转换成便携式文档格式(PDF)数据的功能。如上所述，文档转换服务411提供Web服务。
最后进行关于信息处理装置106的组件的说明，以下将详细描述打印服务器109。打印服务器109具有假脱机(spool)服务412的功能。假脱机服务412通过CPU 301将假脱机程序从间接存储单元303(图3)加载到直接存储单元302上并执行该程序来实现。假脱机服务412具有用于根据经由外部接口305接收到的指令来生成并分配对指示的数据进行打印所需的属性(即诸如打印优先级的信息或色调(tint)信息)的功能。如上所述，打印服务器109提供Web服务。
根据本示例性实施例的网络打印系统1000中包括的各个装置具有上述功能。
以下将参照图5详细描述服务器计算机102的平台系统。图5例示了平台系统500的各种示例性功能。参照图5，服务器计算机102中存在的物理硬件资源用来实现平台系统500，该平台系统500包括两个平台设备。利用服务器计算机102的平台系统500的人能够使用服务器计算机102中包括的物理硬件资源作为计算资源。此外，平台系统500是提供分布式(划分式)环境的系统。
服务器计算机102的平台系统(操作系统(OS))500提供以下功能：
虚拟机501和502
结构控制器(fabric controller)503
负载均衡器504
队列存储服务(“Queue”)505
表存储服务(“Table”)506
Blob存储服务(“Blob”)507
在服务器计算机102上实现的平台系统500包括多个虚拟机501和502。“虚拟机”是指通过使用虚拟化方法将服务器计算机102划分成逻辑计算机、并且在所划分的逻辑计算机中通过使用独立OS来操作的逻辑计算机。以“例(instance)”为单位对逻辑计算机进行计数。在本示例性实施例中，将服务器计算机102中包含的一个服务器计算机分配给一例(即，一个虚拟机)。
虚拟机501包括请求接收单元(“Web角色例”)509和请求接收单元代理(“代理”)510。请求接收单元509经由负载均衡器504(以下将详细描述)接收来自用户的处理请求。另外，请求接收单元509将处理请求经由队列存储服务505发送至虚拟机502。
为了确保请求接收单元509的高可用性，经由在虚拟机501的外部提供的负载均衡器504来执行来自外部网络的请求(在本发明的示例性实施例中，是通过HTTP进行的通信)。
负载均衡器504集中管理通过外部网络输入的请求。此外，负载均衡器504选择性地向具有与请求接收单元509类似的请求接收功能的多个虚拟机传送请求。
请求接收单元代理510收集包括虚拟机501的使用状态、请求接收单元509的运行状态、虚拟机501的资源使用状态以及请求接收单元509上发生的错误的各种信息。另外，请求接收单元代理510将收集的信息周期性地发送给结构控制器503。
虚拟机501等同于图4所示的请求接收单元401。虚拟机501通过请求接收程序来实现。虚拟机501的各种功能在请求接收程序的控制下被执行。
请求接收单元509和后端处理单元511的各例由结构控制器503来管理。因此，各例的可扩展性(scalability)和可用性得以确保。更具体地说，假定请求接收单元509或后端处理单元511的特定例由于服务器中的故障而被暂停。在这种情况下，结构控制器503不能从请求接收单元代理510或后端处理单元代理512接收到周期性通知。
如果结构控制器503没有接收到周期性通知，则结构控制器503向虚拟机输入指令，以委托新的例来执行处理。换句话说，新的虚拟机用作由于故障或者相当于故障的事件而不能被起动的虚拟机的替代。结果，当前执行处理的例的数量能够保持恒定。因此，能够抑制处理的延迟。
虚拟机502包括后端处理单元(“工人角色例”)511和后端处理单元代理(“代理”)512。后端处理单元511经由队列存储服务505接收由请求接收单元509输入的处理请求。后端处理单元511执行经由队列存储服务505从请求接收单元509接收到的处理请求。此外，后端处理单元511执行标出(scale out)。
“标出”是指由于虚拟机502的数量增加而产生的后端处理单元511的例数量增加。当后端处理单元511的例增加时，分配给一个后端处理单元的数据处理的量减少。因此，在该情况下，用户输入的处理请求的执行结果能够被非常迅速地返回。请求接收单元509接收标出指令。虚拟机502等同于图4所示的后端处理单元402。虚拟机502通过后端处理程序来实现。虚拟机502的各种功能在后端处理程序的控制下被执行。
队列服务505提供用于在请求接收单元509与后端处理单元511之间实现异步数据通信的服务。请求接收单元509和后端处理单元511通过向队列存储服务505输入各种指令来执行异步数据通信。以下将详细描述请求接收单元509与后端处理单元511之间的异步数据通信。请求接收单元509输入给队列存储服务505的指令包括队列消息添加指令。后端处理单元511输入给队列存储服务505的指令包括队列消息获取指令和队列消息删除指令。
以下将详细描述在请求接收单元509与后端处理单元511之间执行的一系列异步数据通信操作。请求接收单元509根据用户输入的处理请求生成队列消息600。此外，请求接收单元509将队列添加指令发送给队列存储服务505，该队列添加指令指示将队列消息600添加到队列。在接收到队列添加指令后，队列存储服务505将队列消息600添加到队列。
为了获取队列消息600，后端处理单元511将队列消息获取指令输入给队列存储服务505。在接收到队列消息获取指令后，队列存储服务505响应于该队列消息获取指令，将队列消息600以及对各队列消息600唯一分配的消息ID和作业ID返回给后端处理单元511。
更具体地说，“消息ID”是指为了唯一定义队列消息600而对各队列消息600分配的唯一信息。在输入用于删除队列消息600的指令时，处理已经完成的后端处理单元511使用消息ID。作业ID是用于唯一定义实际处理的内容的ID。
在完成处理请求后，后端处理单元511将用于删除对应于消息ID的队列消息的指令输入给队列存储服务505。在接收到队列消息删除指令后，队列存储服务505删除对应于由后端处理单元511指示的消息ID的队列消息。因此，能够有效避免对同一队列消息进行处理的冗余处理，该冗余处理可能会被已经输出队列消息删除指令的后端处理单元511以外的其他后端处理单元511不利地执行。
另外，队列存储服务505具有用于使已被添加到队列中的队列消息600变得可见或不可见的功能。更具体地说，如果使队列消息600“不可见”，则即使后端处理单元511已经输入用于获取已被添加到队列中的队列消息600的请求，则队列存储服务505也不将队列消息600传送给后端处理单元511。
在从队列中获取到队列消息600之后，通过队列存储服务505使所获取到的队列消息变为可见。如果队列消息要变为“可见”，则在后端处理单元511已经输入用于获取已被添加到队列中的队列消息600的请求的情况下，队列存储服务505将队列消息传送给后端处理单元511。
通过队列存储服务405可以使已经被后端处理单元511获取并要成为可见的队列消息变得可见，除非在预定时间内从当前执行处理的后端处理单元511返回处理结果。术语“可见”是指上述的相同状态。因此，如果后端处理单元511已被异常终止并且不能继续处理，则将自动重试处理。
表存储服务506提供在存储数据时利用的存储器。表存储服务506将数据以简单格式进行存储，所述简单格式包括实体和类型信息的属性的组合。
Blob存储服务507提供在存储数据时利用的存储器。更具体地说，Blob存储服务507提供用于存储二进制数据的集合的功能。
以下将详细描述根据本示例性实施例的队列消息600。图6例示了队列消息600的示例。队列消息600描述请求接收单元509请求后端处理单元511执行的处理的内容。
参照图6，请求601表示队列消息600要被添加至的队列存储服务505的统一资源定位符(URL)。请求接收单元509分析图6所示的消息，并识别队列存储服务505的位置。另外，请求接收单元509输入图6所示的消息中的头602所包含的信息以及之后的信息。
头602存储用于访问队列存储服务505的认证信息。该认证信息包括利用队列存储服务505所需的字符串的散列值(hash value)。队列存储服务505读取头信息，并将所读取的头信息与预先存储在队列存储服务505中的字符串进行比较，以执行认证。另外，队列存储服务505确定包含头602的队列消息600是否能够被接受。
以下将详细描述队列消息600的消息数据内容部分。根据用户输入的处理请求来确定该消息数据内容部分。部分<MessageText>603表示作业ID。在图6所示的示例中，作业ID“pk01|job01”包含在部分<MessageText>603中。作业ID是根据用户输入的处理请求生成的唯一信息。换句话说，部分<MessageText>603中包含的作业ID等同于上述作业ID。
以下将详细描述根据本示例性实施例的作业表。作业表管理作为作业被后端处理单元402执行的一系列处理，并存储作业的内容以及作业的处理的进行状态。作业表被存储在表存储服务506中。
图7例示了实际存储的作业表700。参照图7，ETag字段701是由表存储服务506自动设置的值。如果字符串数据被更新，则在ETag字段701中写入唯一值。在更新从表中获取的数据时，如果在获取数据时ETag字段701的值与在更新数据时ETag字段701的值相互不同，则能够识别出该表已被另一处理(后端处理)更新。
划分关键字(Partition Key)字段702和行关键字(Row Key)字段703表示用于唯一识别表的各行的ID。在作业表700中，这两个关键字字段702和703的值识别作业。换句话说，这两个值等同于作业ID。然而，作为替代方案，可以仅由行关键字来定义作业ID。
对于开始时间(Start Time)字段704，登记由后端处理单元402处理的作业的处理开始日期和时间。对于结束时间(End Time)字段705，登记作业的处理结束日期和时间。在开始作业前或开始作业后，对开始时间字段704和结束时间字段705设置初始值。
状态(Status)字段706存储整个作业的状态。作业的状态包括“Ready”(准备完成)，“Processing”(处理当前正在执行中)，“Success”(作业处理成功)，以及“Failure”(作业处理失败)。
准备完成状态(“Ready”)表示在请求接收单元401已经将作业添加到作业表中之后、在后端处理单元402开始处理作业以前的状态。处理进行中状态(“Processing”)对应于在后端处理单元402已经开始作业的处理之后、并且在由作业定义的所有任务均已完成之前的状态，或者对应于在作业中途处理失败之前的状态。
作业处理成功(“Success”)表示后端处理单元402已经对作业中定义的所有任务进行了处理、并且所有任务的处理已被成功执行的状态。作业处理失败(“Failure”)表示作为后端处理单元402执行任务的结果、任务未被成功处理的状态，或者确定服务质量不满足执行任务前的预定参照条件的状态。
如上所述，一个作业包括一个或更多个任务。当作业中包含的一个或更多个任务的全部被完全处理时，一个作业的处理完成。
数据ID字段707存储分配给与作业相关联的数据的ID。数据ID被存储在Blob存储服务507中，并且是Blob存储服务507中的唯一值。
最后任务字段708记录已完成的任务的任务编号。作业包括要被顺次处理的多个任务。以下将详细描述“任务”。假定存在包含两个任务的作业，并且该作业的名称是“作业A”。作业A包括用于从文档服务器103获取文件的第一任务和用于向打印服务器109输入数据的第二任务的组合。在本发明中，第一任务被定义为“任务1”，第二任务被定义为“任务3”。通过顺次执行这两个任务来处理作业A。
如果处理已经进行到用于从文档服务器103获取文件的任务完成时，则在最后任务(Last Task)字段708中记录值“1”。如果尚未有任务的执行被完成，则在最后任务字段708中记录值“0”。另一方面，如果处理已经进行到用于向打印服务器109输入数据的任务完成时，则在最后任务字段708中记录值“3”。
尽管图中未示出，但是在本示例性实施例中，可以存在以下任务。换句话说，存在用于将通过第一任务获取的文件(内容)输入到文档转换服务器108、并且使文档转换服务器108转换所输入的内容的任务。在本发明中，将上述类型的任务定义为“任务2”。当任务2的执行完成时，在最后任务字段708中记录值“2”。通过参照最后任务字段708，能够验证任务的处理的当前进行状态。
在本示例性实施例中，按照预定顺序执行任务。更具体地说，按照任务1、任务2和任务3的顺序执行作业A中包含的任务。在服务序列表900中定义任务的执行顺序。以下将详细描述服务序列表900。
最后任务结果(LastTask Result)字段709存储最后执行的任务的处理结果。通过使用各种参数来管理任务处理结果，所述参数为诸如“None”(表示任务的处理完成之前的状态)、“Success”(任务成功完成)、“FailureRetry”(可以通过重试相同的处理来完成失败任务)以及“Failure”(任务失败)。针对各任务需要使用上述参数的任意一者来返回处理结果。如果任务的处理已被成功完成，则返回参数“Success”。
更具体地说，在将打印数据登记到打印服务器109中时，如果打印服务器109由于暂时的高处理负荷而不能完成处理或者如果暂时中断用于传送数据的通信，则任务返回以下值。更具体地说，任务针对未完成的或暂时中断的处理返回值“FailureRetry”，如果该未完成的或暂时中断的处理被再次执行，则极有可能成功完成。另一方面，如果暂停或中断的处理即使被再次执行也不太可能成功完成，即如果打印服务器109不支持要登记的打印数据的格式或者如果要对打印数据进行打印的图像形成装置104没有被打印服务器109识别，则针对该处理返回值“Failure”。
最后任务尝试计数(LastTask TryCount)字段710记录最后执行的任务已被执行了多少次。如果在处理结果具有值“FailureRetry”(可以通过重试相同的处理来完成失败任务)的情况下任务结束，则该任务要被再次执行。在这种情况下，记录最后执行的任务的执行次数。如果最后任务尝试计数字段710的值变为等于或大于预定次数的数值，即如果任务已被反复再次重试但是任务的处理仍未成功完成，则任务被控制作为错误。
最大任务(Max Task)字段711记录了相应作业中包含的任务的数量。在本示例性实施例中，一个作业中能够包含一个至二十个任务。这些任务具有连续的任务编号，诸如“任务1”、“任务2”和“任务3”。在本示例性实施例中，按照上述方式来处理任务1、任务2和任务3的各个。
从任务1服务ID(Task1 ServiceID)712至任务20参数(Task20Parameter)717的字段管理关于作业中包含的任务的信息。任务1服务ID 712存储提供要第一个执行的任务的服务的ID。任务1参数(Task1Parameter)713存储当执行任务1时传送给任务的参数。类似地，任务2服务ID(Task2S erviceID)714和任务2参数(Task2 Parameter)715存储关于第二个要执行的任务的信息。另外，任务20服务ID(Task20ServiceID)716和任务20参数717存储关于要第二十个执行的任务的信息。以上述方式来存储关于20个任务的任务信息。在本示例性实施例中，一个作业包含20个任务。然而，在本示例性实施例中，一个作业中能够包含的任务的数量并不限于特定的最大值。
以下将参照图8详细描述根据本示例性实施例的服务表。参照图8，服务表800管理提供任务的服务。如上所述，作业表700包括关于要执行的服务的信息。更具体地说，在作业表700中描述关于要执行的服务的信息，以便在任务执行时刻前后的时刻，写入作业处理以及任务的处理的进行状态。另一方面，对于服务表800，登记平台系统500的提供者预先从服务的提供者接收到的服务的定义。换句话说，服务表800不管理状态信息。
在本示例性实施例中，术语“服务的提供者”(或者术语“服务提供者”)是指提供利用文档提取服务器107、文档转换服务器108和打印服务器109的服务的用户。对此解释为，在本示例性实施例中，“服务的提供者”(或者术语“服务提供者”)是指提供任务1至任务3的用户。服务表800存储在表存储服务506中。
图8例示了服务表800的示例。参照图8，ETag字段801类似于图7所示的ETag字段701。划分关键字字段802和行关键字字段803表示用于唯一识别表的各行的ID。在服务表800中，划分关键字字段802具有固定值“服务”。行关键字字段803作为用于识别任务服务的ID被管理。以下将详细描述任务服务。
统一资源标识符(URI)字段804存储提供服务的Web服务的URL。用户能够通过访问具有URI字段804中管理的URI的地址来利用服务。更具体地说，从图8所示的服务表800可知，行关键字字段803具有值“服务01”的任务基于URI字段804来利用由文档提取服务器107提供的功能。
类型字段805存储服务类型。服务类型包括“IN”(输入服务)、“PIPE”(处理服务(pipe service))以及“OUT”(输出服务)。输入服务是用于执行从文档服务器103获取数据的处理的服务。更具体地说，输入服务是用于从外部系统输入数据的服务。输入服务通过执行任务1来实现。
PIPE服务是用于执行将文档数据转换成打印数据的处理的服务。更具体地说，PIPE服务是用于处理数据的服务。PIPE服务通过执行任务2来实现。输出服务是用于执行将数据输入到打印服务器109以由此输出数据的处理的服务。更具体地说，输出服务是用于将数据输出到外部系统的服务。输出服务通过执行任务3来实现。
在本示例性实施例中，用于实现具有类型“IN”、“PIPE”或“OUT”的各种服务的功能称为“任务服务”。如上所述，各任务服务由行关键字字段803来识别。
属性字段806存储关于任务服务的属性信息。属性信息被登记作为针对各任务服务唯一定义的信息。例如，在用于从文档服务器103获取数据的任务服务中，关于文档服务器103的URI的信息被存储在属性字段806中。在用于向打印服务器109输入作业的任务服务中，属性字段806存储关于打印服务器109的URI的信息。
对于验证字段807，登记表示关于在将服务登记到表中以前服务质量是否已被提供平台的厂商验证的信息的标记。如果标记的值为“TRUE(真)”，则确定服务在登记到表中以前其质量已被验证。换句话说，在这种情况下，确定针对服务确保了预定水平的质量。另一方面，如果标记的值为“FALSE(假)”，则确定服务在登记到表中以前其质量未被验证。换句话说，在这种情况下，确定质量水平未知。
更具体地说，在图8所示的示例中，由表可知，通过设置给验证字段807的值“TRUE”所指示，行关键字字段803具有值“服务03”的任务服务的质量已被确保。其他服务的质量未被确保。
换句话说，验证字段807具有值“TRUE”的服务的质量已被确保。因此，在这种情况下，能够有效利用平台系统500。另一方面，验证字段807具有除值“TRUE”以外的值的服务可能无谓地消耗平台系统500的资源，或者可能包含会攻击平台系统500的内容或信息。
以下将参照图9详细描述根据本示例性实施例的服务序列表。参照图9，服务序列表900管理服务处理顺序。出于以下目的，作业表700包含如上所述的服务处理顺序。对此解释为，服务处理顺序也包含在作业表700中，从而如果后端处理单元402按照处理顺序执行了任务，则在各任务的执行时刻前后的时刻写入该任务的处理状态以及接下来要执行的任务的任务编号，并且识别各任务的处理的进行状态。
另一方面，服务序列表900存储关于登记到服务表800的各种服务的组合的信息。以下将参照图9详细描述服务序列表900。更具体地说，由图9可知，能够被具有值“序列”、“seq01”的关键字字段902和903识别的作业包括三个任务，如最大任务字段904所指示的。另外，在图9所示的示例中，作业包括服务01、服务02以及服务03，如任务1字段905、任务2字段906以及任务3字段907所指示的。针对由任务1字段905、任务2字段906和任务3字段907定义的各个任务服务，能够通过参照服务表800来识别各个任务服务的类型。
服务序列表900被存储在表存储服务506中。
图9例示了服务序列表900的示例。参照图9，ETag字段901与图7所示的ETag字段701类似。划分关键字字段902和行关键字字段903表示用于唯一识别表的各行的ID。在服务序列表900中，划分关键字字段902具有固定值“序列”。行关键字字段903被作为序列ID管理。序列ID与作业ID的不同之处如下。对于序列ID，对请求了相同服务的所有处理请求分配共同的序列ID。另一方面，对于作业ID，如果请求了相同的服务，则对各个处理请求分配唯一的作业ID。作业ID用作识别处理请求的标识符。因此，能够识别登记到图7所示的作业表的各个作业所需的任务服务。
最大任务字段904存储序列中包含的任务数量的定义。在本示例性实施例中，能够在一个序列中识别一个至二十个任务。
任务1字段905至任务20字段909管理关于序列中包含的各个任务的信息。任务1字段905存储提供要第一个执行的任务的服务(任务服务)的ID。之后，类似地，任务2字段906存储关于要被执行的第二任务的信息。服务序列表900存储关于直到要第二十个执行的任务(其信息存储在任务20字段909中)的二十个任务的信息。如上所述，在本示例性实施例中，任务的最大数量为二十。然而，除二十以外的其他值也可以被设置为任务的最大数量。
以下将参照图12A至图12C详细描述根据本示例性实施例的、在登记到服务表800中的任务服务(即文档提取服务410、文档转换服务411和假脱机服务412)中实现的接口。
任务服务大体上能够被划分为三种类型，即“IN”、“PIPE”和“OUT”。预定接口是针对这三种类型中的各种而实现的。要执行的处理根据所实现的任务服务的类型而不同。IN型任务服务需要包含图12A所示的接口。在本示例性实施例中，文档提取服务410实现该接口。
参照图12A，执行指令接收单元1201从后端处理单元402接收任务执行指令以及参数。更具体地说，由执行指令接收单元1201接收到的参数是任务1参数713。在接收到任务执行指令后，执行指令接收单元1201执行处理程序。在执行处理程序1202后，作为应答将任务结束通知发送给后端处理单元402。
处理程序1202是被设计为执行特定处理的处理程序。如果任务服务是IN型任务服务，则处理程序1202执行这样一种处理，该处理用于在Web服务内生成数据，或者从诸如文档服务器103的外部服务器获取数据。处理程序1202将所生成的或所获取的数据存储在输出数据存储单元1203中。此外，处理程序120将任务执行结果(结果状态，诸如“Success”或“Failure”)存储在执行结果存储单元1204中。输出数据存储单元1203是存储作为执行任务的结果被输出的数据的区域。执行结果存储单元1204是存储任务执行结果(结果状态，诸如“Success”或“Failure”)的区域。
结果获取请求接收单元1205从后端处理单元402接收结果获取请求。此外，结果获取请求接收单元1205读取存储在输出数据存储单元1203和执行结果存储单元1204中的信息。另外，结果获取请求接收单元1205将数据返回给后端处理单元402。
属性获取请求接收单元1206根据来自后端处理单元402的属性获取请求，从属性信息存储单元1207获取适当的信息。此外，属性获取请求接收单元1206返回服务的属性。属性获取请求接收单元1207存储诸如服务ID、服务类型和开发者ID等的信息。服务ID与在将服务登记到服务表800时分配的服务ID相同。换句话说，序列ID是用于唯一识别服务的信息。服务类型是如上所述的关于任务服务的类型(IN型、PIPE型或OUT型)的信息。开发者ID使得能够识别任务服务的功能的开发者。对此解释为，开发者ID对应于开发了任务服务的用户。在本示例性实施例中，IN型任务服务称为“获取任务服务”。
PIPE型任务服务需要包含图12B所示的接口。在本示例性实施例中，文档转换服务411实现该接口。
输入数据接收单元1208将根据来自后端处理单元402的输入数据存储请求而发送的数据存储在输入数据存储单元1209中。输入数据存储单元1209是存储输入给任务服务的数据的区域。执行指令接收单元1210从后端处理单元402接收任务执行指令以及参数。在接收到任务执行指令后，执行指令接收单元1210执行处理程序1211。在执行处理程序1211后，作为应答将任务结束通知发送给后端处理单元402。
处理程序1211是被设计为执行特定处理的处理程序。如果任务服务是PIPE型任务服务，则处理程序1211从输入数据存储单元1209获取数据，并将处理后的数据存储在输出数据存储单元1203中。
此外，处理程序1211将任务执行结果(结果状态，诸如“Success”或“Failure”)存储在执行结果存储单元1204中。结果获取请求接收单元1205从后端处理单元402接收结果获取请求。此外，结果获取请求接收单元1205读取存储在输出数据存储单元1203和执行结果存储单元1204中的信息。另外，结果获取请求接收单元1205将数据返回给后端处理单元402。在本示例性实施例中，PIPE型服务称为“处理任务服务”。
OUT型任务服务需要包括图12C所示的接口。在本示例性实施例中，假脱机服务412实现该接口。输入数据接收单元1208将根据来自后端处理单元402的输入数据存储请求而发送的数据，存储在输入数据存储单元1209中。输入数据存储单元1209是存储输入给任务服务的数据的区域。
执行指令接收单元1212从后端处理单元402接收任务执行指令及参数。在接收到任务执行指令后，执行指令接收单元1212执行处理程序1213。在执行处理程序1213后，作为应答将任务结束通知发送给后端处理单元402。
处理程序1213是被设计为执行特定处理的处理程序。如果任务服务是OUT型任务服务，则处理程序1213从输入数据存储单元1209获取数据，并且将处理后的数据存储在假脱机服务412内并进行管理。此外，处理程序1213将任务执行结果(结果状态，诸如“Success”或“Failure”)存储在执行结果存储单元1204中。
结果获取请求接收单元1214从后端处理单元402接收结果获取请求。此外，结果获取请求接收单元1214读取存储在执行结果存储单元1204中的信息。另外，结果获取请求接收单元1214将数据返回给后端处理单元402。在本示例性实施例中，OUT型任务服务被称为“发送任务服务”。
上述各任务服务的各种功能通过CPU 301从间接存储单元303加载程序并执行程序来实现。输出数据存储单元1203、执行结果存储单元1204和属性信息存储单元1207全部被实现作为在直接存储单元302或间接存储单元303上确保的区域。类似地，输入数据存储单元1209、输出数据存储单元1203、执行结果存储单元1204、属性信息存储单元1207和输入数据存储单元1209也被实现作为在直接存储单元302或间接存储单元303上确保的区域。“IN”、“PIPE”和“OUT”型的三种类型的接口具有由平台系统500的开发者公开的开放型规格。
开发了利用这三种类型接口的服务应用的人请求平台系统500的开发者将关于服务应用的信息登记到服务表800和序列表900。因此，本发明的示例性实施例能够向图像形成装置104的用户提供这样一种服务，其中图像形成装置104和服务应用经由平台系统500协作操作。
换句话说，通过生成实现“IN”、“PIPE”和“OUT”型接口的Web服务，使得平台系统500可用，并且Web服务能够被提供给图像形成装置104。结果，应用的服务开发者能够使处理程序1202、1211及1213与图像形成装置104及平台系统500协作操作，而不公开其内部结构(专门知识以及特征技术)。
以下将详细描述各类型的任务服务。IN型任务服务生成服务内的数据，或从诸如文档服务器103的外部服务器获取数据。换句话说，IN型任务服务是不需要来自平台系统500的输入信息的服务。PIPE型任务服务是基于对由平台系统500明确指定的输入数据进行处理、并且将处理结果输出到平台系统500的前提而提供的服务。OUT型任务服务是基于从平台系统500明确接收到输入数据、并且输入数据的处理结果要在服务内完成或者要被发送至外部服务器(即，数据的处理结果不被输出到平台系统500)的前提而提供的服务的类型。
按照如上所述调整这三种类型(“IN”、“PIPE”和“OUT”)的服务接口。由此能够获得以下效果。更具体地说，使得应用提供者容易地设计从IN型任务服务开始、然后继续到PIPE型任务服务并且在OUT型任务服务结束的序列，并且容易地从应用调用该序列。通过将任务服务分为三种类型，能够更容易地重新使用处理程序。
根据本示例性实施例的网络打印系统1000具有上述结构。在以下说明中，将描述根据本示例性实施例的网络打印系统1000内执行的处理的示例性流程。
图10是例示根据本示例性实施例的网络打印系统1000内执行的处理的示例性流程的序列图。
当用户经由图像形成装置104的设备浏览器409开始操作时，一系列处理开始。设备浏览器409与请求处理单元401上运行的打印应用通信以执行打印。换句话说，作为请求接收单元401的其他功能，请求接收单元401执行用于支持打印的各种功能。
图11例示了由设备浏览器409显示的打印画面的示例。图11所示的画面由在请求接收单元401上运行的打印应用生成。
参照图11，打印目的地字段1101显示唯一识别用户当前操作的图像形成装置104的设备ID。文档服务器字段1102显示获取数据的文档服务器的URL。在本示例性实施例中，登记到服务表800的属性字段806中的数据被显示在文档服务器字段1102中。
打印目标文档字段1103显示要实际打印的文档的ID。文档ID由用户输入。在图11所示的示例中，文档“folder/file.pdf”要被打印。文档存储在文档仓库406中。用户能够通过按压打印按钮1104输入用于执行预先定义的打印序列的指令。更具体地说，由服务序列表900(图9)的行关键字字段903定义的序列ID被分配给打印按钮1104。当用户按压打印按钮1104时，序列ID被发送。
例如，如果ID“seq01”已被分配作为序列ID，则执行对应于ID seq01的任务。当用户按压图11所示的打印按钮1104时，则在步骤S1001中，设备浏览器409将打印指令请求输入给请求接收单元401。当打印指令请求被输入时，经由打印目标文档字段1103输入的文档ID、显示在打印目的地字段1101中的设备ID以及分配给打印按钮1104的序列ID，作为参数被传送(作业接收处理)。
在接收到请求后，在步骤S1002中，请求处理单元401将序列获取请求输入给表存储服务403的服务序列表。序列获取请求包括作为参数的序列ID。在步骤S1003中，表存储服务403响应于输入的请求，将所请求的序列ID的序列数据发送给请求处理单元401。在本示例性实施例中，“序列数据”是指由服务序列表900定义的各种类型的任务中包含的信息。
在步骤S1004中，请求处理单元401将作业添加请求输入给由表存储服务403存储的作业表700。在输入作业添加请求时，请求接收单元401将作为参数的序列数据以及诸如文档ID的参数数据，发送给表存储服务403。
在步骤S1005中，表存储服务403基于从请求接收单元401接收到的参数，执行作业生成和添加处理。另外，表存储服务403将所生成作业的ID返回给请求接收单元401。所生成作业的ID由划分关键字字段702和行关键字字段703识别。
在步骤S1006中，请求接收单元401将消息添加请求发送给队列存储服务405。更具体地说，通过输入消息添加请求，请求接收单元401将在步骤S1005中获取到的作业ID作为参数进行发送。队列存储服务405执行消息添加处理。
在本示例性实施例中，在步骤S1006中要添加的消息是队列消息600。另外，作为参数发送的作业ID，更具体地说，是队列消息600中包含的部分<QueueMessage>603的值。
在步骤S1007中，响应于在步骤S1001中输入的请求，请求接收单元401经由设备浏览器409获取作业ID。通过执行上述处理，完成用户输入的打印指示操作。以下将描述由平台应用408执行的用于获取打印数据的处理。
在步骤S1007中获取作业ID后，处理进行到步骤S1050。在步骤S1050中，设备浏览器409将监视指令输入给平台应用408。在输入监视指令时，设备浏览器409将作业ID作为参数发送给平台应用408。在步骤S1051中，平台应用408请求请求接收单元401发送打印数据。在输入打印数据发送请求时，平台应用408将作业ID和设备ID作为参数发送给请求接收单元401。
在步骤S1052中，请求接收单元401将作业信息获取请求输入给表存储服务403。在步骤S1052中的作业信息获取请求处理中，请求接收单元401将在步骤S1051中已经接收到的作业ID发送给表存储服务403。
表存储服务403搜索对应于已被请求获取的作业ID的作业。另外，表存储服务403将搜索结果作为应答发送给请求接收单元401。
在接收到作业信息后，请求接收单元401通过参照指示作业的进行状态的状态字段706，确定作业的处理是否已经完成。
在本示例性实施例中，在步骤S1053中接收到应答时，作业job01的处理正在进行中。因此，在步骤S1054中，请求接收单元401将表示不存在打印数据的应答发送给平台应用408。
平台应用408重复用于请求发送打印数据的处理，直到获取到打印数据。在步骤S1055中，平台应用408执行用于发送打印数据的重复请求。步骤S1055中的打印数据请求处理、步骤S1056中的作业信息请求处理以及步骤S1057中的作业信息获取处理，分别对应于步骤S1051、S1052和S1053中的处理。
在本示例性实施例中，在步骤S1057中发送响应时，作业已经被完全处理。因此，在步骤S1058中，请求接收单元401将打印数据获取请求输入给假脱机服务412。在打印数据获取请求中，请求接收单元401将作业ID和设备ID作为参数发送给假脱机服务412。
假脱机服务412检查是否存在对应于所指定的作业ID和设备ID的数据。如果确定存在对应于所指定的作业ID和设备ID的任意数据，则处理进行到步骤S1059。在步骤S1059中，假脱机服务412将打印数据发送给请求接收单元401。
在从假脱机服务412接收到应答后，在步骤S1059A中，请求接收单元401将打印数据发送给平台应用408。平台应用408执行控制，以通过使用图像形成装置104的打印单元来打印输出打印数据。根据本示例性实施例的网络打印系统1000执行从用户输入打印请求到在图像形成装置104上输出打印物的上述处理流程。
在以下描述中，将详细描述平台系统500与各种Web服务之间的协作操作。在步骤S1010中，后端处理单元402周期性地将消息获取请求输入给队列存储服务405。在步骤S1011中从队列获取到消息之后，后端处理单元402从部分<MessageText>603中提取作业ID。
在步骤S1012中，后端处理单元402将作业和服务信息获取请求输入给表存储服务403。在接收到作业和服务信息获取请求之后，表存储服务403通过参照作业表700，获取关于对应于作业ID的作业的信息。
在步骤S1013中，表存储服务403从作业信息中获取对应于接下来要执行的任务的任务服务的ID。此外，表存储服务403基于所获取的任务服务的ID，从服务表800中获取对应于任务服务的ID的服务信息。另外，表存储服务403将作业和服务信息作为对步骤S1012中输入的请求的应答，返回给后端处理单元402。可以通过参照关于最后执行的任务的信息，来识别接下来要执行的任务。
在步骤S1014中，后端处理单元402基于所获取的作业和服务信息，输入任务执行指令。在执行任务时，后端处理单元402将由作业表700管理的参数作为变元(argument)来进行传送。在本示例性实施例中，后端处理单元402将任务执行指令输入给文档提取服务410的执行指令接收单元1201。
在接收到任务执行指令后，执行指令接收单元1201执行处理程序1202。在步骤S1015中，在通过使用处理程序1202执行任务时，将文档获取请求发送给文档仓库406。在发送文档获取请求时，文档提取服务410将文档ID作为参数传送给文档仓库406。文档仓库406的URL和文档ID是基于关于在步骤S1014中从后端处理单元402接收到的参数的信息。
在步骤S1015中文档仓库406已接收到文档获取请求之后，处理进行到步骤S1016。在步骤S1016中，文档仓库406将对应于所指定文档ID的文档数据，传送给文档提取服务410的处理程序1202。
处理程序1202将所接收到的文档数据存储在输出数据存储单元1203上。此外，处理程序1202将处理的执行结果(执行结果状态，诸如“Success”或“Failure”)存储在执行结果存储单元1204上。然后，处理程序1202结束。
当处理程序1202结束时，然后在步骤S1017中，执行指令接收单元1201将任务结束通知作为对步骤S1014中输入的指令的应答，返回给后端处理单元402。
在步骤S1018中，后端处理单元402将结果获取请求发送给文档提取服务410的结果获取请求接收单元1205。结果获取请求接收单元1205从输出数据存储单元1203读取文档数据，并且从执行结果存储单元1204读取结果状态。
在步骤S1019中，结果获取请求接收单元1205将所读取的文档数据和结果状态作为对步骤S1018中接收到的请求的应答，返回给后端处理单元402。在接收到应答后，在步骤S1020中，后端处理单元402执行文档存储处理，以将文档数据存储在Blob存储服务404中。
在步骤S1021中，后端处理单元402执行作业信息更新处理。更具体地说，后端处理单元402将任务执行结果应用于表存储服务403的作业表700。以上述方式，任务1被完全处理。
在任务的一系列处理已经完成后，后端处理单元402将消息添加给队列存储服务405以及从队列存储服务405中删除消息，以执行下一个任务(即任务2)。
更具体地说，首先，在步骤S1022(消息添加请求处理)中，后端处理单元402将对应于当前执行的作业的作业ID的消息添加到队列存储服务405。通过执行步骤S1022中的处理，用于对待处理的任务进行处理的请求已经完全被输入。在步骤S1023(消息删除请求处理)中，后端处理单元402从队列存储服务405中删除当前处理的消息。因此，从队列中删除指示执行所处理任务的消息。之后，将不再对可能由于超时而被暂停的相同处理执行再执行处理。
以下将参照图10详细描述由任务2执行的处理。步骤S1060至S1063的处理与步骤S1010至S1013的处理类似。
在步骤S1064中，后端处理单元402基于所获取的作业信息和服务信息，从Blob存储服务404中获取文档数据。更具体地说，在本示例性实施例中，后端处理单元402获取在步骤S1020中存储的文档。
在步骤S1065中，后端处理单元402将输入数据存储请求发送给文档转换服务411的输入数据接收单元1208。在发送输入数据存储请求时，后端处理单元402将在步骤S1064中获取到的文档数据作为变元进行传送。
通过接收输入数据存储请求，输入数据接收单元1208接收作为变元传送的文档数据。另外，输入数据接收单元1208将所接收的文档数据存储在输入数据存储单元1209中。
在步骤S 1066中，后端处理单元402将任务执行指令发送给文档转换服务411的执行指令接收单元1210。在发送任务执行指令时，后端处理单元402将由作业表700管理的参数作为变元发送给执行指令接收单元1210。
在接收到任务执行指令后，执行指令接收单元1210执行处理程序1211。当执行处理程序1211时，执行指令接收单元1210对存储在输入数据存储单元1209上的数据执行预定的数据转换，并将转换结果存储在输出数据存储单元1203上。
在本示例性实施例中，假定在步骤S1015中获取到的数据是通过使用诸如文字处理器的办公应用所生成的文档。因此，通过执行处理程序1211，将通过办公应用生成的文档转换成能够被图像形成装置104处理的PDF数据。
此外，处理程序1211将处理的执行结果(执行结果状态，诸如“Success”或“Failure”)存储在执行结果存储单元1204上。然后处理程序1211结束。
当处理程序1211结束时，然后在步骤S1067中，执行指令接收单元1201将任务结束通知作为对步骤S1066中输入的指令的应答，返回给后端处理单元402。在步骤S1068中，后端处理单元402将结果获取请求发送给文档转换服务411的结果获取请求接收单元1205。
在步骤S1069中，结果获取请求接收单元1205将所读取的文档数据和结果状态作为对步骤S1018中接收到的请求的应答，返回给后端处理单元402。
在接收到应答后，在步骤S1070中，后端处理单元402将文档数据存储在Blob存储服务404中。在步骤S1071中，在执行作业信息更新处理时，后端处理单元402将任务执行结果存储在表存储服务403的作业表700中。通过执行上述处理，任务2完全被处理。
在任务的一系列处理已经完成后，后端处理单元402将消息添加到队列存储服务405以及从队列存储服务405中删除消息，以执行下一个任务(即任务3)。更具体地说，首先，在步骤S1072中，后端处理单元402将对应于当前执行的作业的作业ID的消息添加到队列存储服务405。通过执行步骤S1072中的处理，用于对要处理的任务进行处理的请求已经完全被输入。在步骤S1073(消息删除请求处理)中，后端处理单元402从队列存储服务405中删除当前处理的消息。因此，从队列中删除指示执行处理任务的消息。之后，将不再对可能由于超时而被暂停的相同处理执行再执行处理。
继续描述任务执行序列。在上述处理之后，执行任务3的处理。步骤S1030至S1033的处理与步骤S1010至S1013的处理类似。
在步骤S1034中，后端处理单元402基于所获取的作业信息和服务信息，从Blob存储服务404中获取文档数据。更具体地说，在本示例性实施例中，后端处理单元402获取在步骤S1070中存储的文档。
在步骤S1041中，后端处理单元402将输入数据存储请求发送给假脱机服务412的输入数据接收单元1208。在发送输入数据存储请求时，后端处理单元402将在步骤S1034中获取到的文档数据作为变元进行传送。
通过接收输入数据存储请求，输入数据接收单元1208接收作为变元传送的文档数据。另外，输入数据接收单元1208将接收到的文档数据存储在输入数据存储单元1209中。
在步骤S1035中，后端处理单元402将任务执行指令发送给假脱机服务412的执行指令接收单元1212。在发送任务执行指令时，后端处理单元402将由作业表700管理的参数作为变元发送给执行指令接收单元1212。
在步骤S1035中发送的任务执行指令由假脱机服务412的执行指令接收单元1212接收。当接收到任务执行指令时，则执行处理程序1213。在执行处理程序1213后，处理程序1213从输入数据存储单元1209获取数据。另外，处理程序1213生成并分配在图像形成装置104上打印所指示的数据所需的属性(即诸如打印优先级的信息或色调信息)。
在本示例性实施例中，假脱机服务412的处理程序1213接收打印目的地装置的设备ID和作业ID作为参数，并将打印数据与参数值相关联地进行管理。此外，处理程序1213将处理执行结果(执行结果状态，诸如“Success”或“Failure”)存储在执行结果存储单元1204中。然后，处理程序1213结束。
在处理程序1213被完全执行后，在步骤S1036中，执行指令接收单元1212将任务结束通知作为对步骤S1035中输入的指令的应答，返回给后端处理单元402。在步骤S1037中，后端处理单元402将结果获取请求发送给假脱机服务412的结果获取请求接收单元1214。
结果获取请求接收单元1214读取存储在执行结果存储单元1204上的结果状态。在步骤S1038中，结果获取请求接收单元1214将结果状态作为对步骤S1037中接收到的请求的应答，返回给后端处理单元402。
在接收到应答后，在步骤S1039中，后端处理单元402通过执行作业信息更新处理，将任务执行结果存储在表存储服务403的作业表700中。通过执行上述处理，任务3被完全处理。
在本示例性实施例中，当添加打印数据时作业的处理结束。因此，在任务的一系列处理已经完成后，后端处理单元402从队列存储服务405中删除消息。更具体地说，当在步骤S1040中发送消息删除请求时，从队列存储服务405中删除当前处理的消息。因此，从队列中删除对应于所处理的任务的消息。然后作业结束。根据本示例性实施例的网络打印系统1000执行上述处理。
根据本示例性实施例，通过实现图12A至图12C所示的接口，能够获得以下效果。
具有上述结构的本示例性实施例能够提供这样一种服务，即通过利用诸如平台系统500的平台，与图像形成装置104协作，而不公开处理程序1202、1211和1213的专门知识和特征技术。
在本示例性实施例中，简单执行被登记到作业表700的服务。然而，由于基于开放型规格来生成服务应用，因此服务应用的质量可能不均一。如果由服务提供装置提供的服务不具有足够高的质量，则服务不仅无谓地消耗平台系统500的资源，而且使图像形成装置104的用户感到困扰。
这是由于可能多次失败的服务结果难以达到用户期望的结果。因此，针对可能不满足预定水平的质量的服务应用，以下解决方案可能是有用的。
因为如果执行上述服务，则上述服务有可能会失败，所以不执行具有不足以满足质量标准的质量的服务应用的任务，而暂停作业，以提高整个打印系统1000的质量。因此，对于用户来说执行期望服务也变得更为容易。因此，能够增加网络打印系统1000的可靠性。
在本发明的第二示例性实施例中，提供图13所示的服务质量统计表1300。基于服务质量统计表1300中存储的信息来确定是否执行任务。首先，将在下面详细描述根据本示例性实施例的服务质量统计表1300。
服务质量统计表1300管理关于服务的执行结果的统计信息。服务质量统计表1300由表存储服务506来存储。图13例示了服务质量统计表1300的示例。
参照图13，ETag字段1301类似于图7所示的ETag字段701。划分关键字字段1302和行关键字字段1303表示用于唯一识别表中各行的ID。在服务质量统计表1300中，划分关键字字段1302是能够唯一识别服务的开发者的开发者ID。行关键字字段1303被管理作为用于唯一识别任务服务的服务ID。
执行计数字段1304存储表示任务服务的执行次数的数值。错误计数字段1305存储表示在执行任务服务时发生了的错误数量的数值。
在本示例性实施例中，服务质量统计表1300管理预先编译的数据。然而，作为替代方案，可以在每次执行作业时存储执行结果，以及可以在所存储的信息变得必要时或者在所存储的信息即将变得必要之前对该信息进行编译。
在本示例性实施例中，能够在步骤S1021(图10)中更新作业信息时更新统计信息。更具体地说，后端处理单元402将任务执行指令作为要在步骤S1021中更新的作业信息的一部分，与该作业信息一起进行发送。同时，表存储服务403也更新服务质量统计表1300中包含的信息。然而，可以在与用于更新作业信息不同的另一时刻来更新统计信息。换句话说，可以在执行图10所示的步骤S1071或S1039时更新统计信息。
此外，在本示例性实施例中，如上所述，参照图7所示的作业表700来更新作业信息。对此解释为，未被成功处理的任务和作业的计数值增加。
以上未描述的网络打印系统1000的结构的其它部分与本发明的第一示例性实施例中上述描述的类似。
本示例性实施例执行图14的序列图中所示的以下处理。步骤S1001至S1012中的处理与图10中所示的处理类似。
在步骤S1012中，后端处理单元402将作业和服务信息获取请求发送给表存储服务403。更具体地说，后端处理单元402请求获取服务质量统计信息以及作业信息和任务服务信息。对此解释为，后端处理单元402从服务质量统计表1300中获取对应于任务服务的ID的统计信息(执行计数字段1304和错误计数字段1305)。
执行计数字段1304表示任务的执行次数。错误计数字段1305表示执行任务的失败次数。作业信息和任务服务信息如上所述。
在步骤S1401中，表存储服务403将作业信息、服务信息和服务质量统计信息作为对步骤S1012的应答，返回给后端处理单元402。
在获取到服务质量统计信息后，后端处理单元402确定所获取到的质量统计信息是否满足预定的基准值。
图15是由后端处理单元402执行的逻辑的流程图，所述逻辑用于基于服务质量统计信息来确定要调用的服务是否满足预定质量。
参照图15，在步骤S1500中，后端处理单元402检测服务的类型。此外，后端处理单元402确定要调用的服务是OUT型任务服务。
通过以下方式来检测服务类型。更具体地说，后端处理单元402向属性获取请求接收单元1206发送请求。属性获取请求接收单元1206从属性信息存储单元1207中读取服务类型并发送应答。
如果作为服务类型的确定结果，确定服务类型是INPUT服务或PIPE服务，则处理进行到步骤S1501。“预定的基准值”是指表示执行作业的失败次数相对于总次数的比率的失败率。
在步骤S1501中后端处理单元402计算失败率。更具体地说，后端处理单元402通过使用以下公式来计算失败率：
失败率＝错误计数(1305)/执行计数(1304)×100
在步骤S1502中，后端处理单元402确定失败率是否小于预定的基准值。在基准值(阈值)为20％的情况下，如果失败率小于20％，则在步骤S1503中认为满足条件。另一方面，如果在步骤S1502中确定失败率为20％或者更大，则在步骤S1504中认为不满足条件。
另一方面，在步骤S1500中，如果确定要调用的服务的类型是OUT型任务服务，则处理进行到步骤S1505。在步骤S1505中，后端处理单元402检测要调用的服务的开发者。为了检测服务开发者，后端处理单元402向属性获取请求接收单元1206输入请求，并且属性获取请求接收单元1206从属性信息存储单元1207中读取开发者ID并将所读取信息作为应答进行发送。
在步骤S1506中，后端处理单元402基于检测到的开发者ID来确定厂商的可靠性是否高。按照如下来执行步骤S1506中的确定。更具体地说，首先，后端处理单元402计算由开发者开发的所有服务的错误计数(1305)的总数(即错误总数)以及执行计数1304的总数(即总执行次数)。
然后，后端处理单元402通过使用以下公式来计算总失败率：
总失败率＝总失败次数/总执行次数×100
在步骤S1506中，后端处理单元402确定通过使用上述公式计算出的总失败率是否小于预定的基准值。另外，基于确定的结果，后端处理单元402确定厂商的可靠性是否高。
例如，当已经设置基准值为20％时，如果失败率小于20％，则在步骤S1506中后端处理单元402确定满足条件。另一方面，如果失败率为20％或更大，则后端处理单元402确定不满足条件。
如果确定不满足确定基准条件(步骤S1506中“否”)，则在步骤S1507中，后端处理单元402确定服务是否已被验证。如果确定服务已被验证(步骤S1507中“是”)，则处理进行到步骤S1508，在步骤S1508中，后端处理单元402确定达到了预定水平的质量。另一方面，如果确定服务尚未被验证(步骤S1507中“否”)，则处理进行到步骤S1509，在步骤S1509中，后端处理单元402确定未达到预定质量。
如果满足上述确定基准条件，则执行图10所示的序列图中的步骤S1014至S1019中的处理。另一方面，如果不满足确定基准条件，则执行图14所示的序列图中的步骤S1402中的作业信息更新处理。
更具体地说，通过在步骤S1402中更新作业信息并将作业表700中包含的状态字段706的值改变为“Failure”，后端处理单元402执行控制，以清楚地表示作业已经失败。换句话说，认为作业已经失败。
后端处理单元402根据在步骤S1403中接收到的消息删除请求，从队列存储服务405中删除由当前处理所处理的消息。通过执行上述处理，以后不对作业进行处理。执行上述处理，以避免不利地执行质量未达到预定水平的服务。
以下将参照图14描述由平台应用408执行的用于获取打印数据的处理。参照图14，图14所示的步骤S1050至S1053中的处理与图10所示的处理类似。
请求接收单元401通过参照在步骤S1053中获取到的状态字段706，能够确定处理已经失败。因此，在步骤S1404中，请求接收单元401将错误通知发送给平台应用408。当接收到错误通知时，平台应用408暂停处理。
根据本示例性实施例，能够暂停执行质量尚未达到预定质量的服务。因此，本示例性实施例能够有效地利用系统资源。
如图12A至图12C所示，本发明的上述示例性实施例的各个包含请求接收单元，该请求接收单元针对IN、PIPE和OUT型服务的各个具有唯一功能。然而，可以以统一方式使用多个请求接收单元。
更具体地说，在图16A所示的示例中，执行指令接收单元1201和结果获取请求接收单元1205的功能被组合成请求接收单元1601。在本示例中，作为在步骤S1014中从后端处理单元402发送的任务执行指令的结果，请求接收单元1601接收执行指令，执行对应于执行指令接收单元1201的处理，然后执行对应于结果获取请求接收单元1205的处理。
后端处理单元402接收与在步骤S1019中发送的应答等同的应答，作为对步骤S1014中发送的指令的应答。换句话说，在这种情况下，不执行等同于步骤S1017和S1018的处理。
在图16B所示的示例中，输入数据接收单元1208、执行指令接收单元1210和结果获取请求接收单元1205的功能被组合成请求接收单元1602。
在这种情况下，当后端处理单元402执行步骤S1065中的处理时，请求接收单元1602依次执行对应于输入数据接收单元1208、执行指令接收单元1210和结果获取请求接收单元1205的处理。
后端处理单元402接收与在步骤S1069中发送的应答等同的应答，作为对步骤S1065中发送的请求的应答。换句话说，在这种情况下，不执行等同于步骤S1066至S1068的处理。
类似地，在图16C所示的示例中，输入数据接收单元1208、执行指令接收单元1212和结果获取请求接收单元1214的功能被组合成请求接收单元1603。在这种情况下，当后端处理单元402执行步骤S1041中的处理时，请求接收单元1603依次执行对应于输入数据接收单元1208、执行指令接收单元1212和结果获取请求接收单元1214的处理。
后端处理单元402接收与步骤S1038中发送的应答等同的应答，作为对步骤S1041中发送的指令的应答。换句话说，在这种情况下，不执行等同于步骤S1035至S1037的处理。
如上所述，图12A至图12C所示的三种IN、PIPE或OUT请求接收单元被整合提供为图16A至图16C中所示的示例中的一个单元。然而，作为替代方案，这三种请求接收单元的功能能够被分割和整合提供给两个请求接收单元。
换句话说，如果满足以下要求，则能够采用上述替代结构。首先，要求数据能够从平台系统500被发送给Web服务。其次，平台系统500能够从Web服务获取数据。
如果实现根据本发明的各示例性实施例的接口，则平台系统500不能在满足这两个要求的同时直接访问Web服务。结果，允许服务应用的开发者使用平台系统500，而不公开其自身的专门知识及技术。
此外，由于除非使用实现接口的服务应用，否则不能利用平台系统500，因此平台系统500的厂商能够将平台系统500的质量维持在恒定高的水平。
在本发明的各示例性实施例中，在单个服务器计算机上运行一例(一个虚拟机)。然而，本发明并不限于此。更具体地说，如果服务器计算机包括多核CPU，则能够实现针对一个核包含一例的结构。如果服务器计算机遵照多线程(multi-threading)，则一个CPU能够实现至少一个虚拟机(当然也可以是两个、三个或更多个虚拟机)。
如上所述，根据各示例性实施例，用于实现一例的方法并不限于特定方法。换句话说，可以适当地改变根据各示例性实施例的用于实现一例的方法。
根据本发明的各示例性实施例，文档转换服务411将内容转换成PDF数据。然而，文档转换服务411可以将内容转换为任何其他适当的格式。更具体地说，文档转换服务411能够具有将内容转换成以下多种格式中的至少一种格式的功能，即诸如PostScript(PS)、打印机控制语言(PCL)和扩展标记语言(XML)文件规格(XPS)的页面描述语言(PDL)。
如上所述，文档转换服务411能够将内容转换成除上述格式以外的任何适当的数据格式。
此外，包含任务1、任务2和任务3的三个任务被用作根据本发明的各示例性实施例的任务。然而，任务的数量并不限于此。更具体地说，通过增加PIPE型任务的数量，可以增加任务的数量。
此外，如上所述，根据本发明的各示例性实施例的任务服务被划分为三种服务类型，因此这种结构对于实现本发明尤其有用。更具体地说，这是由于服务应用的开发者能够增加处理程序的多样性。换句话说，开发者在开发另一服务应用时能够再利用该处理程序。然而，如果本发明的目的并不在于该效果，则本发明不限于此。
换句话说，不需要采用在一个作业中包含一个IN或OUT任务的结构。对此解释为，在一个作业中可以包含多个IN或OUT任务。另外，在一个作业中可以只包含IN型任务。作为替代方案，在一个作业中可以包含IN型任务和OUT型任务二者。
此外，代替提供三种服务类型，可以只提供一种服务类型。在这种情况下，IN、PIPE和OUT型服务被整合成一种类型。作为替代方案，代替使用三种服务类型，即IN(输入)、PIPE(处理)以及OUT(输出)型，通过进一步划分服务类型，可以提供四种或更多种服务类型。
在各示例性实施例中，通过Web服务来提供服务，并且通过URI来管理由此提供的地址。然而，可以通过任何其它方法来提供服务。
更具体地说，代替Web服务，可以通过表象化状态转变(REST，Representational State Transfer)的接口来提供服务。作为替代方案，可以通过诸如动态链接库(DLL)的模块来提供服务。换句话说，如果文档提取服务410被提供作为DLL，则后端处理单元402能够执行该DLL。如果后端处理单元402执行该DLL，则后端处理单元402能够用作文档提取服务410。
如果后端处理单元402已经执行了IN型DLL，则文档仓库406获取文档文件。因此，在这种情况下，任务服务的开发者不需要构建用于提供任务服务的服务提供装置。
然而，在这种情况下，服务的开发者在必要时需要向平台系统500的厂商公开自身的专门知识和技术。诸如统一资源标识符(URI)的地址是平台系统500内的地址。
本发明的各方面还可以通过读出并执行记录在存储装置上的用于执行上述实施例的功能的程序的系统或设备的计算机(或诸如CPU或MPU的装置)、以及由系统或设备的计算机例如读出并执行记录在存储装置上的用于执行上述实施例的功能的程序来执行各步骤的方法来实现。鉴于此，例如经由网络或者从用作存储装置的各种类型的记录介质(例如计算机可读介质)向计算机提供程序。
虽然参照示例性实施例对本发明进行了说明，但是应当理解，本发明不限于所公开的示例性实施例。应当对所附权利要求的范围给予最宽的解释，以使其涵盖所有这种变型、等同结构及功能。