CN1770776A - 传送设备及其控制方法、分布式处理系统、程序和记录介质 - Google Patents
传送设备及其控制方法、分布式处理系统、程序和记录介质 Download PDFInfo
- Publication number
- CN1770776A CN1770776A CN200510119981.2A CN200510119981A CN1770776A CN 1770776 A CN1770776 A CN 1770776A CN 200510119981 A CN200510119981 A CN 200510119981A CN 1770776 A CN1770776 A CN 1770776A
- Authority
- CN
- China
- Prior art keywords
- communication equipment
- server
- response
- operation requests
- equipment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
在经由网络协调第一通信设备和第二通信设备间的通信的传送设备中,第一接收单元集中地从第一通信设备接收操作响应,该操作响应相对于第二通信设备的操作请求而相应地创建。第一发送单元集中地将由第一接收单元接收的操作响应发送给作为每个操作响应目的地的第二通信设备。第二接收单元集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求。第二发送单元将由第二接收单元接收的操作请求集中地发送到第一通信设备,该第一通信设备作为操作请求的各自的目的地。
Description
技术领域
本发明涉及协调第一通信设备和第二通信设备之间的通信的传送设备,具有传送设备、第一通信设备和第二通信设备的分布式处理系统,控制该传送设备来协调(mediate)该第一通信设备和第二通信设备之间的通信的传送设备控制方法,和用于使计算机执行该传送设备控制方法的计算机程序产品。
背景技术
常规的,在通信设备通过网络连接的通信系统中,该通信设备相互交换信息,以便将来自通信设备的通知或要求发送给另一个通信设备。而且在该系统中,第一通信设备向第二通信设备发送命令,而作为使该第二通信设备执行特定操作的操作请求,并且该第二通信设备向第一通信设备返回作为操作响应的操作执行结果。
例如,日本公开专利申请号2001-273211公开了该技术,并且教导远程处理器向本地处理器发送消息,该消息给出由本地处理器执行的命令,并且由本地处理器接收表示命令结果的响应。
在日本公开专利申请号2001-273211的系统中,将远程处理器设置在防火墙的外部,并且将本地处理器设置在防火墙的内部。而且还公开了,当需要时,本地处理器向防火墙外部的远程处理器发送操作请求,并且该远程处理器向该本地处理器发送命令作为操作请求的响应。该技术能使命令从防火墙的外部传送到防火墙的内部。
有关上述操作请求的技术也可应用于远程管理系统,该系统实施设备的管理操作的远程控制,该设备连接该通信设备。
日本公开专利申请号2002-135858公开了该技术应用到远程管理系统的范例。在该系统中,将来自远程控制设备的命令发送给被远程控制的设备,该远程控制设备具有从用户接收操作请求的功能,被远程控制的设备具有执行盲操作和清晰操作的功能,从而被远程控制的设备根据该命令执行盲或清晰的操作。
然而,在日本公开专利申请号2002-135858中没有教导从受远程控制的设备向远程控制设备发送有关命令的响应。
顺便提及,当在多个通信设备之间交换消息时,存在可能的情况,其中通信设备向两个或多个其它通信设备发送命令。并且在该情况下,要求接收该命令的每个通信设备分别向命令发送源通信设备返回该命令的执行结果。
传统地,当执行该操作时,所述源通信设备单独的与作为命令的目的地通信设备通信,并且向每个目标通信设备发送命令。而且,当接收命令响应时,源通信设备单独地与对其发送命令的目的地通信设备通信,并且从每个目的地通信设备接收命令响应。
然而,根据上述的传统系统,每次发送命令或接收命令响应,必须分别在源通信设备和单独用于每个命令终点的目的地通信设置之间建立连接。因此,通信开销变大,并且存在通信效率的问题。
在当前环境下,仍然保持着通过建立拨号连接执行经由网络的通信的环境,并且在该环境下仍然未解决上述问题。在该环境下,每次建立连接时要对通信费用进行收费,并且存在花几十秒的时间建立连接的情况。还存在一个问题,即由于建立连接的次数增加,通信成本显著增加。
发明内容
本发明的一般目的是提供一种消除上述问题的传送设备。
本发明更具体的目的是提供一种传送设备,当特定通信设备向其他通信设备发送操作请求,并且从其他通信设备接收相对于该操作请求的一个或多个操作响应时,该传送设备有效地在分布式处理系统中执行通信设备之间的通信。
为了实现上述目的,本发明提供一种传送设备,其通过网络在第一通信设备和第二通信设备之间协调通信,该传送设备包括:第一接收单元,集中接收来自该第一通信设备的操作响应,相对于该第二通信设备的操作请求产生操作响应,并且将操作响应发送给第二通信设备;第一发送单元,向该第二通信设备集中发送由该第一接收单元接收的操作响应,该第二通信设备作为每个操作响应的目的地;第二接收单元,从该第二通信设备集中接收由该第二通信设备发送给该第一通信设备的操作请求;和第二发送单元,向该第一通信设备集中发送由该第二接收单元接收的操作请求,该第一通信设备作为第二通信设备的操作请求的各自的目的地。
为了实现上述目的,本发明提供一种分布式处理系统,其具有相互连接的服务器和传送设备,该传送设备通过网络在服务器和终端单元之间协调通信,该传送设备包括第一接收单元,集中接收来自该终端单元的操作响应,相对于该服务器的操作请求产生操作响应并且发送给服务器;第一发送单元,向该服务器集中发送由该第一接收单元接收的操作响应,该服务器作为每个操作响应的终点;第二接收单元,从该服务器集中接收由该服务器发送给该终端单元的操作请求;和第二发送单元,向该终端单元集中发送由该第二接收单元接收的操作请求,该终端作为服务器的操作请求的相应终点,并且该服务器包括:发送单元,向该传送设备集中发送要发送给终端单元的操作请求;和接收单元,从该传送设备集中接收该终端单元的操作响应,相对于该服务器的操作请求产生该操作响应并且发送给该终端单元。
为了实现上述目的,本发明提供一种控制传送设备的传送设备控制方法,该传送设备通过网络在第一通信设备和第二通信设备之间协调通信,该方法包括:集中接收来自该第一通信设备的操作响应,相对于该第二通信设备的操作请求产生操作响应,并且将操作响应发送给第二通信设备;向该第二通信设备集中发送接操作响应,该第二通信设备作为每个操作响应的终点;从该第二通信设备集中接收由该第二通信设备发送给该第一通信设备的操作请求;并且向该第一通信设备集中发送接收的操作请求,该第一通信设备作为第二通信设备的操作请求的相应终点。
为了实现上述目的,本发明提供一种用于使计算机执行控制该该传送设备的传送设备控制方法的计算机程序产品,该传送设备通过网络在第一通信设备和第二通信设备之间协调通信,该方法包括:集中接收来自该第一通信设备的操作响应,相对于该第二通信设备的操作请求产生操作响应,并且将操作响应发送给第二通信设备;向该第二通信设备集中发送操作响应,该第二通信设备作为每个操作响应的终点;从该第二通信设备集中接收由该第二通信设备发送给该第一通信设备的操作请求;并且向该第一通信设备集中发送接收的操作请求,该第一通信设备作为第二通信设备的操作请求的相应终点。
根据本发明的该传送设备、该分布式处理系统和该传送设备控制方法,当在分布式处理系统中的某个通信设备向两个或多个通信设备发送操作请求,并且接收对于该操作请求的操作响应时,通过在该通信设备之间适当的协调通信能提高通信效率。根据本发明的计算机程序或计算机可读记录介质,使计算根据上述传送设备控制方法来控制该传送设备,并且可获得相同的有利效果。
附图说明
通过下面结合附图的详细描述,本发明的其他目的、特征和优点将显而易见。
图1是显示使用作为本发明的传送设备的传送服务器的分布式处理系统实施例的组成框图。
图2A、图2B、图2C和图2D是用于解释图1的分布式处理器系统中操作请求和操作响应之间的关系的图。
图3是显示作为远程管理系统范例的图1的分布式处理系统的另一个实施例的组成的框图。
图4A、图41B、图4C和图4D是用于解释图3的远程管理系统中操作请求和操作响应之间的关系的图。
图5是用于解释图3的远程管理系统中图像处理设备和传送服务器之间的通信顺序的范例图表。
图6是用于解释图3的远程管理系统中传送服务器和服务器之间的通信顺序的范例图表。
图7是用于解释图5所示的通信顺序的另一个范例的图。
图8是显示图3所示的传送服务器的硬件组成的框图。
图9是显示图3所示的该图像处理设备的硬件组成的框图。
图10是图3所示的服务器的硬件组成的框图。
图11是显示图3的传送服务器的功能中用于执行命令和命令响应有关过程的功能组成的框图。
图12是显示图3的传送服务器中的终端命令表单的数据结构范例图。
图13是显示图3的传送服务器中的传送服务器命令表单的数据结构范例图。
图14是显示传送消息库(pool)中的传送消息表单的数据结构范例图,该传送消息库用于图3的传送服务器中的发送。
图15是显示传送消息库中的传送消息表单的数据结构范例图,该传送消息库用于图3的传送服务器中的接收。
图16是显示HTTP请求的范例图,该HTTP请求由图3的传送服务器从该图像处理设备中接收。
图17是显示HTTP响应的范例图,该HTTP响应由图3的该传送服务器发送给该图像处理设备。
图18是显示HTTP请求的范例图,该HTTP请求由图3的传送服务器发送给该服务器。
图19是显示HTTP响应的范例图,该HTTP响应由图3的传送服务器从该服务器接收。
图20是显示描述发送给图3的远程管理系统中的传送服务器的终端命令的部分的范例图。
图21是显示描述了对于图20所示的终端命令的响应的部分的范例图。
图22是显示当发送给服务器(销售管理服务器)的终端命令从该图像处理设备传送给该传送服务器时的部分的范例图。
图23是显示当图22中所示的终端命令从该传送服务器传送给该服务器时的部分的范例图。
图24是显示当图22中所示的终端命令的响应从该服务器传送给该传送服务器时的部分的范例图。
图25是显示当图24中所示的命令响应从该服务器传送给图像处理设备时的部分的范例图。
图26是显示部分范例的图,该部分描述了发送给该图像处理设备的传送服务器命令。
图27是显示部分范例的图,该部分描述了对图26中所示的传送服务器命令的响应。
图28是显示当发送给该图像处理设备的服务器命令从服务器传送给传送服务器时的部分的范例图。
图29是显示当图28中所示的服务器命令从该传送服务器传送给该图像处理设备时的部分的范例图。
图30是显示当图28中所示的服务器命令的响应从图像处理设备传送给该传送服务器时的部分的范例图。
图31是显示当图30中所示的命令响应从该传送服务器传送给该服务器(销售管理服务器)时的部分的范例的图表。
图32是用于解释由图3的传送服务器执行的与图像处理设备和传送服务器之间的通信有关的消息收集和分布式处理的基本流程的流程图。
图33是用于解释图32所示的消息分布式处理的流程图。
图34是显示在图3的传送服务器中存储的目的地表的范例图表。
图35是用于解释图32的基本流程中步骤S14的传送消息收集过程的流程图。
图36是用于解释图32的基本流程中步骤S15和后续步骤的过程的流程图。
图37是用于解释与由图3的传送服务器执行的终端命令的执行有关的过程范例的流程图。
图38是用于解释与由图3的传送服务器执行的终端命令的执行有关的另一个过程范例的流程图。
图39是用于解释与由图3的传送服务器执行的服务器和传送服务器之间的消息传送有关的过程的流程图。
图40是用于解释与图39的消息传送过程的执行定时控制有关的过程的流程图。
图41是用于解释与由图3的传送服务器执行的终端命令的传送有关的过程的另一个范例的流程图。
图42是显示用于执行命令和命令响应的功能组成的框图,该命令和命令响应与图3的图像处理设备的功能中的过程有关。
图43是显示图3的图像处理设备中的终端命令表单的数据结构范例图。
图44是显示图3的图像处理设备中的服务器侧命令表的数据结构范例图。
图45是用于解释由图3的图像处理设备执行的消息收集和分布式处理的基本流程的流程图。
图46是用于解释图45的基本流程中直到步骤S114的过程的流程图。
图47是用于解释图45的基本流程中步骤S115和后续步骤的过程的流程图。
图48是显示用于执行与图3的服务器的功能中的过程有关的命令和命令响应的功能组成的框图。
图49是显示图3的服务器中存储的路径信息表的范例图。
图50是用于解释由图3的服务器执行的消息收集和分布式处理的基本流程的流程图。
图51是用于解释图50的基本流程中直到步骤S215的过程的流程图。
图52是用于解释图50的基本流程中的步骤S216和后续步骤的过程的流程图。
图53是用于解释图50的基本流程中的路径信息表更新过程的流程图。
图54是用于解释当图像处理设备产生由该服务器执行的终端命令并且接收对于该终端命令的命令响应时,由图3的远程管理系统的相应部件执行的过程的流程图。
图55是用于解释当该服务器产生发送给该图像处理设备的服务器命令并且接收对于该服务器命令的命令响应时,由图3的远程管理系统的相应元件执行的过程的流程图。
图56是显示本发明的分布式处理系统的另一个实施例的组成图。
图57是显示本发明的分布式处理系统的另一个实施例的组成图。
图58是显示图57所示的服务器J中的路径信息表的范例图。
图59是显示图34的目的地表的另一个范例的图。
图60是显示当使用图59的目的地表时分布式处理系统的组成框图。
图61是显示该目的地表的另一个范例图。
图62是显示当使用图61的目的地表时,该分布式处理系统的组成图。
图63是显示当如图62所示构造分布式处理系统时,代替该目的地表而使用的数据的范例图。
图64是当使用图63的数据时用于解释执行的消息分布式处理的流程图,其对应图33的流程图。
图65是显示本发明的分布式处理系统的另一个实施例的组成图。
具体实施方式
现在将参考附图对本发明的优选实施例进行描述。
作为传送服务器的分布式处理系统的一个实施例构成本发明的传送设备,并且将解释利用该传送服务器构成分布式处理系统。
图1是显示利用作为本发明的传送设备的传送服务器的分布式处理系统的组成框图。如图1所示,该分布式处理系统包括作为第一通信设备的终端单元10,作为第二通信设备的服务器13,并且该传送服务器12通过网络14在这些通信设备之间协调通信。在图1中,示意了终端单元10和10’以及服务器13a和13b。为了下面对本发明的解释,认为终端单元10和服务器13为这些设备的典型范例,除非另外指定。
终端单元10设置在用户环境(用户侧)下,并且配置使其能通过因特网14与传送服务器12通信。当由终端10使用服务器13提供的功能时,终端单元10只向传送服务器12发送请求,并且该传送服务器12将来自终端单元10的请求发送给合适的服务器13。如此,该分布式处理系统允许终端10使用由服务器13提供的功能。
为了易于理解该分布式处理系统,使用术语“传送服务器”和“服务器”,但是不需要将这些设备限制为实现如网络中的“服务器”的功能。
终端单元10可以是具有通信能力的公知的PC(个人计算机)或者是可应用于各种电子设备之一的具有通信能力的通信设备。例如,终端单元10可以是任何图像处理设备,包括打印机、传真设备、数字复印机、扫描仪和多功能外围设备,或者安装在气体测量系统、供水或供电、联网的家用器具、自动售货机、医疗设备、电源设备、空调系统、汽车、飞机等中的具有通信能力的通信设备。
如图1所示,可以在用户环境中设置多个终端(10和10’),并且在用户环境中可以共存不同种类的终端单元。
在该实施例中,在每个用户环境中的终端单元10连接在一起以形成LAN(局域网),并且考虑到它们的安全性,该LAN通过防火墙11连接因特网14。
通常建立防火墙11来拦截从用户环境外部发送的通信请求,并且传送服务器12只通过发送如HTTP(超文本传送协议)请求的通信请求不能向防火墙11内部的终端单元10发送信息。因此,为了在传送服务器12和终端单元10之间交换信息,有必要采用专用协议。
可以设置服务器13构成各种分层结构,尽管在该实施例中只有两个服务器13连接传送服务器12。有可能在分布式处理系统的使用期间改变该布局。
由于甚至在该实施例中由传送服务器12管理命令的目标,能通过改变被管理的目标的数据而容易的响应该系统结构的变化。
在该实施例中,显示了不同于因特网14的在服务器13和传送服务器12之间的连接线。然而,有可能重新排列该设备,以便该设备能通过因特网14相互通信。
在上述的分布式处理系统中,在服务器13中安装应用程序,以便该服务器13根据来自终端单元10的操作请求执行操作,或者将操作请求发送给终端单元10。
在该传送服务器12中安装应用程序,以便该传送服务器12协调在终端单元10和服务器13之间的操作请求以及对于该操作请求的操作响应的发送和接收。
而且,用于实现如服务器功能的应用程序安装在传送服务器12中。配置包括终端单元10的分布式处理系统的每个节点,以便可以发送请求处理安装的应用程序的方法的操作请求,并且根据RPC(远程过程调用)在每个节点获得作为请求处理的结果的操作响应。
在该说明书中,定义该方法为逻辑功能,其中指定输入和输出格式。该操作请求充当调用该功能的功能调用(过程调用),并且操作响应充当由功能调用所调用的功能的执行结果。还存在一种情况,其中响应该操作请求的内容包括具有无意义执行结果的通知。
图2A至图2D显示操作请求和操作响应之间的关系。在这些图中不考虑防火墙11。
图2A显示了由终端单元10生成向服务器13发送操作请求的情况。
在该情况中,终端单元10产生终端侧操作请求,并且服务器13通过传送服务器12接收该请求,并且返回对于该操作请求的操作响应。此时,终端单元10侧没有必要掌握操作请求最终发送给哪个服务器13,所执行的仅仅是将操作请求发送给传送服务器12。该传送服务器12向合适的服务器13发送操作请求,接收来自服务器13的操作响应,并且将其返回给终端单元10。还存在一种情况,其中由两个或多个传送服务器12一个接一个的协调终端侧操作请求a,并且到达服务器13。
在图2A中,存在一种情况,其中不仅响应而且该延迟通知a’发送给终端单元10。当服务器13接收来自传送服务器12的终端侧操作请求a并且确定在与传送服务器12连接期间不能返回对操作请求的响应时,服务器13发送延迟通知a’。在报告响应被延迟后,连接状态暂时终止,并且在下个连接情况下,服务器13重新传送对该操作请求的响应。
图2B显示了由该终端单元10产生发送给传送服务器12的操作请求。
在该情况下,终端单元10产生终端侧操作请求b,并且传送服务器12将其接收并返回对于该操作请求的操作响应b。
然而,在该情况下,终端单元10侧没有必要采取与图2A的情况不同的动作。如果像图2A那样,将操作请求发送给传送服务器12,应当由自己执行的操作请求被该传送服务器12侧区别。当识别应当由自己执行时,执行替换为传送给服务器13的操作,并且涉及操作请求。
与图2A的情况类似,在图2B的情况,当不能立刻返回响应时,返回该延迟通知b’。
图2C显示了服务器13产生发送给终端单元10的操作请求c的情况。
在该情况中,服务器13产生服务器侧操作请求c,并且终端10通过传送服务器12接收,并且返回对该操作请求的操作响应。
图2D显示了传送服务器12产生发送给终端单元10的操作请求的情况。
在该情况中,传送服务器12产生传送服务器侧操作请求d,并且该终端单元10接收其,并且返回对该操作请求的操作响应。
而且在图2C和图2D的情况中,终端单元没有必要识别操作响应返回给哪个服务器,并且如果所有的操作响应发送给传送服务器12,该传送服务器12侧将它们发送给合适的服务器(包括传送服务器12自己)。
而且在图2C和2D的情况中,发送延迟通知与图2A和图2B的情况相同。
根据本发明,SOAP(简单目标访问协议)用作变元表和根据RPC(远程过程调用)的返回值的传送协议,并且上述操作请求和上述操作响应描述为SOAP消息。
在该实施例中,当发送或接收在通信设备(终端单元10)和两个或多个通信对方(服务器13)之间的操作请求和对于该操作请求的操作响应时,提供传送服务器12作为协调发送和接收的传送设备。并且根据从终端单元10接收的操作请求的分类、由该传送服务器12将操作请求发送给作为目的地节点的服务器13,并且服务器13将操作响应返回给作为该操作请求的源节点的终端单元10。
可以配置上述实施例使得只从上述通信设备发送操作请求,并且上述通信对方只向上述通信设备发送对于该操作请求的操作响应。
作为实际发送操作请求和操作响应的通信协议,根据该系统的结构可以使用合适的协议,并且,例如可以使用HTTP(超文本传送协议)、SMTP(简单邮件传送协议)或FTP(文件传送协议)。
将参考图3解释采用HTTP的范例。在该实施例中的图像处理设备100是图1的分布式处理系统的实施例中的第一通信设备。
将解释远程管理系统,其中使用由作为第二通信设备的销售管理服务器103a或信息传送服务器103b提供的业务,并且设备管理服务器102是本发明的传送设备,其在这些设备之间协调通信。
在该系统中,该图像处理设备100也使用由该设备管理服务器102提供的业务。图3是显示分布式处理系统的组成范例的概念框图,并且图3的构成与图1相同,除了该终端单元10更换为图像处理设备100以及该服务器12和13更换为服务器102和103。将省略对图3整个系统的解释。
在该实施例中,只有一个图像处理设备100显示在图1中作为终端单元,但在该系统中有可能包括两个或多个终端单元。
在下面的解释中,为了简化解释,将终端单元解释为只是一个图像处理设备100,但是涉及一些处理和数据,还显示了具有两个或多个终端单元的范例,而不特别指定,以便能容易的扩展并且也可以应用于设置两个或多个终端单元的情况。甚至在该情况下,如果假设多个终端单元中的一个为图像处理设备100,也可令人满意地应用于图3所示的系统中。
顺便提及,图像处理设备100是具有多个功能的数字多功能外围设备,包括复印机、传真机和扫描仪,以及与外部设备通信,并且结合用于提供有关这些功能的业务的应用程序。
设备管理服务器102除了具有作为传送服务器的功能之外还具有提供有关远程管理的业务和图像处理设备100的维护的功能,该传送服务器在服务器和图像处理设备100之间协调通信。
销售管理服务器103a具有提供有关订购接收的业务和消费物品的销售以及图像处理设备100中的供给的功能。
信息传送服务器103b具有提供将包括新闻、指南或产品介绍等的各种信息分配给图像处理设备100的用户的业务的功能。
每个节点通过RPC(远程过程调用)可以发送请求处理共有应用程序的方法的操作请求给装置(mount),并且能立刻获得作为该请求处理的结果的操作响应。
在下面的解释中,除了给予有关业务内容的解释之外,该设备管理服务器102称作传送服务器102,并且销售管理服务器103a和信息传送服务器103b共同称作服务器103。
图4A至图4D显示了操作请求和操作响应之间的关系。在图4A至4D中,没有考虑防火墙11。
图4A显示了由图像处理设备100产生发送给服务器103的操作请求情况。
在该情况下,图像处理设备100产生图像处理设备侧操作请求a(终端命令),并且服务器103通过传送服务器102接收该请求,并且返回对于该命令的操作响应(命令响应)。
存在一种情况,其中由两个或多个传送服务器102一个接一个地协调该图像处理设备侧操作请求a,并且到达服务器103。
图4B显示了图像处理设备100产生发送给传送服务器102的操作请求的情况。
例如,在该情况下,图像处理设备100产生图像处理设备侧操作请求b,并且传送服务器102接收该请求并且返回对于该命令的操作响应b。
在这点上,图4A和图4B的情况与图2A和2B的情况相同,图像处理设备100侧没有必要掌握该操作请求最终发送给哪个节点。
图4C显示了服务器103产生发送给图像处理设备100的操作请求的情况。
在该情况下,服务器103产生服务器侧操作请求c(服务器命令),并且图像处理设备100通过传送服务102接收该请求,并且返回对于该操作请求的操作响应。
图4D显示了由传送服务器102产生发送给图像处理设备100的操作请求的情况。
在该情况中,传送服务器102产生传送服务器侧操作请求(也称作“传送服务器命令”)d,并且该图像处理设备100接收该请求,并且返回对于该命令的操作响应。
在这点上,图4C和图4D的情况与图2C和2D的情况相同,图像处理设备100侧没有必要掌握图像处理设备100侧将操作响应最终发送给哪个节点。
这与图2A的情况相同,当没有立刻返回响应时,发送与所有图4A-图4D有关的答复延迟通知。因此,在图像处理设备100和服务器103之间的RPC级别上,以及在图像处理设备100和传送服务器102之间的RPC级别上对称的处理操作请求和操作响应。然而,在通信级别上,这是不对称的。
下面,将解释在该分布式处理系统中的通信顺序。
图5显示了在图像处理设备和传送服务器之间的通信顺序的范例。
如图5所示,通过相互发送和接收作为通信请求的HTTP请求,以及作为对该通信请求的通信响应的HTTP响应,图像处理设备100和传送服务器102通信。
然而,在图像处理设备100和传送服务器102之间提供防火墙11,并且,如图5所示,从图像处理设备100向传送服务器102发送作为通信请求的HTTP请求,并且该请求由传送服务器102通过向图像处理设备100返回作为对该通信清求的通信响应的HTTP响应的过程一直执行。
例如,传送服务器102返回对于由图像处理设备100发送的HTTP请求X的HTTP响应X,并且同样返回对于HTTP请求Y的HTTP响应Y。
在由图像处理设备100发送的HTTP请求中,所述的内容是终端命令,该命令是图像处理设备100对传送服务器102或服务器103的操作请求,由服务器103通过传送服务器102发送给图像处理设备100的服务器命令的响应(命令响应),和由传送服务器102发送给图像处理设备100的传送服务器命令的响应。
图像处理设备100侧只掌握由图像处理设备100将有关的终端命令发送给传送服务器102或服务器103,这是必要的。
在由传送服务器102发送的HTTP响应中,所描述的内容是服务器命令,该命令是服务器103对图像处理设备100的操作请求,对传送服务器命令的响应,该命令是传送服务器102对图像处理设备100的操作请求,和从图像处理设备100到传送服务器102或服务器103的终端命令。
应当注意,该响应指示哪个终端命令被寻址,并且有必要使其具体指定是否是它来自与该响应有关的传送服务器102或服务器103中的哪个的响应。
当发送延迟通知时,延迟通知可表示为代替上述响应。
作为在该范例中的表示,对于HTTP请求X可以指示和发送终端命令A和B,并且对于该HTTP请求X和对应的HTTP响应X,可以指示和发送该响应或延迟通知。
然而,该服务器命令C和传送服务器命令D将表示为答复HTTP请求X和相应HTTP响应X,并且将发送给它们,以及对于跟随HTTP请求的HTTP请求Y,将指示和发送响应或延迟通知。
在上述图4A或图4B的情况中,图像处理设备100在产生终端命令之后,可以立刻建立与传送服务器102的连接,并且它能将包含这些的内容传递给HTTP请求。
然而,在图4C或图4D的情况中,为了安装在图像处理设备100侧中的防火墙11可以从传送服务器102中截取该HTTP请求,不能立刻从传送服务器102侧访问图像处理设备100,并且不能转移服务器命令。
下面,图6显示了在传送服务器和服务器之间的通信顺序的范例。
在传送服务器102和服务器103之间的防火墙是不必要的。然而,为了丢掉负荷,如图6所示,该负载管理应当与服务器103侧通信的对方,或者管理应当需要通信的定时,该通信发送HTTP请求给服务器103作为来自传送服务器102的通信请求,并且一直执行该过程,即由服务器103向传送服务器102返回对于该通信请求的HTTP响应作为通信响应。
例如,该情况,即,服务器103返回对于传送服务器102发送的HTTP请求Z的HTTP响应Z,并且同样返回对于HTTP请求W的HTTP响应W。
并且,在从图像处理设备100中接收对于HTTP请求的响应中,该响应是对从图像处理设备100中接收的发送给终端单元和图像设备100的服务器命令的响应,它表示确定应当发送给服务器103,并且试图发送。
它表示对服务器命令进行响应,该服务器命令是从服务器103寻址图像处理设备100的操作请求,并且发送到服务器103的终端命令用于HTTP响应,并且试图将其发送。
当发送延迟通知时,其可以代替上述的响应表示延迟通知。终端命令、传送服务器命令、服务器命令和响应以及对这些的延迟通知可分别表示全部(0是足够的)HTPP请求中一个任意的HTTP请求,或HTTP响应。逻辑上将一个HTTP请求或HTTP响应表示的内容插入到数据块中并且发送。
通过集中发送目的地和源节点的不同的操作请求和不同的操作响应,可以减小为了发送需求信息所需的连接次数,可以减小开销,并且可获得通信效率的增加。
图7显示了在图像处理设备和传送服务器之间的其他通信顺序的范例。
尽管为了解释,图5和图6所示的顺序的范例非常简单,在图7中显示的范例是不变的。当延迟通知发送给命令时,在下个发送器会话时不需要返回响应。
例如,它表示为HTTP响应X’的下个HTTP响应Y’,该HTTP请求X’描述如图7所示的终端命令B的延迟通知,并且可返回HTTP响应,进一步在不返回之后并且示意该响应。
当然,传送服务器命令或服务器命令与此相同,并且没有必要表示对HTTP请求的下个HTTP请求的响应命令。并且有必要表示更靠后的HTTP请求,并且只是发送。
顺便提及,分别单独的产生每个命令和每个命令响应。由于应当存在处理,为了执行上述图像处理设备100和传送服务器102之间,以及传送服务器102和服务器103之间的批传送,在传送之前,该处理组合这些命令和命令响应,并且在需要传送之后将其分开是必需的。
下面,将解释通过每个设备的硬件结构和处理程序来执行该处理的功能组成。
为了简化解释,在下面的解释中,省略了对与延迟有关的处理的陈述。图8显示了本发明的传送服务器的硬件组成。图8是显示传送服务器102的组成的框图。
该传送服务器102包括调制解调器121、通信终端122、外部连接接口123、操作员终端124、控制单元125、和文件服务器126。
调制解调器121经由公众电路通过设备用户侧(例如,使用图像处理设备的用户点)与图像处理设备100通信,并且执行发送和接收数据的不同恢复。
通信终端122通过调制解调器121控制通信。并且通过这些调制解调器121和通信终端122获得作为通信单元的功能。
外部连接I/F123是一个接口,其经因特网14或公用载波租用线路通过网络执行通信。并且执行设备用户侧的图像处理设备100与服务器103通信。可以提供用于安全管理等的代理服务器。
通过操作员,操作员终端124在输入单元,如键盘接收各种操作数据的输入。当与每个客户环境的图像处理设备100通信时,存在使用的用户数据,例如,他们的IP地址、电话号码(呼叫起点电话号码)等。
控制单元125具有微型计算机,其包括未示意的CPU、ROM、RAM等。该CPU通常根据程序控制该传送服务器102,并且如果需要,通过使用相应的元件可以执行各种处理。
文件服务器126具有存储器,如未示意的硬盘驱动器单元。每个客户环境的图像处理设备100的该IP地址和电话号码、数据、用于维护的图像处理设备的标识、各种数据,如关于从操作员终端124输入的数据的程序,其中存储每个命令和命令响应的目的地的目的地表,分别作为数据库(DB)。
控制设备的组成不限于该实施例。例如,也可以通过使用个人计算机(PC)来构成。
下面,图9显示了本发明图像处理设备的硬件构成。
图像处理设备100构成具有多个功能的多功能外围设备,该功能包括打印机功能、传真功能、数字复印机功能、扫描仪功能、和文件管理功能。
如图9所示,该图像处理设备100包括CPU201、ASIC(专用集成电路)202、SDRAM203、闪存204、NRS存储器205、PHY(物理介质结构)206、NVRAM(非易失存储器)207、操作板209、HDD(硬盘驱动器)210、调制解调器211、PI(个人接口)212、FCU(传真控制单元)213、USB(通用串行总线)214、IEEE(电气与电子工程师协会)1394接口215、引擎接口216、和引擎单元217。
这些元件是用于执行图像处理的硬件资源,如图像读取、图像形成、和绘图信息传送。
CPU201是通过ASIC202执行数据处理(每个功能的控制)的算术处理单元。
ASIC202是多功能设备,其包括HDD接口、CPU接口、SDRAM接口、本地总线接口、PCI接口、和MAC(介质访问控制器),并且共享这些用作CPU201的受控系统的设备。ASIC202促进应用程序(应用软件)的有效开发或来自结构领域的公共系统业务的支持。
如果需要,接收每个引擎单元的操作指令的操作面板209直接连接ASIC202,并且PHY206直接连接ASIC202。FCU213、USB214、IEEE1394接口215、和引擎接口216通过PCI总线218连接ASIC202,并且调制解调器211和PI212直接连接到ASIC202。
并且CPU201能用作处理单元,其通过经ASIC202从闪存204或HDD210的存储单元中读取所需的控制程序,并且在SDRAM203中开发和执行来处理信息。
SDRAM203是用作程序存储器的主存储器,其存储各种程序,包括OS、当CPU201执行数据处理时使用的工作存储器等。DRAM和SRAM可代替该SDRAM203使用。
例如,程序存储器存储也能够用于与闪存204的各种程序,以执行作为执行引导装入程序(引导程序)的文件的OS图像或OS,该OS启动图像处理设备100,并且处理后面所述内容。它是用作存储各种能够固定参数的固定参数存储器的非易失性存储器(存储单元),并且即使关闭电源也保持存储内容。
其中集成RAM和使用电池的备用电路的非易失RAM,或其他非易失性存储器,如EEPROM可以用于代替闪存204。
NRS存储器205是非易失性存储器,其存储后面所述的NRS应用程序,并且能添加NRS功能作为选项。PHY206是用于通过LAN和外部设备通信的接口。
NVRAM207充当模型/机器号存储器,其存储作为图像处理设备100的标识信息的模型/机器号,该存储器存储控制单元209的操作初始值,该存储器存储每个应用程序(APL)、存储器、自身设置情况或者记忆每个计数器信息(计算计数器的数据)的通信对方的初始值,并且非易失性存储器(存储单元)用作存储模型信息的存储器,该模型信息包括网络地址信息、协议等,并且即使电源关闭,也能保存存储器内容。非易失性存储器(如RAM)、累积使用电池的备用电路的非易失性RAM、EEPROM、闪存可用作NVRAM207。
操作面板209是操作和显示单元,其中操作单元和显示单元组合。HDD210是存储单元(记录介质),其保存数据,无论开启和关闭电源。在该HDD210中,也可以存储上述在闪存204中存储的程序和其他数据,或者在NVRAM207中存储的数据。用作收集、更新或传送处理被周期执行的目的地的数据也可以存储在HDD210中。
调制解调器211是调制/解调单元,并且当通过公共电话网络向传送服务器102发送数据时,调制解调器211以可以通过该公共电话网络的形式调制该数据。当从传送服务器102接收调制的数据时,调制解调器211执行调制数据的解调,以恢复该原始数据。
PI212具有符合RS485规范的接口,并且它通过未示意的线路适配器连接公共电话网络。
FCU213经由公共电话网络控制与外部设备的通信,该外部设备包括具有FAX设备或调制解调器功能(FAX通信能力)的图像处理设备,如数字复印机和多功能外围设备。
USB214和IEEE1394接口215是USB规范和IEEE1394规范的接口,用于分别与外围设备通信。
引擎接口216是将引擎部件217连接到PCI总线的接口。引擎单元217包括引擎,其包含公知的扫描仪引擎和绘图仪引擎,并且提供图像读取和形成,并且后处理单元执行后处理,如对纸张排序、穿孔和装订处理,在该纸张上由绘图仪引擎形成图像。
在上述图像处理设备100中,在通电时,CPU201通过ASIC202启动闪存204的引导装入程序,并且根据该引导装入程序,CPU201读取闪存204中的OS图像,将其装载到SDRAM203中并将其扩展为可用OS。并且如果完成OS的扩展,将开始该OS。
然后,如果需要,通过读取在NRS存储器205中的NRS应用程序或在闪存204中的应用程序可以提供各种功能,并且将该程序装载到SDRAM203中并进行扩展。
下面,图10显示了服务器的硬件组成。如图10所示,每个服务器103包括CPU301、ROM302、RAM303、SD(保密数字)卡304,和网络接口卡(NIC)305,这些通过系统总线306互联。
尤其是,在该服务器103中,CPU301是控制单元,其根据在ROM302中存储的控制程序来控制整个服务器103。并且ROM302是只读存储器,其存储包含由CPU301使用的控制程序的各种固定数据。
RAM303是当CPU301执行数据处理等时用作工作存储器进行临时存储的存储器。SD卡304是尽管服务器103的电源切断时仍保存该存储器内容的非易失存储器。NIC305是通信单元,用于通过包含因特网14的网络来执行通信方和信息的发送与接收。当然,如果需要,附加的硬件可以添加到服务器103的基本组成中。
下面,图11显示了在图3的传送服务器102的功能中用于执行关于处理的命令和命令响应的功能组成。
在图11显示的功能中,以任何可改写存储单元提供用于发送的终端命令库41、传送服务器命令库42、传送消息库51,以及用于接收的传送消息库52。例如,可以将它们提供在控制单元125的闪存,SDRAM或HDD中。可选地,也可以将其提供在文件服务器126中。
通过控制单元125的CPU来实现终端命令执行结果产生单元43、传送服务器命令产生单元44、消息收集单元45、消息分配单元47、和消息传送单元48的功能。
通过控制单元125的CPU和外部连接I/F123来实现HTTP服务器功能模块46和HTTP客户端功能模块49的功能。通过非易失性存储单元,如控制单元125的闪存或HDD来实现目的地信息存储单元50的功能。
将详细解释这些功能。终端命令库41是终端命令的库,在从图像处理设备100中接收的终端命令中,确定由该传送服务器102自己执行存储库中的该终端命令,并且该终端命令与响应命令、命令的标识信息、命令始发节点的信息等有关,并且记录该终端命令。
传送服务器命令库42是与响应该命令、命令的标识信息、命令目的地节点的信息等有关的传送服务器命令的库,并且记录该传送服务器命令。
在这些库中,对于每个命令产生表格形式的命令表,并且存储该信息,以便关联每个命令、标识信息和包含其响应的信息等。
该终端命令执行结果产生单元43对应响应产生单元。并且它具有终端命令处理器43a,该处理器是从终端命令库41中读取和执行终端命令的应用系统。
该终端命令处理器43a产生对终端命令的响应,并且它具有与终端命令的命令ID关联的功能,并且记录在终端命令库41中。
从图像处理设备100接收的终端命令与管理信息有关,该管理信息用于管理识别该命令的ID和该命令等,并且作为表格形式的终端命令表单记录在终端命令库41中。
并且当在终端命令库41中记录终端命令执行结果产生单元43产生的命令响应时,它被记录在与执行的终端命令有关的终端命令表单中。
从终端命令库41中将两种或多种终端命令读取到终端命令处理器43a中,并且有可能提供产生对每个终端命令的响应的功能。
当它包括用于终端命令的调度优先级的信息时,考虑执行它,该终端命令具有超过传送服务器102的优先级,并且执行处理,提供优先从高优先级的对象中读取的功能。
该终端命令处理器43a可以是不调用除终端命令执行所需的应用程序以外的应用的模块,并且执于命令。
图12显示了在传送服务器102的终端命令表单(sheet)中的数据结构的范例。
如图12所示,在传送服务器102中,在终端命令表单中提供存储“命令ID”、“传送资源信息”、“方法名称”、“输入参数”、“状态”、“输出参数”和“命令的通知节点”的数据的区域。
在这些当中,“命令ID”、“方法名称”、和“输入参数”对应于终端命令(及其附属ID),并且“状态”和“命令的通知节点”对应于管理信息。该“输出参数”是传送服务器命令的执行结果,并且充当由传送服务器102返回的命令响应的内容。
将解释每个数据项目的内容。该“方法名称”是请求传送服务器102的内容,并且表示由传送服务器102调用的功能的种类。“输入参数”是带有“方法名称”的数据,并且是调用功能时的变元。“传送源信息”表示在产生命令的节点处的设备的标识信息。在终端命令的情况下,将该图像处理设备100的标识信息记录在该数据中。
将所述信息改变为当发送命令的响应时表示目的地的信息。由于传送服务器102本身执行在终端命令库41中存储的所有的终端命令,不需要管理该命令的目标。
该“命令ID”是识别该终端命令的标识信息。该“状态”是表示终端命令处理的状态的数据,并且随着处理按这一方式,即“未处理”→“处理完成”→“响应完成”或按这一方式,即“未处理”→“处理期间”→“处理完成”→“响应完成”进行而变化。
由终端命令执行结果产生单元43产生的响应存储在“输出参数”中。它是空的,直到完成终端命令的执行,并且上述“状态”变为“处理完成”。
“命令的通知节点”是表示执行终端命令的模块的参考信息。
返回参考图11,传送服务器命令产生单元44对应请求产生单元,并且产生传送服务器命令和识别向其分配的命令的标识信息(ID)。
附加用于管理这一命令的目标信息和这一命令的管理信息,并且该管理信息具有联合这些信息的功能,并且记录到传送服务器命令库42中作为表格形式的传送服务器命令表单。传送服务器命令产生处理器44a执行该过程。
其中,传送服务器102中提供的应用程序对应于产生传送服务器命令的部分。在传送服务器命令产生处理器44a中提供这样的功能,即,在使得图像处理设备100执行每个命令时向产生的传送服务器命令提供优先级。
图13显示了在传送服务器102的传送服务器命令表单中的数据结构的范例。
如图13所示,在传送服务器102中,在传送服务器命令表单中提供存储“命令ID”、“目标信息”、“方法名称”、“输入参数”、“状态”、“命令执行结果的通知节点”和“输出参数”的数据的区域。
其中,“命令ID”、“方法名称”、和“输入参数”对应于传送服务器(及其附属ID),并且“状态”和“命令执行结果的通知节点”对应于管理信息。
该“输出参数”是从图像处理设备100中接收的命令响应的内容,用作命令的目标。
将解释每个数据项目的内容。该“方法名称”是请求图像处理设备器100的内容,并且表示由图像处理设备100调用的函数的种类。该“输入参数”是带有“方法名称”的数据,并且是调用函数时的变元。
该“目标信息”表示执行命令的目标设备的标识信息,即,该设备用作命令的目标。在传送服务器命令的情况下,将图像处理设备100的标识信息记录到此。该ID、属性名称、IP地址等可用作该标识信息。
由于传送服务器102本身一直产生传送服务器命令,不需要管理该命令的传送资源信息。该“命令ID”是识别该传送服务器命令的标识信息。
“状态”是表示终端命令的处理的进展状态的数据,并且随着处理按这一方式,即“未发送”→“等候响应”→“响应接收完成”进行而变化。
该“命令执行结果的通知节点”是显示模块的参考信息,当接收对在表格中表示的传送服务器命令的响应时,该模块通知并执行所需的处理。
尽管所述模块涉及在许多情况下记录该传送服务器命令的处理器,但这不是必需的。
在接收该命令响应阶段的内容存储在“输出参数”中。它是空的直到它从图像处理设备100中接收命令响应。
返回参考图11,消息收集单元45对应收集单元,并且关联命令ID和对应由终端命令执行结果产生单元43产生的命令响应的终端命令的传送资源信息,和该命令响应,并且从终端命令库41中读出的,并且关联命令ID和由传送服务器命令产生单元44产生的传送服务器命令的目标信息,和该命令,并且它从传送服务器命令库42中读出。
读取在消息表上表示的用于传送的消息,该消息表用于在后面详细解释的用于接收的传送消息库52的传送,并且它具有从其中产生输出消息的功能。
当对用于命令响应、或终端命令或传送的消息指定优先级时,有可能引起消息收集单元45分别顺序地读取高优先级的项目。
在该实施例中,通过XML(可扩充标记语言)描述输出消息,该XML是一种结构化语言,并且输出消息表示作为SOAP消息的上述命令响应或命令和命令ID。并且消息收集单元45产生一个SOAP消息作为与一个命令响应或命令有关的输出消息。此时,在SOAP报头中描述的每个命令的命令ID,并且在SOAP主体中描述命令响应或命令的内容。
在使用SOAP通信中,通过XML描述称为SOAP信包(信包)的消息,该SOAP信包包括SOAP报头和SOAP主体,并且通过HTTP协议交换该消息。
通过执行基于WSDL(网络业务描述语言)产生的转换程序(并行器)来实现来自该命令响应或命令的SOAP消息的产生,以便将数据串行化。以由XML描述的SOAP信包的状态存储用于传送的消息,并且存储的消息可用作没有变化的输出消息。
HTTP服务器功能模块46具有发送HTTP响应的HTTP响应发送单元46a,和接收HTTP请求的HTTP请求接收单元46b。
并且HTTP响应发送单元46a对应第二发送单元。HTTP响应发送单元46a具有产生HTTP响应的功能,该HTTP响应包含由消息收集单元45产生的输出消息,并且向图像处理设备100发送HTTP响应。在这一方面,在一个HTTP响应中可以包含两个或多个输出消息,并且可以任意混合的形成与命令响应有关的输出消息、与传送服务器命令有关的输出消息、和与传送消息有关的输出消息。当然,可以混合与由不同的服务器产生的传送消息有关的输出消息。
无论输出消息的类型如何,HTTP响应发送单元46a产生一个包含由消息收集单元45产生的所有输出消息的HTTP响应,并且向图像处理设备100发送该HTTP响应。
然而,可以考虑提供最大数量的输出消息,该输出消息包含在一个HTTP响应中。
顺便提及,一直执行HTTP响应的传送,甚至当消息收集单元45试图读出传送服务器命令、传送服务器命令响应或传送消息等,除非没有数据读出,并因此不产生任何应当发送给图像处理设备100的SOAP消息。
并且当HTTP请求接收单元46b接收来自图像处理设备100的HTTP请求时,一直执行读出的试验。这是因为传送服务器102不能通过防火墙11向图像处理设备100发送HTTP请求,如上所述。
HTTP请求接收单元46b对应第一接收单元,并且具有从图像处理设备100接收HTTP请求的功能。并且,在由HTTP请求接收单元46b接收的HTTP请求中,任意混合包含终端命令和与该命令有关的命令ID的接收的消息,和包含传送服务器命令或服务器命令的响应和与该命令或响应有关的命令ID的接收的消息。
接收的消息表示上述命令、响应、命令ID等,作为SOAP消息。并且接收时未检测它是否是寻址传送服务器102的消息或者是应当发送给服务器103的消息,并且对于HTTP请求,它没有必要包含目的地的信息。
消息分配单元47具有将在由HTTP请求接收单元46b接收的HTTP请求中包含的数据分配和记录到终端命令库41、传送服务器命令库42、和用于传送的传送消息库51中的合适一个。
尤其是,检索在目的地信息存储单元50中存储的目的地表,并且消息分配单元47用作目标确定单元,并且根据接收的命令或接收的命令响应的分类来确定每个数据项目的目标,以便基于确定结果来确定记录数据项目的库。
该目的地表规定命令或命令响应的目标与命令或命令响应的分类(组)之间的对应关系。并且通过使用有关的命令或命令响应作为关键字(key)并且搜索该目的地表可以获得命令或命令响应应当被发送的目标上的信息。
并且如果接收的命令(终端命令)的目标是传送服务器102自身,在终端命令库41中形成终端命令表单,在终端命令表单中记录终端命令和与该命令有关的命令ID。
并且如果接收的命令响应的目标是传送服务器102自身,该响应是对传送服务器命令的响应。命令响应的命令ID与在传送服务器命令库42中存储的传送服务器命令表单中的命令ID匹配,并且指定具有匹配的命令ID的传送服务器命令,并且将其记录到与该传送服务器命令有关的“输出参数”中。
尽管此时取出每个接收的消息,该消息划分HTTP请求并且包含在此,将该数据改变为在表格中记录所需的形式,通过执行必要的基于WSDL产生的转换程序(并行机)可以执行该转换。
另一方面,为了将关于命令和命令响应的消息发送给除传送服务器102自身以外的与命令和命令响应有关的作为目标的其他设备,向用于传送的传送消息库51登记。
并且在向用于传送的传送消息库51中记录的,产生和记录传送消息表单。
图14显示了传送消息表单的数据结构的范例。
如图14所示,在用于传送的传送消息库51的传送消息命令表中建立存储“目标信息”、“实体报头信息”和“消息的XML数据”的区域。
其中,在“目标信息”中记录根据消息分配单元47接收的命令的分类而确定的目标上的信息,或命令响应。
在表示消息的部分实体报头(后面将详细描述)上的信息记录在“实体报头信息”中,并且关于消息的SOAP信包(envelope)的内容记录在“消息的XML数据”中。
由于不是基于消息的内容,但由于它与传送消息有关,仅仅发送是必要的,因而没有必要改变SOAP信包的数据格式。
当消息分配单元47将消息记录在用于传送的传送消息库51中时,通过参考要表示的消息的HTTP请求的源节点上的信息,产生描述消息的源节点上的信息的报头,并且试图将其添加到实体报头信息中。
返回参考图11,消息传送单元48具有对于接收将消息记录到传送消息库52中,而对于发送从传送消息库51中读取记录的传送消息的功能,并且产生输出消息,和接收HTTP客户端功能模决49的HTTP响应接收单元49b的消息。
首先,关于输出消息的产生,为了每个目标读取应当发送给该目标的传送消息。并且由于此时该消息以由XML表示的SOAP信包的状态记录在传送消息表单中,它能用作用于按原样传送的消息。
用于传送的部分将在相同表的“实体报头信息”中记录的实体报头提供给SOAP消息,并且表示产生该消息。
产生和记录该传送消息表单,该传送消息表单用于将接收的与记录有关的消息记录在用于接收的传送消息库52中。然而,该表格的形式与用于发送的传送消息库51的情况有一点不同。
图15显示了在用于接收的传送消息库52中的传送消息表单的数据结构的范例。如图15所示,在用于接收的传送消息库52的传送消息表单中提供存储“实体报头信息”和“消息的XML数据”的数据的区域。
其中,在指示消息的部分实体报头(后面将详细描述)上的信息记录在“实体报头信息”中,并且关于消息的SOAP信包的内容记录在“消息的XML数据”中。
在该点,与对于传送的传送消息库51的情况相同,没必要改变SOAP信包的数据格式。
在对于接收的传送消息库52的情况下,不存在“目标信息”项目,而这是因为试图将消息的传送路径上的信息指示给实体报头。
如果再次返回图11的解释,HTTP客户端功能模块49将具有发送HTTP请求的HTTP请求发送单元49a,和接收HTTP响应的HTTP响应接收单元49b。
并且HTTP请求发送单元49a对应第一发送单元,产生描述由消息传送单元48产生的输出消息的HTTP请求,并且具有将其发送给服务器103的功能。
几个输出消息可以包含在一个HTTP请求中,并且此时可以任何混合关于命令响应的输出消息和关于图像设备命令的输出消息。
首先,当发送消息时,如果可以识别目标,没有必要识别该消息的内容。
并且可以混合关于命令的输出消息,或不同的命令响应或发送代理的不同的传送消息。
然后,不存在HTTP请求发送单元49a,并且它包括消息传送单元48产生的关于一个HTTP请求中的一个目标的所有的输出消息,并且试图涉及任何有关的输出消息,并且发送。
然而,也考虑提供包含在一个HTTP请求中的最大数量的输出消息。
当试图将传送消息的读出与具有消息传送单元48关联时,HTTP请求的传送不进行数据读出,并且当没有产生应当发送作为结果的SOAP消息时,也如此执行。
并且,应当周期地执行该读出试验。例如,通过计时器,可能每60分钟读一次。以这种方式进行,因为能防止发送,除非从传送服务器102要求通信,甚至存在将信息从服务器103发送给传送服务器120,如上所述。
通过提供机会周期地将通信请求发送给每个服务器103,并且从每个服务器103向传送服务器102发送信息,甚至从传送服务器102不发送任何数据,能防止传送所需的信息持续一段长的时间,并且停滞在服务器103中。当然,除了周期的定时外,可以合适地执行通过消息传送传送单元48的读出和紧接着的通过HTTP请求发送单元49aHTTP请求的的传送。
例如,当将有必要紧急发送的信息记录在用于传送的传送消息库51中时,消息分配单元47也可以使消息传送单元48来通知这个内容并读出。
HTTP响应接收单元49b对应第二接收单元,并且具有接收来自服务器103的HTTP响应的功能。并且接收的消息包含在与服务器命令和它的命令有关的HTTP响应命令ID中,响应终端命令和它的命令,并且包含相关命令ID的接收的消息被任意混合和被包含。
上述命令、响应、命令ID等表示作为SOAP消息的被接收的消息。并且由于存在应当发送给图像处理没备100的消息,如上所述,通过消息传送单元48将该消息记录到用于接收的传送消息库52中,在合适的计时中通过消息收集单元45将其读出,并且通过HTTP响应发送单元46a将其发送给图像处理设备100。
当在用于接收的传送消息库52上进行登记时,没有必要根据消息的目标在那里而改变对应。
当消息收集单元45从用于接收的传送消息库52中读出消息并且产生输出消息时,在删除传送目标的信息后,试图产生实体报头部分,该传送目标在传送路径上的信息表示为“实体报头信息”后将发送消息。
下面,图16显示了HTTP请求的范例,传送服务器102从图像处理设备100接收的HTTP请求的范例显示在图16中。
由于图16显示了该HTTP请求,作为主体部分表示跟随在MIME(多功能因特网邮件扩展名)后面的多部分消息。
嵌入SOAP信包,尽管分别这样的由每个部分表示实体报头,对其详细的描述将省略。
尽管在图16范例的HTTP请求的HTTP主体上由“MIME边界”分类的每个元素构成第一独立部分、第二部分、第三部分和第四部分,包含在HTTP主体中的部分的数量不限于四。没有包括零块的限制是合适的。
终端命令所表示的内容,描述对传送服务器命令的响应的内容,和描述对服务器命令的响应的内容包含在嵌入到HTTP请求中并被转交的SOAP信包中。
传送服务器102向图像处理设备100发送的HTTP响应的范例显示在图17中。如图17所示,只有图16中的HTTP请求和用于解释HTTP响应的HTTP报头在形式上相互不同,并且与HTTP请求的主体部分的情况相同,对其的详细描述将省略。
根据MIME的多部分的SOAP信包被表示。根据命令或命令响应的内容,SOAP信包的内容将不同。
传送服务器命令所表示的内容,描述传送服务器命令的内容,和描述对终端命令的响应的内容包含在嵌入到HTTP请求中并被转交的SOAP信包中。
下面,图18显示了传送服务器102发送给服务器103的HTTP请求的范例。
如图18所示,该HTTP请求与图16所示的HTTP请求相同。然而,自然地与SOAP信包的内容有关,根据命令或命令响应的内容,SOAO信包的内容不同。
并且终端命令所表示的内容,描述对服务器命令的响应的内容包含在嵌入到HTTP请求中并被转交的SOAP信包中。
通过传送服务器102的消息分配单元47将显示SOAP消息的源节点的信息添加到每个部分实体报头中,该SOAP消息由“X-Received-From”报头部分表示。
并且服务器103能基于该信息规定终端命令的响应或服务器命令的传送路径。
图19显示了传送服务器102从服务器103接收的HTTP响应的范例。
如图19所示,该HTTP响应与图18所示的HTTP响应相同。然而,自然地与SOAP信包的内容有关,根据命令或命令响应的内容该SOAO信包的内容不同。
并且服务器命令所表示的内容,描述对终端命令的响应的内容包含在嵌入到HTTP响应中并被转交的SOAP信包中。
将显示传送路径和SOAP消息的目标的信息添加到每个部分实体报头中,该SOAP消息由X-Send-To报头部分表示。
并且传送服务器102的消息收集单元45能基于该信息识别消息的目标。
上述形式的HTTP请求和HTTP响应是可以发送的一个消息,并且没有变化的形式,一个以上的可以结合,并且它们能产生每个部分SOAP信包。
当划分该形式的HTTP请求和HTTP响应并且取出每个部分SOAP信包时,具有普通网络业务(SOAP RPC)功能的其他通信没备中,也能用于通信,通信其实描述了对于HTTP请求或HTTP响应的一个SOAP信包。
如图16和图17所示的在图像处理设备100和传送服务器102之间传送和接收的消息中,没有必要表示SOAP消息的传送路径目标。
下面,利用图20至31解释一些在HTTP请求或HTTP响应中表示的部分的范例。
图20显示了描述到传送服务器(设备管理服务器)102的终端命令的部分范例。
在该范例中,显示由部分实体报头的“X-SOAP-Type”的部分表示的SOAP消息是否是SOAP请求或者它是SOAP响应的信息。
该范例显示它是SOAP请求,即,它是通过“请求”值描述该命令的SOAP消息。
该“SOAP Action”报头显示该SOAP请求的内容,并且显示范例中由URI(统一资源标识符)“http://www.--”请求的内容。
当在消息的接收侧SOAP消息是SOAP响应的“SOAP Action”报头时,通过存在的报头能确定SOAP消息是否是SOAP请求或者是SOAP响应。
并且将名称空间声明为“信包”标签的属性。并且除了由SOAP规定的名称空间作为标准以外,声明由“http://www.example.com/header”和“http://www.example.com/maintenance/server”的URI指定的名称空间。因此,发现它是属于由“http://www.example.com/header”的URI指定的名称空间标签,其与给定名称空间前缀为“n”的XML标签有关。
与给定名称空间前缀为“ns”的XML标签有关,结果它是属于由“http://www.example.com/maintenance/server”的URI指定的名称空间的标签。
对于SOAP报头,作为该终端命令的ID的“12345”表示为“请求ID”的XML标签的内容。指定在传送服务器102中调用的方法的信息像SOAP主体一样,在“主体”标签的下面,“错误消息”标签被表示(它对应于“方法名称”和所示的命令的分类),和表示为低级的标签“错误ID”的在调用该方法的时间上的变元,以及“解释”的元素(它对应于“输入参数”)。
错误消息的通知内容被表示。传送服务器102的消息分配单元47根据命令的种类识别由传送服务器102执行的部分所表示的命令。
因此,目标或命令的目标没有指示这部分,并且没有必要识别该命令最终由图像处理设备100侧的哪个设备执行。
描述对图20所示的终端命令的响应的部分范例显示在图21中。
在该范例中通过指示作为“响应”的实体报头部分的“X-SOAP-Type”报头的值显示了由该部分表示的SOAP消息是SOAP响应,即,它是描述该命令响应的SOAP消息。
而且,在该范例中,名称空间的声明与该图20所示的范例相同。并且作为产生响应的终端命令的ID的“12345”作为由SOAP报头描述的“Command ID”的XML标签的内容。
在该“主体”标签下面直接提供“错误消息响应”标签(所示的命令响应的分类),它是在SOAP主体中所示的“错误消息”命令的响应,并且命令响应的内容被低级的标签表示。
通常表示在接收的错误消息上的信息。并且该信息存储在图像处理设备100中的终端命令表单的“输出参数”项目中。
由于没有必要识别命令响应由图像处理设备100侧的哪个设备产生,对此,命令响应的源节点没有指示该分布式处理系统。
图22显示了当从图像处理设备100向服务器103a(销售管理服务器)到传送服务器102发送终端命令时的部分的书面范例。
而且在该范例中,与图20的情况相同,通过“X-SOAP-Type”报头的“请求”值显示由该部分表示的SOPA信包是SOAP请求,在“SOAP Action”报头上的信息显示SOAP请求的内容。
名称空间的声明与图20的情况相同,作为“信包”标签的属性。并且除了由SOAP规定的名称空间在此作为标准之外,声明由“http://www.example.com/header”和“http://www.example.com/sales/server”的URI指定的名称空间。
在该SOAP报头中,是图像设备命令的ID的“12346”表示为“请求ID”的XML标签的内容。由于指定在服务器103a中的“主体”标签下直接调用的方法的信息作为SOAP主体,“表格订购”标签被表示并且在调用该方法时的变元表示为低级的标签“产品名称”,和“数量”的元素。表格订购的内容被表示。
传送服务器102的消息分配单元47根据命令的种类识别由该部分表示的命令应当发送给服务器103a。
因此,目标或命令的目标没有显示这部分,或者没有必要识别该命令最终由图像处理设备100侧的哪个设备执行。
图23显示了当从传送服务器102向服务器103a发送图22所示的命令时的该部分的书面范例。
由于这一部分是在向服务器103a发送与图22所示的内容相同的命令时的内容,与用来解释图22的部分几乎相同的内容被表示。
然而,将“X-Received-From”报头添加到实体报头部分,并且显示已经从“Client”(考虑为图像处理设备100)发送由该部分表示的命令的信息被表示。
并且在执行命令后,使用该信息以指定返回命令响应时的传送路径。
尽管表示了作为命令的源节点的图像处理设备100的标识信息,当命令覆盖两个或多个设备并且已经发送给它时,为每个传送一个接一个地添加“X-Received-From”报头,从是命令的源节点的设备的最高一级开始到产生该部分的设备的底,并且显示了作为最后源的设备的标识信息。
对于部分,不需要指示命令的目的地。传送服务器102仅仅识别将命令向下一个传送的目的地,并且由于是发送的设备,因而不需要识别最后被传送到那个装置。
图24显示了在从服务器103a将对到服务器103a的终端命令的响应发送给传送服务器102时的部分的书面范例。
而且在该范例中,通过指示实体报头部分的“X-SOAP-Type”报头的值为“响应”,显示了由该部分表示的SOAP消息是SOAP响应,如图21的情况。
在从传送服务器102预先发送命令响应时的传送路径表示为“X-Send-To”报头。
尽管在此表示充当最后目标的图像处理设备100的标识信息,当传送路径覆盖两个或多个设备时,提供两个或多个“X-Send-To”报头的和充当路径的设备的标识信息被一个接一个的表示,并且表示了该设备的标识信息,该设备随着下个目标而变为末端(bottom),并且用作目标的设备最终到最高一级。
而且在该范例中,名称空间的声明与图22所示的范例相同。
并且对于SOAP报头,表示是产生作为“命令ID”的XML标签的内容的响应的终端命令的ID的“12346”。
提供直接在“主体”标签下的SOAP主体中显示的对于“表格订购”命令响应的“表格订购响应”标签,并且命令响应的内容表示为低级的标签。
正常接收表格订购并表示通知费用的信息。
由于对该部分,没有必要识别命令响应由传送服务器102侧的哪个设备产生,命令响应的源节点没有指示该分布式处理系统。
图25显示了在从传送服务器102向图像处理设备100发送图24所示的命令响应时的部分的书面范例。
由于该部分是在向图像处理设备100发送与图24所示相同的命令响应时的内容,显示了与用于解释图24的部分几乎相同的内容。
然而,由于再没有必要向图像处理设备100发送传送路径上的信息,已经删除了实体报头部分的“X-Send-To”报头。
描述给图像处理设备的传送服务器命令的部分的范例显示在图26中。
也在该范例中,像图20的情况那样,“X-SOAP-Type”报头的“请求”值显示由该部分表示的SOAP信包是SOAP请求,并且在“SOAP Action”报头上的信息显示该SOAP请求的内容。
由于从传送服务器102可以将命令直接发送给图像处理设备100,没有表示显示传送路径上的信息的“X-Send-To”报头。
声明该名称空间这点与作为“信包“标签的属性的图20的情况相同,。并且除了由SOAP规定的名称空间作为标准以外,声明由“http://www.example.com/header”和“http://www.example.com/maintenance/server”的URI指定的名称空间。
在该SOAP报头中,将作为该传送服务器命令ID的“98765”表示为“请求ID”的XML标签的内容。
并且作为指定调用的方法直接在图像处理设备中“主体”标签下作为SOAP主体的信息,“温度传感器值采集”标签被表示,并且将调用该方法时的变元表示为低级的标签“传感器ID”的元素。
获得传感器值的传感器的ID被表示。在图像处理设备100侧,由于能够识别对于接收的命令的命令响应仅仅暂时发送给传送服务器102,该部分没有表示命令的源节点上的信息。
在图27中显示了描述对图26所示的传送服务器命令的响应部分的范例。
而且在该范例中,通过指示实体报头部分的“X-SOAP-Type”报头的值为“响应”,显示由该部分表示的SOAP消息是SOAP响应,如图21的情况。
也在该范例中,名称空间的声明与图26所示的范例相同。
并且对于SOAP报头,将作为产生响应的传送服务器命令的ID的“98765”表示为“命令ID”的XML标签的内容。
响应于在SOAP主体中所示的“温度传感器值采集”命令的“温度传感器值采集响应”标签直接在“主体”标签的下面,并且该命令响应的内容表示为低级的标签。
要求表示值采集的传感器的温度值的信息。由该部分表示的命令响应相对于传送服务器命令,并且该传送服务器102根据传送服务器102的消息分配单元47的命令响应的分类用于目标识别。
因此,对于该部分,没有必要表示该目标和命令响应的目标,并且没有必要识别该命令响应最终由图像处理设备100侧的哪个设备发送。
图28显示了在对于传送服务器102、从服务器103a将服务器命令发送给图像处理设备时的该部分的书面范例。
而且,在该范例中,如同图20的情况相同,对于“X-SOAP-Type”报头的“请求”值,显示由该部分表示的SOAP信包是SOAP请求,并且在“SOAP Action”报头上的信息显示该SOAP请求的内容。
通过服务器103a,此时能使它识别传送路径和命令的目标,并且从传送服务器102预先发送命令的传送路径表示为“X-Send-To”报头,如图24的情况。
声明名称空间这一点与图20的情况相同,作为“信包”标签的属性。
并且除了由SOAP规定的名称空间作为标准,声明由“http://www.example.com/header”和“http://www.example.com/sales/client”的URI指定的名称空间。
在该SOAP报头中,作为服务器命令的ID的“77777”表示为“命令ID”的XML标签的内容。
对于指定调用的方法的信息直接在图像处理设备100中的“主体”标签的下面作为SOAP主体,“产品预览的通知”标签被表示,并且在调用方法时的变元表示为低级的标签“产品名称”,和“单价”元素。
产品名称和新产品的单价被表示。即使不知道命令是从哪里发送的以便以后陈述,但由于传送服务器102能向合适的目标发送命令响应,所以没有向该部分指示命令的源节点的信息。
图29显示了从传送服务器102向图像处理设备100发送图28所示的服务器命令时的该部分的书面范例。
由于向图像处理设备100发送与图28所示的相同的服务器命令时产生该部分,所以表示了与用来解释图28的部分几乎相同的内容。
然而,由于应当发送给图像处理设备100的传送路径上的信息仍然是不必要的,所以该实体报头部分的“X-Send-To”报头被删除。
在图像处理设备100侧,识别出对接收的命令的命令响应只应当暂时发送给传送服务器102,并且由于在此之后不需要识别命令响应发送的位置,所以不向该部分表示命令的源节点的信息。
图30中显示了在从图像处理设备100向传送服务器102发送图28所示的对服务器命令的响应时,该部分的书面范例。
而且在该范例中,通过指示实体报头部分的“X-SOAP-Type”报头的值为“响应”,显示了由该部分指示的SOAP消息是SOAP响应,如图21的情况。
而且,在该范例中,名称空间的声明与图28所示的范例相同。
并且对于SOAP报头,表示了作为产生该响应的服务器命令的ID的“77777”,其作为“命令ID”的XML标签的内容。
提供了响应于“产品预览的通知”命令的“产品预览的通知响应”标签,其在“主体”标签下面直接在SOAP主体中显示,并且该命令响应的内容表示为低级的标签。
正常接收的通知的信息被表示。由该部分表示的命令响应与服务器命令相对,并且应当发送给服务器103a,根据传送服务器102的消息分配单元47的命令响应的分类来识别。
因此,对于该部分没有必要指示目标和命令响应的目标,并且没有必要识别该命令响应最终由该图像处理设备100侧发送给哪个设备。
传送服务器102也不需要识别该命令最终发送给哪个设备。
图31显示了在从传送服务器102向服务器103a发送如图30所示的命令响应时的该部分的书面范例。
由于该部分是在向服务器103a发送与图30所示的相同的命令响应时的内容,与用来解释图30的部分几乎相同的内容被表示。
尽管如图23的情况,将“X-Received-From”报头添加到实体报头部分中,由于不需要对返回的命令响应进行响应,该陈述不是必需的。关于这一点,即不对该部分表示命令响应的目标,这与图23的情况相同。
下面,将使用流程图32至图41解释在传送服务器102中执行的处理,该传送服务器102具有上面解释的结构和功能。
当控制单元125的CPU(当它只称为“CPU”时,在图32至图41的解释中应当特别指出该CPU,除非不接受)执行必要的控制程序时,执行这些流程图中显示的处理。
首先,图32显示了消息收集的流程图和分配处理基本流程。
如果从图像处理设备100发送HTTP请求,CPU将启动在图32的流程图中显示的处理。并且从图像处理设备100首先接收该HTTP请求(S11),并且接收的HTTP请求的HTTP主体划分为每个部分(S12)。
划分为每个部分是划分为由“MIME边界”分类的元素,并且划分涉及所有的部分。
然后,重复步骤S13的消息分配处理用于划分的所有部分,并且按顺序作为对象而获得。
并且当执行涉及所有部分的这些处理时,进行到下面的步骤S14。
在目前的处理中,步骤S11和S12是第一接收过程的处理,并且CPU用作HTTP请求接收单元46b。
在步骤S13,CPU用作消息分配单元47。在步骤S14之后的处理是关于HTTP响应传送给图像处理设备100的处理。
并在该处理中,CPU执行传送消息收集处理(S14)。该处理是为了接收,从传送消息库52中收集应当发送给图像处理设备100的消息的处理,并且包括从收集的消息中产生启动传送的该部分的处理。
然后,执行传送服务器命令收集处理(S15)。该处理是从传送服务器命令库42中收集应当发送给图像处理设备100的传送服务器命令的处理,并且包括根据收集的数据、通过SOAP信包产生该部分的处理。
下面,执行终端命令执行结果的收集处理,该结果是终端命令的响应(S16)。该处理是从终端命令库41中收集应当发送给图像处理设备100的命令响应的处理,并且包括根据收集的数据、通过SOAP信包产生该部分的处理。
然后,通过步骤S14至S16的处理产生的部分合并为一个,产生包含所有部分的HTTP响应(S17),并且将该HTTP响应发送给图像处理设备100(S18)。
步骤S14至S16的处理以随机顺序进行是可能的。
在目前的处理中,在步骤S14至S16中CPU用作消息收集单元45。
步骤S17和S18是第二发送过程的处理,并且CPU用作HTTP请求发送单元46a。
下面,利用对每个部分详细显示的流程图解释图32的流程图中所示的处理。
图33是用于解释图32所示的消息分配处理的内容的流程图。
在该处理中,CPU从相关部分的SOAP消息中获得在主体标签下的标签的名称空间URI(S21)。
如图20至图31的范例所示,在该SOAP消息中能够,显示对主体标签下的命令或命令响应的分类的标签被表示。
将名称空间前缀(例如,图20的情况“ns”)指定这一该标签,并且可以从该名称空间前缀和在该“信包”标签内部的名称空间规定的内容中获得标签的名称空间URI。
由于名称空间URI用作标签分组,可以考虑具有相同名称空间URI的命令或命令响应是属于相同组的命令或命令响应。
下面,搜索按关键字存储到目的地信息存储单元50中获得名称空间URI的目标表,并且获得候选部分消息的目标的信息(S22)。
图34显示了目标表的范例。
如图34所示,在该目标表上,对每个名称空间URI表示属于名称空间或命令响应的命令的目标的信息。
并且目标的信息可以存储为IP地址、主机名称等。当然在此时,即使相同的目标对应不同的名称空间URI也没有关系。
并且对于在步骤S21获得的名称空间URI,对关键字通过搜索该表格来获得侯选部分消息的目标。此时,侯选部分消息不需要区别是否它是关于命令的内容,或者是否它是关于命令响应的内容。
例如,当它是由图20的侯选部分所示的部分时,在“主体”标签下面的标签属于http://www.example.com/maintenance/server的名称空间,并且发现关于该部分的消息的目标是传送服务器102本身。
当目的地表中没有包含名称空间URI时,可能执行错误处理。
下面,确定在步骤S22获得的目标是否是传送服务器102自身(S23)。
并且如果是本身,表示应当执行作为终端命令的该目标部分,该终端命令是对传送服务器命令的响应。
然后,该目标部分进行这样的确定。在图33中,表示确定是否它响应于传送服务器命令(S24)。
并且根据该“SOAP Action”报头是否存在于目标部分的内容,和“X-SOAP-Type”报头来确定这一判断。
并且如果它响应于传送服务器命令,在步骤S25至S28将执行关于响应登记的处理。
即,它转变为表格(form)的数据,其首先分析该部分的SOAP信包并且记录在传送服务器命令表单(sheet)中(S25)。
它从传送服务器命令库42中搜索对应于该响应的传送服务器命令,并且该响应的数据被记录在与该传送服务器命令有关的传送服务器命令表单的“输出参数”的项目中(S26)。
应当将在传送服务器命令的传送时附加的“命令ID”上的信息相同的命令ID给定到命令响应,并且至于传送服务器命令的搜索,该信息可作为关键字来执行。
在完成数据记录之后,记录数据的传送服务器命令表单的“状态”转变为“响应接收完成”,并且显示它(S27)。
并且报告记录在“命令执行结果的通知节点”中的通知节点具有响应(S28)。
通过该通知,可以识别产生传送服务器命令的应用具有响应产生的命令,并且可以执行根据响应的处理。
例如,当对应于随着图像处理设备100突然增加的应用产生传送服务器命令以获得图像处理设备100的温度传感器的传感器值时,如果该命令发送给图像处理设备100,图像处理设备100则返回包含需要的传感器值的命令响应。
并且在传送服务器(设备管理器)102侧,如果接收该命令响应,在此基于包含的命令ID,搜索传送服务器命令的响应,这对应于发现的传送服务器命令,并且该命令响应将被记录。
并且报告与记录为该命令的执行结果报告目标的突然增加对应的该应用具有响应。
如果当接收通知时参考传送服务器命令表单时,该应用可以从“输出参数”的项目中获得产生的命令的执行结果。在到上述步骤S28的处理完成之后,图33的处理结束,并且返回到最初处理。
当在步骤S24没有响应传送服务器命令时,由于该目标部分是传送服务器应当执行的终端命令,它们是步骤S29至S33,并且执行与命令的记录有关的处理。
就是说,它转变为表格形式的数据,其首先分析所述部分的SOAP信包并且记录在终端命令表单中(S29)。
在终端命令库41中产生用于记录该终端命令的终端命令表单(S30),并且将终端命令、命令ID、和传送源信息记录在该终端命令表单(S31)中。
该终端命令的内容记录在该终端命令表单的“方法名称”和“输入参数”的项目,以及由该部分表示的命令ID记录在“命令ID”的项目中。
关于“传送源信息”,表示被表示目标部分的HTTP的传送源信息可以表示被获得和被记录。
当“X-Received-From”报头是一个目标部分实体报头时,也将该内容记录为传送路径的信息。该“状态”的初始值是“未处理”,并且“输出参数”的初始值是空值。
在记录上述项目完成之后,通过参考定义该方法和该处理程序之间的对应的预定的对应信息,来搜索对于该处理者(终端命令处理者43a)用于执行存储在该终端命令表单中的“方法名称”的方法的参考信息(S32)。并且发现的参考信息记录在该终端命令表单的“命令的通知节点”的项目中(S33)。
在完成直到上述步骤S33的处理之后,图33的处理结束,并且该控制返回到最初处理。
由于如果在步骤S23中目标不是它本身,目标部分的消息应当发送给其他设备,这是步骤S34至S36,执行有关传送消息的记录的处理。
就是说,首先在用于传送的传送消息库51中产生用于记录该消息的传送消息表单(S34),并且消息和消息上的目标信息记录在用于传送的消息表但中(S35)。在此,侯选部分的实体报头按原样记录在“实体报头信息”的项目中,并且SOAP信包的内容记录在“消息的XML数据”的项目中。
关于“目标信息”,记录在步骤S22获得的信息。
并且在记录到上述项目中完成之后,将“X-Received-From”报头添加到在“实体报头信息”中记录的实体报头的末端,并且作为消息的源节点的信息。表示被表示目标部分的HTTP的源节点的信息(S36)。
在到上述步骤S36的处理完成之后,图33的处理结束,并且返回到最初处理。
在图33的处理结束之后,返回到图32的处理。然而,如果存在如图33所示的下一部分,将对该部分重复图33的处理。接着,图35的传送消息收集处理执行在图32的基本流程的步骤S14中。
在这一处理中,CPU收集传送消息表单,利用该传送消息表单对于图32的步骤S11的接收、将从传送消息库52接收的HTTP请求的源节点HTTP首先指示到“X-Send-To”报头的底端(S41)
记录到用于接收的传送消息库52中的传送消息表单中的信息已经显示在图15中,并且该“X-Send-To”报头签录在其中的“实体报头信息”的项目中。
下面,通过将在步骤S41收集的所有传送消息表单作为目标,连续地重复步骤S42和S43的处理。
并且在这一处理中,产生在目标传送消息表单中首先表示的传送消息的部分(S42)。该处理将在“实体报头信息”的项目中记录的实体报头提供给在对象表单的“消息的XML数据”的项目中记录的SOAP信包。
然而,由于没有必要将实体报头中底端的“X-Send-To”报头的内容告知给目标设备,因而试图删除该报头。
产生该部分的过程结束时将从用于接收的传送消息库52中删除该目标传送消息表单(S43)。
并且当与所有收集的表单有关地执行这些处理时,进行到图32的步骤S15所示的步骤中。
下面,在图36中显示图32的步骤S15之后的处理。
在该处理中,CPU从传送服务器命令库42中收集的目标信息等于在图32的步骤S11中接收的HTTP请求的源节点。
并且,传送服务器命令表单的“状态”、“方法名称”和作为应当发送的传送服务器命令的“还没有发送的输入参数”的内容被收集,并且“命令ID”的内容也被收集作为该命令的命令ID(S51)。
由于“未发送”的“状态”显示了在命令由传送服务器命令产生单元44产生之后仍然没有发送给图像处理设备100,能在此基础上提取应当发送给图像处理设备100的命令。
然后,通过将在步骤S51收集的所有传送服务器命令作为目标连续重复步骤S52至S54的处理。
在该部分的处理中,首先是目标传送服务器命令和它的目标命令ID。它分别转变为在该SOAP主体中包含的XML文档和(SOAP信包)SOAP报头(S52),并且该信息将实体报头添加到此,并且产生与目标命令有关的部分(S53)。
并且表示目标传送服务器命令的传送服务器命令表单的“状态”转变为“等候响应”(S54)。
“等候响应”这样的“状态”示出已经完成将命令响应发送到图像处理设备100。
并且当执行与所有收集的传送服务器命令有关的这些处理时,进行到步骤S55。在此,对于CPU的传送源信息的终端命令库41等于在图32的步骤S11接收的HTTP请求的源节点。
并且所述状态收集应当发送终端命令表单的“输出参数”的“内容”,其是对终端命令的命令响应中“处理完成”,并且也收集作为相应终端命令的命令ID的“命令ID”的内容(S55)。
在传送服务器102中的“处理完成”的状态表示通过终端命令处理结果产生单元43完成与该终端命令对应的处理,但是仍然没有将它通知给图像处理设备100。因此,在该状态的基础上可以提取发送给图像处理设备100的命令响应。
然后,通过将在步骤S55中收集的所有终端响应作为目标连续地重复步骤S56至S58的处理。在该处理中,首先收集命令ID和该目标命令响应和它的目标响应。
它分别转变为在该SOAP主体和SOAP报头中包含的XML文档(SOAP信包)(S56),并且在这些信息中添加实体报头,并且产生与目标命令有关的部分(S57)。
这些处理与步骤S52和S53的处理相同,除了对性不同。并且下面,表示目标命令响应的终端命令表单的“状态”转变为“响应完成”(S58)。
“响应完成”这样的示出已经完成将命令响应通知给传送服务器102。
并且,完成目前的所有处理之后,CPU合并在步骤S53、S57或图35的步骤S42中产生的每个部分,产生如图17所示的多部分HTTP响应,发送给图像处理设备100(S59),并且结束处理。
如上所述,利用图32至图36解释由传送服务器102执行的消息收集和分配的处理。
从图像处理设备100,两个或多个操作请求和操作响应可被插入方块中,并它能接收、能处理,并且当没有向它们给定目标时,可以自动识别合适的目标,并且可以执行对应于目标的通信。
自己产生的或从其他设备接收的应当发送给图像处理设备100的两个或多个操作请求和操作响应可以集中地发送给图像处理设备100。
在实际完成该传送后,可以进行“状态”的变化,其中由步骤S54或S58来执行它。
由于将要发送的命令和命令响应可再次设置为传送的对象,即使这样做发生通信错误,所以,提高了系统的可靠性。
同样,在图35的步骤S43执行的传送消息表单的删除与此相同。
在产生所有应当发送的部分之后进行合并之后,要发送和接收所有部分,这解释为通过将其分为每个部分进行处理,但不必这样做。
首先发送HTTP报头,自此以后无论何时它产生一个部分,一个接一个地发送该部分,并且当完成所有该部分的传送之后,与传送有关的效果是可以发送数据。
由于可以在一次会话中发送,并且可以立刻管理协商的处理,甚至这样做,如果在这些过程中发送的数据是只具有逻辑连续的一个HTTP报头的一个HTTP响应,可以获得与合并和发送的情况相同的效果。
由于可以减小用于应当发送的数据缓冲器所需的存储空间,通过通信设备可以低成本处理大规模的数据。
另外,接收方每次接收每个部分时,每个部分的处理可以一个接一个的执行。与发送方的情况类似,通过以该方式执行有可能减小存储空间。
下面,将解释与终端命令的执行有关的处理。图37是用于解释该处理范例的流程图。
在执行步骤S33的处理之后,执行流程图37所示的处理。就是说,在图33中将终端命令记录在终端命令库41之后,立刻执行图37中的与终端命令的执行有关的处理。
在该处理中,CPU用作终端命令执行结果产生单元43。
在该处理中,基于和记录的终端命令有关的终端命令表单的“命令的通知节点”的信息,首先调用应用程序。并且通过传递“方法名称”和“数据参数”的数据来执行与终端命令的执行有关的处理(S61)。
在该流程图中没有显示与终端命令本身的执行有关的处理,但是CPU通过使用处理程序(handler)分别执行这一处理。
在执行步骤S61之后,获得执行结果并将其记录在该终端命令表单的“输出参数”项目中(S62)。并且该终端命令表单的“状态”转变为“处理完成”,并且通知该处理完成(S63)。
通过执行上述处理,有可能执行终端命令并且建立该状态,其中终端命令的执行结果能发送给图像处理设备100,作为命令响应。
换句话说,图38的流程图中所示的处理可独立于和图32所示的传送服务器102与图像处理设备100之间的消息的发送和接收有关的处理而执行,作为和终端命令的执行有关的处理。
而且在该处理中,CPU用作终端命令执行结果产生单元43。CPU在传送服务器102启动时启动该处理。
并且在该处理中,它处于备用直到确定终端命令库41中是否存在状态是“未处理的”任何终端命令表单(SX1),并且如果首先不存在任何内容,它将发现该终端命令表单。
如上所述,在终端命令表单中,状态“它是未处理的”是该“状态“的初始值,并且显示在命令记录之后不特定执行处理。
当通过步骤SX1发现“未处理的”终端命令表单时,它们中的一个成为处理对象,并且该终端命令表单的“状态”转变为“处理中”(SX2)。
然后,如果在与图37的步骤S61至S63相同的步骤中处理的并在该处理对象的终端命令表单上表示的该终端命令被执行并完成,它将返回到步骤SX1,并且重复处理。可以同时通过两个或多个线程(例如,四个线程)执行上述处理。
由于用作处理对象的终端命令表单的“状态”不是“未处理”,甚至同时由两个或多个线程处理,但是相互重叠并且不会按顺序放置一个终端命令表单作为处理对象。
进一步的处理不会延迟,即使存在要求执行时间的命令,由于如果执行上述命令,终端命令能以任意时间执行。
并且可以执行结果,而按照来自执行结束的命令响应进行,并且它能转变为发送给图像处理设备的状态。
下面,图39是用于解释关于服务器之间的消息传送的处理的流程图。
对于在图34所示的目的地表显示的目的地之一(在此,考虑为服务器103),CPU以合适的计时执行该处理,。
在这一处理中,从用于传送的传送消息库51中首先收集将目标目的地记录在“目的地信息”项目中的传送消息表单(S71)。
并且通过将在步骤S71中收集的所有传送消息表单作为目标,连续重复步骤S72和S73的处理。
并且在这些处理中,产生在该目标传送消息表单中首先显示的传送消息部分(S72)。该处理将在“实体报头信息”项目中记录的实体报头提供给在对象表单的“消息的XML数据”项目中记录的SOAP信包。
产生部分结束时将从用于传送的传送消息库51中删除该目标传送消息表单(S73)。
并且当执行与所有收集的表单有关的处理时,产生的部分被合并为一个(S74),产生如图18所示的多部分的HTTP请求,并且将其发送给目标目的地(S75)。
在目前的处理中,在步骤S71至S73,CPU用作消息传送单元48。步骤S74和S75是第一发送过程的处理,并且CPU用作HTTP请求发送单元49a。
这与上述图35的步骤S43的情况相同,在实际完成该传送之后,在步骤S73执行传送消息表单的删除。
接着,从目标目的地接收HTTP响应作为对发送的HTTP请求的通信响应(S76)。并且将接收的HTTP响应的HTTP主体分为每个部分(S77)。
划分为每个部分是指划分为由“MIME边界”分类的元素,如图32的步骤S12的情况,并且划分涉及的所有部分。
然后,对划分的所有部分重复步骤S78和S79的处理,并按顺序得到对象。
在这些处理中,在用于接收的传送消息库52中首先产生用于记录该目标消息的传送消息表单(S78),并且将该目标消息记录在用于传送的消息表单中(S79)。
在此,将候选部分的实体报头按原样记录在“实体报头信息”项目中,并且将SOAP信包的内容按原样记录在“消息的XML数据”中。在此时没有删除该“X-Send-To”报头。
当执行在步骤S77得到的所有部分的有关的处理时,图39的处理结束。
在上述处理中,步骤S76和S77是第二接收过程的处理,并且CPU用作HTTP响应接收单元49b。在步骤S78和S79,CPU用作消息传送单元48。
图40是用于解释与图39的消息传送处理的执行计时控制有关的处理的流程图。
CPU在传送服务器102开始时开始这一处理。并且对于每个固定时间消息传送处理,通过将在图34和图39中所示的目的地表中表示的所有目的地作为目标、一个接一个的显示这一处理执行。
在该情况中,当在目的地表中多次出现相同的目的地时,如果执行与一个目的地有关的消息传送处理被执行,这是足够的。
因此,如果对于消息可以发送的所有的目的地,周期地执行消息传送处理,并且发送作为通信请求的HTTP请求,甚至当通过从传送服务器102侧一直发送该通信请求执行从传送服务器102到目的地的通信。
能够防止提供从目的地向传送服务器102发送信息的机会,并且向传送服务器102传送所需的信息能持续较长时间,并且停滞在服务器103中。
当然,除了周期定时之外可以合适地执行消息传送处理。例如,当将立刻发送的信息记录在一个库中时,消息分配单元47将其通知给消息传送单元48,并且能执行消息传送处理。
如果以这种方式处理,当记录命令时,可以立刻发送给目的地。
如上所述,通过执行与图39和图40中示出的消息传送相关的处理,集中地将应该被发送的操作请求和操作响应发送到与两个或者更多目的地中的每个相关的目的地。
应该发送到图像处理装置100中的操作请求和操作响应能够从目的地集中地接收,并且每个能够以可发送的状态独立地存储到图像处理装置100。
仅仅在图39和图40中所示的情况中或者在图41的流程图中所示出的,能够处理来自图像处理设备100的命令,执行除了这样的处理的替代处理也被考虑。
与图38的情况类似,CUP在传送服务器102的启动时开始该处理。在该处理中,确定是否存在任一描述用于首先发送的传送消息库51命令的传送消息表单(S91),如果没有,它就待命,直到它发现这样传送消息表单。
当在步骤S91发现描述命令的传送消息表单时,其中的一个被作成处理对象,并且传送消息表单上指示的“X-Received-From”报头的内容被存储(S92)。
根据对象表单上的“目的地信息”,描述对象表但上指示的传送消息(SOAP请求)的HTTP请求被发送到目的地(S93)。
当产生传送消息时,将需要的HTTP报头给予记录在“消息的XML数据”项目中的SOAP信包,这是必要的。此时,可以使用记录在“实体报头信息”项目中的实体报头信息。
然后,从目的地接收到发送的HTTP请求的HTTP响应(S94)。为此,发送的SOAP请求的SOAP响应应该被表示。
然后,在用于接收的传送信息库52中创建传送消息表单并且指示接收的HTTP响应的SOAP消息的内容被记录在创建的传送消息表单中(S95)。
将SOAP信包的部分按原样记录到“消息的XML数据”项目中是必要的,只是将HTTP报头中需要的部分记录到与该记录相关的“实体报头信息”的项目中。创建的传送信息表单的“实体报头信息”的“响应”作为“X-SOAP-Type”报头和它的内容。
“X-Send-To”报头被附加并且在步骤S92存储的“X-Received-From”报头的内容被表示在此(S96)。处理返回到步骤S91并且重复。
记录的命令响应能够从命令的目的地中得到,通过上面的处理,类似于通过图39和图40的处理来记录的情况,内容能够记录到用于接收的传送消息库52中,并且能够通过消息收集单元45收集,也能够发送到图像处理设备100。
如果执行这样的处理,即使当目的地设备不支持图39中示出的批发送时,命令也能够被发送和处理。
当一个命令被记录时,也能够被立即发送到目的地。上述对传送服务器102中处理的每个命令和命令响应所涉及的传送处理的解释结束。
接下来,将解释用于处理到图像处理设备100侧的命令和命令响应的功能组成。这已经使用图9硬件说明过了。
图42示出了功能组合,该功能组合用于处理与在图3的图像处理设备100的多个功能中的处理有关的命令和命令响应。
终端命令库141和服务器侧命令库142在存储单元中建立,该存储单元能够重写图42所示的功能中的任一功能。
例如,尽管它可以在NVRAM207中提供,它也可以在SDRAM203中或者HDD210中提供。
终端命令创建单元143、服务器侧命令执行结果创建单元144、消息收集单元145以及消息分配单元147的功能都由CPU201来实现。HTTP客户功能模块146的功能由CPU201和PHY206来实现。
即使命令的源节点是传送服务器102并且图像处理设备100中是服务器103,由于要执行通公共处理,因此在图像处理设备100的解释中,上面所提到的传送服务器命令和服务器命令将被总体称为“服务器侧命令”。这些功能将会进一步解释。
首先,终端命令库141是关联和记录了终端命令、该命令的响应以及该命令的识别信息的库。
服务器侧命令库142是关联和记录服务器侧命令、该命令的响应以及该命令的识别信息的库。通过为每个命令创建表格式的命令表单并存储该信息,在这种库中试图将命令和包括识别信息的信息、响应等等进行关联。
终端命令创建单元143对应于请求创建单元。它创建终端命令并且识别该命令的识别信息(ID)被分配。用于管理该命令的管理信息被附加,其具有关联这些信息的功能,并作为表格式的终端命令表单记录在终端命令库141中。
其中,配备具有应用程序的图像处理识别100,例如相当于创建终端命令的部分。
可以提供一种功能,对于创建的终端命令,该功能在使得终端命令创建单元143执行目的地中的每个命令时,赋予优先级。
图43中示出了图3的图像处理设备100中的终端命令表单的数据结构的例子。
如图43所示,在图像处理设备100中,在终端命令表单中提供存储“命令ID”、“方法名称”、“输入参数”、“状态”、“命令执行结果的通知节点”和“输出参数”的数据的区域。
在这些项目中,“命令ID”、“方法名字”和“输入参数”对应于终端命令(和附加其上的ID),“状态”和“命令执行结果的通知节点”相当于管理信息。“输出参数”是从执行关于命令的处理的设备返回的命令响应的内容。
对于每个项目的内容,它与传送服务器102中的终端命令表单或者传送服务器命令表单中的相同名字的项目内容是相同的,其描述将被省略。
因为没有必要识别是否由哪个设备发送和处理,所以在此之后,如果终端命令被发送到传送服务器102,图像处理设备100不建立“目的地信息”项目。
参考图42,服务器侧命令执行结果创建单元144对应于响应创建单元。
应用程序从服务器侧命令库142读取和执行服务器侧命令。对服务器侧命令的响应被创建,并且具有与服务器侧命令的命令ID相关联的功能,以及被记录在服务器侧命令库142中。
从传送设备102接收的服务器侧命令与管理识别该命令的ID的管理信息相关联,该命令作为表格式的服务器侧命令表单记录到服务器侧命令库142。
服务器侧命令执行结果创建单元144创建的命令响应也被记录在与执行的服务器侧命令相关的服务器侧命令表单中。
两种或者更多种的服务器侧命令被从服务器侧命令库142读取到服务器侧命令执行结果创建单元144,并且能够提供时每个服务器侧命令创建响应的功能。
当它包括与通过图像处理设备100为具有优先级的服务器侧命令分配优先级并且执行处理的信息时,也考虑执行提供优先从优先级高的对象读取的功能。
服务器侧命令执行结果创建单元144可以是不调用应用程序本身而是调用执行服务器侧命令所需要的应用程序的模块,并且执行命令。
图44中示出了图3的图像处理设备100中的服务器侧命令表单的数据结构的例子。
如图44所示,在图像处理设备100中,在服务器侧命令表单中提供存储“命令ID”、“方法名字”、“输入参数”、“状态”、“输出参数”和“命令的通知节点”的数据的区域。
在这些项目中,“命令ID”、“方法名称”和“输入参数”对应于服务器侧命令(和附加其上的ID),“状态”和“命令的通知节点”对应于管理信息。“输出参数”是服务器侧命令的执行结果,作为图像处理设备100返回的命令响应的内容。
对于每个项目的内容,传送服务器102中的传送服务器命令表单或者终端命令表单的相同名字的项目的内容是相同的,其描述将被省略。
因为不必识别它传送到哪个设备,在此之后,如果服务器侧命令的响应被传送到传送服务器102,图像处理设备100不建立“发送源信息”的项目。
返回参考图42,消息收集单元145对应于收集单元。与服务器侧命令执行结果创建单元144创建的命令响应相对应的服务器侧命令的关联命令ID以及该命令响应都从服务器侧命令库142中读出。
终端命令创建单元143创建的终端命令的命令ID和该命令是关联的,它从终端命令库141中读出,并且具有从中创建输出消息的功能。
当分配优先级指定给命令响应或者终端命令时,相应地,使得消息收集单元145从分配优先级高的对象中顺序地读取是可能的。关于输出消息的进入格式或者产生系统,与解释传送服务器102的内容是相同。
HTTP客户功能模块146具有发送HTTP请求的HTTP请求发送单元146a以及接收HTTP响应的HTTP响应接收单元146b。
HTTP请求发送单元146a对应于发送单元,创建包含消息收集单元145创建的输出消息的HTTP请求,并且具有发送到传送服务器102的功能。
一个HTTP请求中可以包括输出消息,并且此时涉及命令响应的输出消息以及涉及终端命令的输出消息也可以被任意混合。
然后,不存在HTTP请求发送单元146a,它包括消息收集单元145在一个HTTP请求中创建的所有输出消息,并且试图涉及并且发送任一输出信息。
然而,提供最大数量的包括在HTTP请求中的输出消息也被考虑。
顺便提起,当消息收集单元145试图读出终端命令、命令响应等时,该HTTP请求的发送没有数据读取,当应该发送的SOAP消息作为结果却没有被创建时,它被执行。该读出的试验将被周期性执行。
例如,通过定时器能每60分钟读取。这样做是因为除了从图像处理设备100请求通信以外,即使如上所述信息将从传送服务器102发送到图像处理设备100,不能够进行发送。
通过给出机会来周期性地发送通信请求给传送服务器102,即使没有数据从图像处理设备100发送,也从传送服务器102发送信息给图像处理设备100。传送需要的信息持续较长一段时间并且在传送服务器102上停滞是可以阻止的。
当然,消息收集单元145的读出以及其后的HTTP请求发送单元146a的HTTP请求的发送将在除周期定时之外的时间适当地执行。
例如,当即将被发送的信息记录在一个库中时,通过通知,终端命令创建单元143或者服务器侧命令执行结果创建单元144可以使其读取到消息收集单元145。
HTTP响应接收器单元146b对应于接收器单元,具有从传送服务器102接收HTTP响应的功能。
包含在涉及服务器侧命令和它的命令的HTTP响应命令ID中的接收消息、对终端命令和它的命令的响应、以及包含与命令ID关联的接收消息被任意混合,并被包含。
关于已接收消息的进入格式,与解释传送服务器102的内容格式是相同的。
消息分配单元147对应于分配单元。它具有将数据分配并且记录在终端命令库141和服务器侧命令库142中的功能,所述数据包含在HTTP响应接收器单元146a接收的HTTP响应中。特别地,服务器侧命令表单形成在服务器侧命令库142中,服务器侧命令和它的关联命令ID都记录在那里。
与终端命令表单的命令ID进行比较并且与终端命令的关联响应对应的终端命令被指定,其中所述终端命令表单存储了与终端命令库141的命令所关联的命令ID。它将被记录为与终端命令关联的“输出参数”。
同样,对于数据转换系统,在该记录的情况下,与解释传送服务器102的内容相同。
接下来,由具有上面说明过的组合和功能的图像处理设备100执行的处理将使用图45到图47的流程图来说明。
当图像处理设备100的CPU201执行必要控制程序时,在这些流程图中示出的处理被执行。
首先在图45中示出了消息收集的流程图以及分配处理的基本流程。
如果消息收集单元145变成试图读出终端命令、命令响应等的定时,CPU201将开始在图45的流程图中示出的处理。
首先执行终端命令的收集处理(S111)。该处理是收集应该从终端命令库141发送到传送服务器102的终端命令的处理,并且包括由SOAP信包从收集的数据中创建部分的处理。
接下来,执行作为服务器侧命令的响应的服务器侧命令执行结果的收集处理(S112)。该处理是收集应该从服务器侧命令库142发送到传送服务器102的服务器侧命令的处理,并且也包括由SOAP信包从收集的数据中创建部分的处理。
然后,由步骤S111和S112的处理创建的部分被合并成一个,包括所有部分的HTTP请求被创建(S113),并且该HTTP请求被发送到传送服务器102(S114)。
在到此为止的处理中,在步骤S111和S112,CPU201作为消息收集单元145,并且在步骤S113和S114,作为HTTP请求发送单元146a。
接下来,从传送服务器102接收到作为对HTTP请求的通信响应的HTTP响应(S115)。接收的HTTP响应的HTTP主体被分成每个部分(S116)。
分成的每个部分划分为由“MIME边界”分类的元素,并且对于所有部分来划分。
然后,步骤S117到S119的处理对于所有被划分的部分重复并依次得到对象。在该处理中,目标部分首先确定是否是描述终端命令的响应的部分(S117)。
如果是终端命令的响应,响应的通知处理将被执行(S118)。当不是终端命令的响应时,因为它是由服务器侧命令指示的部分,服务器侧命令记录处理被执行(S119)。
在步骤S118或者S119被执行后,控制返回到步骤S117,处理对于下一部分重复。
当对于所有部分执行了这些处理时,图45的流程图示出的处理结束。
在到目前为止的处理中,在步骤S115和S116,CPU201作为HTTP响应接收单元146b,在步骤S117到S119,它作为消息分配单元147。
接下来,图45示出了由图3的图像处理设备100执行的消息收集和分布式处理的基本流程。
图46是用于说明直到图45的基本流程的步骤S114的处理的流程图。
在处理中,CPU201从终端命令库141中收集终端命令表单的“状态”和“方法名称”、作为应该发送终端命令而“没有发送的”“输入参数”的内容、以及“命令ID”的内容也收集作为命令的命令ID(S121)。
因为在命令由终端命令创建单元143创建后,“未发送”的“状态”示出了还没有通知给传送服务器102的内容,在此基础上能够提取应该发送到传送服务器102的命令。
然后,通过将在步骤S121收集的所有终端命令作为目标,步骤S122到S124的处理连续地重复。
在这些处理中,首先是将分别包含在SOAP主体和SOAP报头中的包括目标的终端命令和它的命令ID等这些信息变换为SOAP信包(S122),并且将它们附加到实体头标上,来创建与目标命令相关的部分(S123)。
目标终端命令被指示处的终端命令表单的“状态”改变成“等候响应”(S124)。“等候响应”的状态指示到传送服务器102的命令通知完成了。
在对于所有收集的命令的处理完成时,CPU201从服务器侧命令库142收集状态为“处理完成”的服务器侧命令表单的“输出参数”的内容,也收集作为对应服务器侧命令的命令ID的“命令ID”的内容(S125)。
“处理完成”的状态指示对应于服务器侧命令的处理由服务器侧命令执行结果创建单元144执行,但是到传送服务器102通知还没有执行。因此,应该发送到传送服务器102的命令响应能够在此基础上提取。
然后,通过将在步骤S125收集的所有终端响应作为目标,步骤S126到S128的处理被连续地重复。在处理中,命令ID与目标命令响应和它的目标响应一起来收集。
信息是变为包含在SOAP主体和SOAP报头中的SOAP封包(S126),对此增加实体报头,并且创建与目标命令响应相关的部分的处理(S127)。除了对象不同,这些处理与步骤S122和S123的处理是相同的。
下面,目标命令响应被指示的服务器侧命令表单的“状态”被变为“响应完成”(S128)。
“响应完成”这样的“状态”示出已经完成将命令响应发送到传送服务器102。
在到此为止的所有处理都被完成时,CPU201合并由步骤S123或者S127创建的每个部分,创建如图16所示的多个部分的HTTP请求,并且发送到发送服务器102(S129)。
在该发送实际地完成后,可以由步骤S124或者S128在实施处做出“状态”的改变。
因为甚至在出现通信错误的时候,将要被发送的命令和命令响应能够再次作为发送的对象来设置,通过这样,系统的稳定性提高了。
上面对于HTTP请求的发送的处理结束了,将进行图45的步骤S115之后相应处理。
图47是用于解释图45的步骤S115之后的部分的处理流程图。
图46的步骤S129接下来的处理与图47的步骤S131一致。
在该处理中,首先CPU201等待针对已发送的HTTP请求的HTTP响应的接收,并从传送服务器102对此进行接收。
如果其被接收,该HTTP主体将被分析并且将被分成每个部分(S132)。
在这之后,将被划分而得到的每个部分依次作为目标,反复进行步骤S133到S142的处理。
在这部分的处理中,首先确定目标部分是否是对终端命令的响应(S133)。因为如上所述,针对服务器侧命令和终端命令的响应有可能包括在HTTP响应中,所以对目标部分是其中的哪一个进行确定。
根据“SOAP ACTION”报头是否存在于目标部分中以及根据“X-SOAP-Type”报头的内容,能够进行判断。
在步骤S133,如果是终端命令的响应,将执行与步骤S134到S137的响应的记录相关的处理。
即,它首先变成分析该部分的SOAP信包形式的数据,并且能够被记录在终端命令表单中(S134)。
从终端命令库141中查找与终端响应对应的终端命令,并且命令响应的数据被记录到与终端命令关联的终端命令表单的“输出参数”的项目中(S135)。
与在终端命令发送的时候附加的“命令ID”信息相同的命令ID将被给子命令响应,对于终端命令的搜索,该信息能够作为关键字来执行。
在数据的记录完成后,数据被记录的终端命令表单的“状态”被变成“响应接收完成”,并且示出(S136).
并且报告记录在“命令执行结果的通知节点”中的通知节点具有响应(S137)。
通过该通知,可以识别出创建终端命令的应用程序具有由于创建的命令的响应,与响应相对应的处理能够被执行。例如,当发出错误消息的应用程序创建意味着错误信息被执行的终端命令时,如果这一命令被发送到传送服务器102,则传送服务器102将返回意味着它已被正确接收的命令响应。
在图像处理设备100侧,如果接收到该命令响应,则搜索基于包含在此的命令ID对哪一个终端命令进行响应,并且将其与找到的终端命令相对应,并且记录该命令响应。
并且将具有响应的内容报告给作为该命令的执行结果通知目的地而被记录并发出错误消息的应用程序。
如果终端命令表单涉及什么时候接收该通知,那么应用程序能够从“输出参数”的项目中获得创建的命令的执行结果。
在以上的步骤S137的处理完成后,如果存在下一个部分,为此处理将从步骤S133重复。
另一方面,如果在步骤S133没有终端命令的响应,因为该部分是涉及服务器侧命令的部分,所以将在步骤S138到S142执行与命令的记录有关的处理。
也就是说,它首先变成分析该部分的SOAP信包的格式的数据,并且能够被记录在服务器侧命令表单中(S138)。
用于记录服务器侧命令的服务器侧命令表单在服务器例命令库142中创建(S139),并且服务器侧命令和命令ID都记录在服务器侧命令表单中(S140)。
服务器侧命令的内容记录在服务器侧命令表单的“方法名称”和“输入参数”的项目中,由所述部分指示的命令ID记录在“命令ID”的项目中。“状态”的初始值是“未处理”并且“输出参数”的初始值是NULL。
在上面项目的记录完成后,通过参考在方法和处理程序(hundler)间定义通信的预定通信信息,能够搜索用于执行存储在服务器侧命令表单的“方法名称”中的方法的处理程序(包含在服务器侧命令执行结果创建单元144中)的参考信息(S141)。发现的参考信息记录在服务器侧命令表单的“命令的通知节点”项目中(S142).
直到以上的步骤142处理完成后,如果存在下一个部分,为此处理将从步骤S133重复。步骤S133到S142的处理对于所有部分都完成后,图47的流程图示出的处理结束。
通过执行上面的处理,图像处理设备100能够集中地将应该发送到传送服务器102的操作请求的操作响应以及从传送服务器102接收的操作请求发送到传送服务器102。
来自传送服务器102或者服务器103的操作请求的操作响应以及发送到传送限务器102的操作请求能够被集中地从传送服务器102接收和处理。
这里说明了进行在产生所有应被发送的部分之后将其合并的处理,还说明了进行在接收了所有的部分之后将其分成每个部分这样的处理,但没有必要这样做。
与传送服务器102的情况相同,无论何时一个接一个地发送,无论何时创建每个部分或者接收每个部分,它都一个接一个的执行关于每个部分的处理。
与执行服务器侧命令表单所关联的服务器侧命令有关的处理一样,执行使用图37或者图38说明的与传送服务器102相关的处理是必要的。
顺便,对于图像处理设备100创建的操作请求,如果暂时发送到传送服务器102,传送服务器102将发送到合适的目的地(服务器103级),并且将从那里获得和返回操作响应。
因此,对于图像处理设备100,即使它处理传送服务器102正在执行与所有操作请求有关的发送和接收,它也不会干扰。
同样对于图像处理设备100接收的操作请求,在没有掌握哪个设备真正地创建的情况下,它从传送服务器102接收,操作请求也返回到传送服务器102。
因此,对于图像处理设备100,即使它处理传送服务器102正在产生所有操作请求的发送和接收,它也不会干扰。
结束了对图像处理设备100中执行的每个命令和命令响应的传送相关的处理的解释。
接下来,将说明用于处理到服务器103侧的命令和命令响应的功能组成。
使用图10已经解释过硬件。
图48是示出了用于执行服务器103的功能中的命令和命令响应所涉及的处理的功能的细成的框图。
当服务器103的CPU301执行必要的控制程序并且控制服务器103每个部分的操作时,图48中示出的每个功能被实现。
服务器命令库241和终端命令库242都在存储单元中建立,其中在这些功能中象RAM303那样的重写是可能的。
服务器命令创建单元243、终端命令执行结果创建单元244、消息收集单元245以及消息分散单元247的功能都由CPU301来实现。
HTTP服务器功能模块246的功能由CPU301和NIC305来实现。路径信息存储单元250由非易失性存储单元构成,其中象SD卡304那样的重写是可能的。图48示出的每个单元的功能将进一步说明。
终端命令库241是使得服务器命令与该命令的响应、该命令的识别信息、命令的目的地、发送代理的信息等等进行关联的库,并且记录它。
终端命令库242是使得终端命令与该命令的响应、该命令的识别信息、命令的目的地、发送方的信息等进行关联并对其进行记录的库。处理服务器命令创建单元243对应于请求创建单元,并创建处理服务器命令及分配对命令进行识别的识别信息(ID)。
用于管理命令和命令的目的地信息的管理信息被附加,它具有关联这些信息的功能,并且作为表格式的服务器命令表单记录在服务器命令库241中。
其中,服务器103装配的应用程序例如对应于创建服务器命令的部分。
服务器103的服务器命令表单中的数据结构与图13中示出的传送服务器102的传送服务器命令表单中的数据结构相同。
服务器命令创建单元243不但将最后的目的地作为目的地信息记录入服务器命令表单,而且将它直到发送到目的地的路径信息也记录入服务器命令表单。
该路径信息是可以从路径信息存储单元250中获得的。也就是说,因为路径信息存储单元250产生命令的目的地(或其它信息),因此在发送命令到相应目的地时的路径信息作为路径信息表存储。
通过使用最后目的地作为关键字来搜索该路径信息表,直到发送到那个目的地的路径信息可获得。
该路径信息表的例子在图49中示出。该例子示出记录着4个图像处理设备的表。
尽管仅仅通过与图像处理设备A和B有关的传送服务器102发送命令所必需的信息被记录了,对于图像处理设备C和D,意指未知路径的信息也被记录了。
在操作者基于用户记录明信片等上的信息输入终端单元ID后,当从终端单元发送的信息不是曾经接收的时候,这里考虑了不从服务器103侧要求终端单元通信的系统结构。
不管它是否具有经由哪个传送服务器102发送到终端单元的命令,因为它不能识别,所以可能出现路径信息是未知的状态。
路径信息表上的信息能够根据指示服务器103接收的HTTP请求的消息的信息来自动更新,从而它可以稍后被提到,并且服务器103的操作者也可以手动输入它。
尽管也能够记录经由两个或者更多传送服务器发送的传送路径,但它承认一种路径并试图将它与一个终端单元关联记录。
回头参考图48,终端命令执行结果创建单元244对应于响应创建单元。由应用程序从终端命令库242中读出和执行终端命令。
终端命令的响应被创建,并具有与终端命令的命令ID关联的功能,以及被记录在终端命令库242中。终端命令从传送服务器102中接收。
用于管理识别该命令的ID的发送源信息(它变成命令响应的目的地信息)的管理信息与它是关联的,并且该命令作为表格式的终端命令表单记录在终端命令库242中。
终端命令执行结果创建单元244创建的终端响应也记录在与执行的终端命令相关的终端命令表单中。
两种或更多类型的终端命令从终端命令库242中读出到终端命令执行结果创建单元244中,并且提供对每个终端命令创建响应的功能是可能的。
终端命令执行结果创建单元244是这样的模块,它不调用应用程序本身,而且调用执行终端命令所需要的应用程序,并且执行命令。
服务器103的终端命令表单中的数据结构与图12示出的传送服务器102的终端命令表单中的数据结构是相同的。
接下来,消息收集单元245对应于收集单元。将与终端命令执行结果创建单元244创建的命令响应和与该命令响应对应的终端命令的命令ID及发送源信息相关联,并从终端命令库242中读出。
服务器命令创建单元243创建的服务器命令的命令ID和目的地信息以及该命令是关联的,并且它从服务器命令库241中读出,以及具有从中创建输出消息的功能。
对于输出消息的进入格式(entry format)或者产生系统,这与解释传送服务器102的内容是相同的。
HTTP服务器功能模块246提供了发送HTTP响应的HTTP响应发送单元246a,接收HTTP请求的HTTP请求接收单元246b,以及HTTP响应发送单元246a。它对应于发送单元,包含消息收集单元245创建的输出消息的HTTP响应作为对从传送服务器102接收的HTTP请求的通信响应而创建,并且它具有向传送服务器102发送的功能。
输出消息可以包括在几个HTTP响应中,也可以将涉及命令响应的输出消息和涉及处理服务器命令的发送消息任意混合。
当然,也能够混合目的地不同的发送消息。
不存在HTTP响应发送单元246a,它包括消息收集单元245在一个HTTP响应中创建的所有输出消息,对于这些,它试图涉及任何有关的输出消息并且发送。
然而,也考虑提供在一个HTTP响应中包含最大数量的输出消息。
顺便,当消息收集单元245试图读出服务器命令和命令响应等的时候,HTTP响应的发送不具有读取的数据,并且当应该作为结果发送的SOAP消息没有被创建时,这被执行。
当来自传送服务器102的HTTP请求被接收时,执行该读出的试验。即使在除此情况之外的其它情况下试图读出,因为处理服务器103不具有HTTP客户功能部,所以其自身不能发送HTTP请求并且不能将发送消息发送到传送服务器102。
HTTP请求接收单元246b对应于接收单元,具有从传送服务器102接收HTTP请求的功能。
包括终端命令、关联的命令ID、和HTTP请求中的传送路径信息、包括服务器命令的响应的接收消息和它的命令、关联的命令ID和传送路径信息的已接收消息被任意混合和被包含。
对于接收消息的进入格式,其与解释传送服务器102的内容的格式相同。消息分配单元247对应于分配单元,能够将数据分配和记录在服务器命令库241和终端命令库242中,所述数据包含在由HTTP请求接收单元246b接收的HTTP请求中。
特别地,终端命令表单形成在终端命令库242中,并且记录与响应于服务器命令的终端命令相关的命令的命令ID和传送路径信息(记录为发送源信息)。
将与该响应所关联的命令ID与处理服务器命令库241中存储的处理服务器命令表单的命令ID对照并且对对应的处理服务器命令表单进行指定,并记录该处理服务器命令表单的“输出参数”的项目。
在该记录的情况下涉及的数据转换系统与解释传送服务器102的内容的数据转换系统相同。
接下来,将解释由服务器103执行的处理,所述服务器具有上面解释过的组成和功能。
尽管涉及传送服务器间的消息的发送和接收相关的基本流的流程图在图50中示出,当服务器103的CPU301执行必要的控制程序时,执行在该流程图中示出的处理。
如果HTTP请求从传送服务器102发送,CPU301将开始图50的流程图中示出的处理。HTTP请求首先被接收到(S211)。
接收的HTTP请求的HTTP主体被分成每个部分(S212)。这里,划分成每个部分是划分成由“MIME边界线”分类的元素,并且对于所有的部分来划分。
然后,对于按顺序被划分并作为对象的所有部分重复步骤SY和S213到S215的处理。
在该处理中,执行首先在图49中示出的用于更新路径信息表的路径信息表更新处理,目标部分确定其是否是描述服务器命令(SY)的响应和等级的部分(S213)。
如果是服务器命令的响应,将执行响应的通知处理(S214)。当不是服务器命令的响应时,由于它是由终端命令指示的部分,所以执行终端命令记录处理(S215)。
步骤S214或S215执行后,控制转回到步骤S213,对于下一部分重复该处理。
当对于所有部分执行这些处理时,进行到下面的步骤S216。
在到此为止的处理中,在步骤S211和S212,CUP301作为HTTP请求接收单元246b,在步骤S213到S215它作为信息分配单元247。
接下来,CPU301执行服务器命令的收集处理(S216)。该处理是从服务器命令库241收集应该发送到传送服务器102的服务器命令的处理,并且包括从收集的数据中、通过SOAP信包创建该部分的处理。
接下来,执行作为终端命令的响应的终端命令执行结果的收集处理(S217)。该处理是从终端命令库242收集应该发送到传送服务器102的命令响应的处理,并且还包括从收集的数据中由SOAP信包创建所述部分的处理。
然后,由步骤S216到S217的处理创建的部分混合成一个。包括所有部分的HTTP响应被创建(S218),HTTP响应被发送到传送服务器102作为对在步骤S211接收的HTTP请求的通信响应,并且处理(S219)结束。
在到此为止的处理中,在步骤S216和S217,CUP301作为消息收集单元245,它在步骤S218和S219作为HTTP响应发送单元246a。
接下来,图50的流程图示出的处理将使用详细示出的流程图从每个部分进行说明。
图51是用于说明图50的基本流程中直到步骤S215的处理的流程图。
在该处理中,CPU301首先从传送服务器102接收HTTP请求(S221)。如果接收到请求,HTTP主体将被分析并且将划分成每个部分(S222)。
然后,步骤SY和步骤S233到步骤S232的处理通过将划分和得到的每个部分作为目标来连续重复。对于这些处理,步骤SY稍后提到。
对于步骤S223到步骤S232,几乎与使用和图像处理设备100有关的图47解释的步骤S133到步骤S142的处理相同。
而且,基本上说,在图47的处理过程中曾经是终端命令的而在这里却是处理服务器命令,曾经是处理服务器命令而在这里却是终端命令,随之只是命令表单的名称不同。其它的不同点仅为:在步骤S230中,从记载了终端命令的部分的实体的头标中提取与传送路径有关的信息(“X-Received-from”头标的内容),用发送源信息”项目记录,和将HTTP请求的源节点的信息作为最近的传送路径的信息记录到相同的项目栏中
在步骤SY和步骤S223到步骤S232的处理对于所有部分都完成后,处理结束,图51的流程图中示出的处理进行到对应于图50的步骤S216以后的处理。
图52是用于说明图50的基本流程中步骤S216和随后步骤的处理的流程图。
图51中步骤S227或者S232的步骤之后的处理对应于图52的步骤S241的处理。
在该处理中,CUP301首先从处理服务器命令库241中将相当于最近的目的地在步骤S211接收的HTTP请求的源节点、以及该“状态”为“未发送”的处理服务器命令表单的“方法名称”和“输入参数”的内容作为应该发送的服务器命令来收集,并且也将“命令ID”的内容作为该命令的命令ID来收集(S241)。
由于参考路径信息表来将与命令的传送有关的的路径信息记录到“目的地信息”,所以能够识别出记载了来自服务器103的作为直接发送的目标的HTTP请求的源节点信息的表格是记载了记录在针对该HTTP请求的HTTP响应中并应当发送的命令的表格。
由于“未发送”的“状态”示出在由服务器命令创建单元243创建命令后,还没有通知给传送服务器102,在此基础上,能够提取出应该发送到传送服务器102的命令。
然后,通过将在步骤S241收集的所有服务器命令作为目标,步骤S242到S244的处理连续地重复。
在处理中,目标服务器命令和它的目标命令ID相应地转变成包含在SOAP主体和SOAP报头中的SOAP信包(S242),信息对其增加实体报头,并且创建关于目标命令的部分(S243)。
在步骤S243,关于实体报头的“目的地信息”的上述“X-SEND-TO”报头指示传送路径的信息。此时,因为它不是必需的,将要发送HTTP响应的目标的信息从现在开始不再指示。
所指示的目标服务器命令的服务器命令表单的“状态”变成“等待响应”(S244)。调用“等待响应”的“状态”示出,在传送服务器102对于命令是固定发送的。
这些全部结束后,CPU301从终端命令库S242中将相当于在步骤S211接收的最近目的地的HTTP请求的源节点、并且。“状态”是“处理完成”的终端命令表单的“输出参数”的内容,作为针对终端命令的命令响应中应该发送的内容来收集,,还将“命令ID”的内容作为相应的终端命令的命令ID来收集(S245)。
由于将当接收到终端命令时涉及传送的路径信息记录到“发送源信息”中,所以能够识别出记载了来自服务器103的作为直接发送的目标的HTTP请求的源节点信息的表格是记载了记录在针对该HTTP请求的HTTP响应中并应当发送的命令的表格。
并且,“处理完成”这样的“状态”是在终端命令执行结果创建单元244创建对应于终端命令的处理后,并表示还没有发送到传送服务器102,因此在此基础上可以提取应该发送到传送服务器102的命令响应。
然后,通过将在步骤S245收集的所有命令响应作为目标,步骤S246到S248的处理连续地重复。在该处理中,使用目标命令响应和它的目标响应来收集命令ID。
它相应地变成包含在SOAP主体和SOAP报头中的SOAP信包(S246),这些信息为其附加实体报头,并且创建有关目标命令的部分(S247)。
在步骤S247,参考实体报头的“发送源信息”的上面提到的“X-Send-To”报头指示传送路径的信息。
此时,因为它不是必需的,将要发送HTTP响应的对象的信息从现在开始不被指示。也就是说,“X-Send-To”报头的内容将仅仅预示着当相应终端命令被接收到时,它与指示的“X-Received-From”报头的内容一致。
下面,表示目标命令响应的终端命令表单的“状态”变成“响应完成”(S248)。
“响应完成”这样的“状态”示出已经完成将命令响应发送到传送服务器102。
所有处理都完成之后,CPU301将由步骤S243或者S247创建的每个部分混合,并且创建多部分的HTTP响应,它作为对接收的HTTP请求的响应发送到传送服务器102(S249)。
该发送真正完成后,可以使得由步骤S244或者S248实施的“状态”发生改变。
即使这样作产生通信错误,由于将要发送的命令和命令响应能够再次设置为发送对象,所以系统的稳定性增加了。
接下来,图53是用于解释象图50等示出来进行路径信息表更新处理。
在该处理中,CPU301首先确定候选部分是否具有“X-Received-From”头标,也就是说,路径信息是否被记载在实体头标中(S251)。
如果有“X-Received-From”报头,顶端“X-Received-From”报头的值将被获得作为根据候选部分的发送源信息。在剩余的“X-Received-From”报头的值和图50的步骤S211处的作为路径信息接收的HTTP请求的发送源信息被获得(S252)。
在另一方面,如果没有“X-Received-From”报头,HTTP请求的发送源信息将被获得作为候选部分的发送源信息,并且将存储为没有路径信息(S253)。
在任一情况下,确定发送候选部分源(part origin)是否记录在路径信息表中(S254)。
如果记录了,将确定路径信息是否与记录的内容一致(S255)。如果一致,将不必改变路径信息表的内容,所以图53的处理结束,返回到起始处理。
当在步骤S254没有记录时,由步骤S252或者S253获得的路径信息被记录为路径信息,其将发送源信息记录到路径信息表中作为终端单元ID,并且重新将发送部分源与应该记录的路径信息表相对应。
当在步骤S255不一致时,与发送代理的终端单元ID相关的路径信息被转换到由步骤S252或者S253获得的路径信息,并且路径信息被更新。
这也包括源路径信息是未知的情况。为了使得路径信息的更新内容反应在步骤S256或者S257之后的已记录在库中的命令表单,目的地和源节点(不包括中间传送路径)从服务器命令库241和终端命令库中提取一致作为发送候选部分源(由步骤S252或者S253获得的发送源信息)的命令表单(S258)。
在通过一个接一个将所有被提取的表单作为目标而执行改变以后,根据路径信息表格的内容,处理替换了对象表单的目的地信息或者发送源信息(S259)。
此时,所替换的只是传送路径,并没有改变最后目的地的源节点或者命令。
上述所有处理都完成后,图53的流程图中示出的处理结束,返回到原始处理。
通过使用图50到图53执行上面解释的处理,服务器103能够集中地将应该发送到各种图像处理设备100的操作请求的操作响应和从图像处理设备100接收到的操作请求发送到传送服务器102。
来自图像处理设备100的操作请求的操作响应以及发送到图像处理设备100的操作请求都能够集中地从传送服务器102接收和处理。
即使当不从服务器103发送通信请求时,操作请求和操作响应能够移交到协调对图像处理设备100的通信的合适的传送服务器102。
这里说明了进行在产生所有应被发送的部分之后将其合并的处理,还说明了进行在接收了所有的部分之后将其分成每个部分这样的处理,但没有必要这样做。
与传送服务器102的情况相同,既在每当创建每个部分时依次发送,也在每当接收每个部分依次进行执行与每个部分有关的处理。
与图像设备命令的执行有关的处理一样,执行与传送服务器102有关的图37和图38解释的处理作为与图像设备命令相关的处理是必要的,这是必要的。
对于在服务器103中执行的每个命令和命令响应的处理的解释结束了。
当图像处理设备100创建将由服务器103执行的终端命令并且接收终端命令的响应时,图54示出了由图3的远程管理系统的相应元件执行的处理。
当服务器103创建发送到图像处理设备100的服务器命令并接收到服务器命令的响应时,图55示出了由图3的远程管理系统的相应元件执行的处理。
在这些附图中,示出的处理与前面描述的相应处理相同,其详细描述将被省略。
在上面解释的远程管理系统中,通过执行这样的处理,能够由传送服务器102来对处理服务器103和图像处理设备100间的命令及命令响应的发送和接收进行协调。
通过形成传送服务器102并且经由该传送服务器102执行图像处理设备100和服务器103间的通信,即使在图像处理设备100没有识别服务器103的存在并且没有识别出命令和命令响应是否是应该最后被发送到哪个设备,图像处理设备100发送的命令和命令响应也能够被发送到合适的目的地。
这是因为传送服务器102根据分类指定合适的目的地,并且试图发送从图像处理设备100接收的命令和命令响应。
图像处理设备100中的目的地信息管理的负担能够被减少,其中图像处理设备100是安装在客户侧环境中的终端单元。也就是,当改变传送服务器102和服务器103在功能提供侧提供的服务组成时,对于命令和命令响应的传送路径的改变,可以仅仅通过改变传送服务器102存储的目的地表的内容来响应。
也就是,因为能够仅仅通过服务提供侧的维护来进行响应,目的地信息管理是十分容易的。
尽管经常执行命令划分成组并且分等级来进行管理,即使当对于每个组和命令定义类别和目的地间的相应关系在同一组内是增加或者删除,也不必改变目的地表。
因此,传送服务器102中的目的地信息的管理负担也能够减少。因为同一组中的命令通常使用相同应用程序来处理,因此特殊问题在考虑目的地时同样不会出现。
如果命令和命令响应象SOAP请求和SOAP响应那样表示,由于通过XML标准化的数据能够被发送和接收,因此发送和接收的数据是有效可循环的。
也就是,接收的数据能够记录在公司内部系统中,或者自动创建使用例如XSLT(XML格式片语言转换)的技术显示接收的数据的主页的处理能够被轻易地执行。
在SOAP消息中,尽管定义标签的名称空间是经常执行的,如果对于有关命令和命令响应的标签的名称空间来说目的地被指定,那么目的地的管理再次变得容易。
在这种情况下,在关于目的地规约的名称空间和关于名称空间前缀的定义的名称空间方面,分类的精细度不必是相同的。
通过采用构造成远程管理系统的每个设备中的上面已说明过的结构,在每个设备间既没有应该发送和接收的操作请求,操作响应也不依赖于任一操作请求或者它们是的操作响应,或者能够集中地发送和接收的最后目的地。
对于操作请求的发送和操作响应的发送,能够独立地进行协商,不必为每个最后目的地建立通信连接,通信开销能够减少,并且通信息效率能够提高。
如果图像处理设备100的数目增加,并且在处理服务器103、传送服务器102和图像处理设备100间应当发送的操作请求和操作响应也越来越多,该效果将变得很大。
尤其对于图像处理设备100,因为所有的操作请求和操作响应能够在传送服务器102间集中地发送,通信定时管理也变得简单。
因为操作请求和操作响应相应地变成了串行的数据并且变成以结构化语言形式表示的输出消息,因此操作请求和操作响应能够被集中地发送。
通过这样做,格式不同的操作请求和操作响应能够被简单地组合,作为一个发送内容逻辑地发送。
通过这样做,每个设备集中接收的操作请求和操作响应很容易地被划分成每个消息,它们分别是操作请求、操作响应,或者合适的处理能够根据分类和定义执行。
以能够相应地组合两个或者更多操作请求和操作响应的形式示出,在不改变形式的情况下,可以创建一个能够被发送的消息。
在进行多于一个的组合后,如果变成可以划分的形式,在不改变格式的情况下,能够返回到被发送的每个操作请求和操作响应,能够减少在执行操作请求或者操作响应的组合和划分时候的处理负载。
通过从图像处理设备100发送请求和从传送服务器102向图像处理设备100发送操作响应等等,图像处理设备100和传送服务器102间的通信被处理。
如果实施对于通信请求的响应,即使是图像处理设备100形成在防火墙内的情况,操作请求和操作响应的发送和接收能够在没有意识到防火墙存在的情况下执行。
因为通信请求和通信响应一致,通信级的定时管理是容易的。在这种情况下,如果通信请求从上面提到的图像处理设备100周期性地发送到传送服务器102,向图像处理设备100的信息发送的状态将持续长的时间,并能够预防从传送服务器102停滞的情况。
与传送服务器102和服务器103间的通信类似,如果通过一直从传送服务器102发送通信请求来进行通信,即使是不通过服务器103侧管理哪个传送服务器能够作为通信对方的情况,操作请求和操作响应的发送和接收也能够满意地执行。
因此,服务器103侧的通信目的地的管理负担能够被减少。
在这种情况下,如果通信请求周期性地从上面提到的传送服务器102发送到服务器103,向传送服务器102的信息发送的状态将持续长的时间,并能够预防从服务器103停滞的情况。
提供了记录有在每个设备中自身执行的操作请求的命令库,并且提供了记录有自身创建的操作请求的命令库。
对于操作请求和操作响应的产生、发送和接收,在不考虑相对目的地发送定时的情况下,通过将每个应用程序等创建的或者从其它设备接收的操作请求和操作响应存储到这些命令库中,能够实施它。
因此,处理的定时管理能够简化,并且设计和开发也变得简单。
当通过建立收集单元进行通信时,所述收集单元从库中读取应该发送到通信对方的操作请求和操作响应,即使当这样做的时候,也不能够遗漏,应该发送的信息能够被发送。
通过建立将接收的操作请求和操作响应进行单独分离的分配单元,一个合适的库被用于存储,并将接收的信息存储在库中。在不考虑从通信对方接收定时的情况下,可以执行与接收的操作请求、操作响应接收后的处理、操作请求和操作响应有关的操作执行的传送。
因此,定时管理能够被简化,设备的设计和开发变得简单。
例如ID的识别信息被赋予创建的操作请求,并且操作请求被存储。
当发送并且存储和发送该操作请求时,如果通过与操作请求识别信息关联来实现,则还通过与识别信息关联来实现,。
即使当在一个消息(这里是HTTP消息)中包括两个或者更多操作请求和操作响应时,操作请求和操作响应间的相应关系能够通过识别信息来轻易地识别。
优先级被赋予操作请求,如果从高的对象顺序地执行或者发送响应,需要紧急的操作被优先执行,并且响应也能够优先返回。
在传送服务器102中,提供了传送消息库,如果仅仅将协调传送的操作请求和操作响应划分为本身将创建和执行并进行记录,就涉及传送的消息而言,能够执行与其它消息不同的处理。
例如,因为涉及传送的消息不需要解译内容(例如,不需要并行化XML),它能够以已接收的形式存储在传送消息库中。
当搜索应该发送到服务器103的消息时,检索范围可能变窄。因此,传送服务器102中的消息传送代理处理的处理负担能够通过提供传送消息库来减少。
接下来,上面提到的实施例的修改将被解释。
首先,在上面提到的实施例中,尽管已经解释了在终端单元和类似图像处理设备100的服务器103间经由传送服务器102来发送和接收仅仅一个消息的实例,当然,可以经由两个或者更多传送服务器来发送和接收。
图56示出了这样一个分布式处理系统的实例。在这个实例中,终端A能够经由两个传送服务器,即,传送服务器B和传送服务器C来在服务器D间发送和接收消息。
在这种情况下,传送服务器B和C的功能与上面提到的实施例中的传送服务器102的功能是相同的。服务器D的功能与服务器103的功能相同。
在这种情况下,在从终端单元去往服务器的方向发送的消息将被指示到通信请求,对通信请求的通信响应指示和发送相反的方向上发送的消息。
关于每个传送设备,设备变得相对固定,通信设备是关于第一通信设备的第二通信设备。
关于设备的对方设备发送通信请求到传送服务器,尤其是发送到第一通信设备,传送服务器将通信请求发送到第二通信设备。
或者,可以考虑传送没有记载目的地的信息的设备为第一通信设备,并且可以考虑传送了记载目的地的信息的设备为第二通信设备。
在分布式处理系统中,对于应在服务器D发送到传送服务器B的分类消息,目的地是传送服务器C,并且存储被实施(不必存储最后发送的)。
对于应在服务器D应该发送到传送服务器C的分类消息,目的地是服务器D,并且存储被实施。因此,通过建立目的地,发送到传送服务器B的消息能够从终端单元A经由传送服务器C进而发送到服务器D。
此时,当消息在传送服务器C从终端单元A发送到传送服务器B时,“终端单元”的信息被指示到作为发送源信息的“X-Received-From”报头。
当其进而被发送到服务器D时,“传送服务器B”的信息被作为发送源信息附加到随后的“X-Received-From”报头。
另外,处理服务器D能够从记载了该信息的HTTP请求的发送源消息中识别传送服务器C也是发送路径。
因此得出,使得由服务器D侧发送到终端单元A的消息在传送服务器C->传送服务器B->终端单元A的路径中发送是必要的。
然后,服务器D能够通过发送到终端单元A的消息中的“X-Send-To”报头指示出路径信息(不必指示出用作直接目的地的传送服务器C的信息)。
因此,如果如此设置,根据该路径信息,找到传送路径的传送服务器能够发送消息到下一个目的地,并且最后甚至能够发送消息到终端单元A。
此时,在发送消息的时候示出目的地的路径信息被消除,下一个目的地在底部示出。
在从终端单元朝向服务器发送消息中的上面的构成中指示的“X-Received-From”报头的内容被发送,因此图56的陈述可以示出,其与从服务器转向到终端单元的相同路径的消息中指示的“X-Send-To”报头的内容变得完全相同,并被发送。
尽管上面提到的实施例已经说明了是在接收侧附加“X-Received-From”报头并且由发送侧执行“X-Send-To”报头的删除的例子,但这样做也不是绝对必要的。
相反,“X-Received-From”报头可以由发送侧附加,可以由接收侧来删除“X-Send-To”报头。
图57示出了分布式处理系统的构成的另一实施例。
如图57所示,在本发明的分布式处理系统中,与终端单元进行直接通信的传送服务器的数目不必是一个。
不必是仅仅在一个传送服务器与服务器之间发送和接收消息的构成。
与上面提到的一样,一个传送服务器能够在两个或者多个终端单元间发送和接收消息。
即使这样做,在从终端单元朝向服务器发送的消息中,指示了发送代理和传送路径的信息。
由于传送路径和目的地的信息已在消息中指示,中间的传送服务器已针对消息的每个分类存储了目的地信息,并且从服务器发送到终端单元,如果这些已经被涉及,消息能够发送到合适的对方。
在这样的构成的分布式处理系统中,服务器J中的路径信息表在图58中示出。就是说,对于终端单元A,它通过服务器J能够识别,消息能够通过类似终端单元A<=>传送服务器F<=>传送服务器G<=>服务器J的传送路径来发送。
对于终端单元B,它能够识别消息能够通过类似终端单元B<=>传送服务器H<=>服务器J的传送路径来发送。对于终端单元C和D,路径还没有记录。
然而,如果服务器J从终端单元D接收到消息,例如,从消息的传送路径信息中,终端单元D<=>传送服务器F<=>传送服务器G<=>服务器J的路径能够被识别,并且这能够记录在路径信息表中。
当来自没有记录在路径信息表中的例如终端单元E的终端单元的信息被接收到时,类似地,根据消息的传送路径的信息,能够识别出终端单元E<=>传送服务器H<=>服务器J的路径,并且这能够记录在路径信息表中。
然而,错误从没有预先记录在路径信息表中的终端单元返回消息,没有记录的对应关系也通过路径信息表来最新考虑。
除了图56和图57示出的构成,不能过分强调各种构成能够采用作为分布式处理系统。
然而,如果消息已经准备好从一个终端单元向两个或者更多传送服务器发送,在终端侧管理消息的目的地将变得必要。
然后,使得消息准备好从一个终端单元仅仅向一个传送服务器发送是最好的。
在这些分布式处理系统中,包括上面提到的实施例的分布式处理系统,没有必要必须区分服务器和传送服务器。
当这样做的时候,这些服务器的功能仅仅增加了关于路径信息存储单元250的功能,这样服务器103被解释为通过实施例解释了传送服务器102的功能。
在该设备中,除了它本身的任一信息没有作为目的地记录在目的地表中,涉及所有接收的操作请求和响应的处理将由它本身处理,用于传送的消息库和消息传送单元都不使用,结果它将作为服务器。
因此,由于通过改变目的地表的内容,相同的设备能够作为服务器和传送服务器中的任一个来任意操作,如果这样,系统的结构将变得简单。
不给传送服务器提供执行涉及操作请求的处理的功能或者创建操作请求的功能,而是相反地使用传送服务器作为消息的代理中指定的设备,这也是可能的。
当这样做时,终端命令库、传送服务器命令库、终端命令执行创建单元以及传送服务器命令创建单元都是不必要的。
因此,能够简化传送服务器的组成,减少设计或者开发的时间和努力,获得低成本构造。
通信请求从服务器发送到传送服务器,也考虑可能将开始通信请求的消息作为操作请求或者操作响应来标识和发送。
在上面提到的实施例中,根据传送服务器102中的目的地表,如图34所示,对于每个名称空间URI,解释了使用该消息的目的地上的信息所表示的内容的例子,该消息涉及属于名称空间的命令和命令响应。
然而,也考虑发送目的地没有在目的地表中清楚地指向预定目的地的消息。
当这样做的时候,如图59所示,“默认”项提供在目的地表中。
当命令和命令响应的名称空间URI都没有记录在目的地表中时,将涉及命令和命令响应的消息发送到记录在“默认”栏中的目的地是可能的。
在图33所示的分布式处理系统中的情况下,当在步骤S22名称空间URI没有记录在目的地表中时,较好使得候选部分消息的目的地记入“默认”栏中的目的地。
根据使用图59中示出的使用目的地表的系统配置,能够考虑例如在图60中示出的构成。也就是,在图3中示出的分布式处理系统中,存在附加的和形成的综合管理服务器103C的结构。
图59示出的目的地表存储在设备管理服务器102中。使用设备管理服务器102所进行的处理是发送所有的消息,而不是发送到销售管理服务器103a或者信息传递服务器103b,也不是发送到综合管理服务器103C。
由于在传送服务器102中根据能够通过这样处理的所有命令和命令响应来中止指定目的地信息是必要的,系统的设计和管理变得简单。
在这种情况下,不必由它本身去处理综合管理服务器103C接收的消息,可以发送到另外的其它设备。
通过图34中示出的不具有“默认”项的表,综合管理服务器103C在那种情况中使用的目的地表可能具有图59中示出的“默认”项。也考虑使得记录在“默认”项中的目的地记入与一个名称空间URI对应并且记录在目的地表中的目的地相同的地方。
也考虑在每个传送服务器中使用如图61示出的目的地表。也就是,传送服务器本身仅仅作为涉及应该由自身处理的命令和命令响应的目的地来记录,并且将所有其它命令和命令响应发送到接下来的传送服务器也被考虑。
在这种情况下,分布式处理系统构成如图62所示,两个或者多个传送服务器串行排列,每个传送服务器能够一个接一个将涉及除了它本身应该处理的命令或者命令响应的消息发送到随后的服务器。
因此,由于使得传送服务器仅仅存储本身应该处理的命令、命令响应和其它命令的信息以及命令响应的目的地是必要的,如果系统被构建,系统的设计和管理变得更加简单。
因为每个传送服务器不必知道消息在传送服务器和消息目的地的服务器中是怎样被处理的,因此在传送服务器和目的地的服务器中,可以自由地定义命令的种类和对接收处理的分配,不需要通知源传送服务器。
因此,如果这样的构成被采纳,当给一个单独的公司提供涉及消息的传送服务器外购处理的公司以及接收转包合同的订购的公司对子转包合同进一步处理时,接收处理的订购的公司能够自由地构建一个系统,这是特别有效的。
如果在最后阶段的服务器N中,目的地表中没有设置“默许”的项,并且并对名称空间URI没被记录到目标表的命令和命令响应执行错误处理,那么对于根本不相关的命令,合适的对应也是可能的。
只要能够仅仅响应如图62所示来直接安排两个或者更多传送服务器的组成是必要的,可使得替代在图63示出的每个传送服务器的目的地表的信息存储。
也就是,可以使得由它本身处理的方法属于的名称空间URI和传送其它命令的目的地服务器的ID等存储。
在处理使用图63示出的信息接收的消息的情况下,处理流程图在图64中示出。
图64示出的处理由图33中示出的步骤S22和S23的处理来代替,并且执行步骤SA和步骤SB的处理。
也就是,当使用图63示出的信息时,在图32示出的消息发送和接收的基本流程中的消息分配处理中,执行图64所示的处理。
在步骤S21,获得涉及消息的命令的名称空间URI,或者从候选部分的SOAP消息中获得命令响应,在步骤SA,名称空间URI确定它是否包含在图63示出的“由它本身处理的方法所属的名称空间URI”中。
当包含时,因为命令和命令响应都应该由本身来处理,所以处理进行到步骤S24之前,并且执与图33的情况相同的处理。
当不包含时,由于命令或者命令响应被发送到随后的传送服务器,在图63示出的步骤SB,消息的目的地设置将“随后的传送服务器”记录为“目的服务器ID”,处理进行到步骤S34之前,并且目标消息记录到用于传送的传送消息库51。
如果每个传送服务器都执行上面的处理,对于图63示出的信息,消息能够合理地发送。
收集记录在传送消息库51中用于发送的所有消息是必要的,当执行图39中示出的消息传送处理时,正好使得它发送到预定目的地,因为采用这样的处理时那里只有一个目的服务器。
因此,在如图14示出的传送消息表单中管理消息目的地不是绝对必要的。两个或者更多服务器可以记录为“目的服务器ID”,并且在接收时序安排的起点,根据消息的接收日期,能够给每个服务器随意分配涉及应该被发送到其它服务器的命令的消息的目的地和消息。
如果这样做,能够预防消息集中在目的地服务器上,能够针对处理负担的分配。可以使用相同的所述命令响应来执行处理。
在这种情况下,如果可以最后接收消息的每个设备能够汇集形成在能够被共同涉及和接收的数据库的消息,即使命令响应没有达到命令的源节点设备,也能够通过访问数据库参考用于发送代理的设备的命令响应。
即使是涉及能够由它本身处理的命令的消息,当需要由本身处理的资源不够安全时,根据这种情况,可以发送到其它服务器。
当这样做时,对于目的地服务器来说,提供能够处理与源服务器相同命令的功能是很好的。
如果这样,当处理负载集中在一些服务器上时,能使两个或者更多有效的服务器通过提供简单处理而进行分配处理。
在上面提到的实施例中,尽管说明了由多个部分在每个设备间发送消息的例子,这样做也不是必不可少的。
例如,由系统处理的命令从终端单元返回到传送服务器或服务器。对于一个HTTP请求或者HTTP响应使用图41所解释的处理在系统102中仅仅指示了一个SOAP消息,例如,传送服务器102,其可被使用。
因为不必使得每个设备与类似多部分的特殊传送协议对应,如果这样,设计或者开发的时间和努力能够被减少,并且能够获得低成本的结构。
如果根据上面的多部分来执行传送,由系统处理的命令从终端单元转到传送服务器或者服务器,类似地,上面提到的效果能够获得。
尽管上面所提到的每个实施例中SOAP根据实现RPC的较高层协议来采用,通过使用CORBA(公共对象请求中介体系结构)或者JAVA(注册的商标)RMI(远程方法调用)建立桥接(消息转换功能),在应用程序和库之间可以实现直接操作库的应用程序和RPC。可以进一步提高应用程序的开发效率。
在上面所提到的实施例中,尽管由通过XML描述的SOAP消息来实现,每个节点间的命令和其的此命令响应的交换都并不限制与此,也可以其它的形式来描述。可以在发送和接收的命令中或者命令响应的信息量中提供限制。
如果特别接收的命令信息量被限制,当接收侧设备的存储空间被限制时,使用的存储量也能够被停止。
在上面所提到的实施例中,通过增加和采用不是用于SOAP的标准协议而是SOAP和MIME多部分组合的初始协议,包含在HTTP请求或者HTTP响应中的SOAP信包象变得完全独立那样处理。通过根据SOAP规范来定义SOAP附件,到第二部分之后的SOAP信包的链接可以在包含在HTTP响应中的第一部分的SOAP信包中嵌入,并且可能具有关联和移交这些的组合。这与采用SMTP时是相同的。
当采用SMTP作为消息的传送协议时,消息将被指示和发送到E-mail,但是使用MIME多部分等来指示两个或更多消息到一个副本的E-mail的消息是可能的。
因此,它能够替代上面提到的HTTP请求和HTTP响应,也能够使用E-mail和应答E-mail。然而,因为没有类似于需要的信息和E-mail的响应的对应关系,因此独立地管理开始发送定时和对此的答复是必要的。
对于系统的平滑应用,使用HTTP作为传送协议是更期望的,因为对于E-mail到达目的地将花费较长一段时间。
尽管这里解释的是经由因特网14连接图像处理设备100和传送服务器102的例子,除此之外不需要电缆和无线电资源,但是网络通信中的各种可能通信路径都可以使用。
同样,传送服务器102和服务器103之间的各种通信路径都可以使用。并不限制于上面所说明的,本发明能够应用于除了远程管理系统的分布式处理系统以及与分布式处理系统的结构有关的任意通信系统。
例如,上面提到的实施例中的“终端单元”到最后的分布式处理系统中的“终端”,在客户环境中不需要作为“终端”。也就是,通过在客户环境中使用基本系统服务器作为“终端单元”,它与类似于上面提到的实施例的分布式处理系统相连接,处理从此获得的消息并分配到客户环境中的其它设备的组合也可以被采用。
不必执行与服务器各自不同的命令的设备。例如,不但操作请求和操作响应的种类而且消息的源节点信息也都被涉及,并且在传送服务器中指定目的地。
如果这样作,发送操作请求的终端单元的数目将增加,甚至当服务器负担变得过度时,它能够对于固定数目的每个终端单元实施划分服务器,处理的负担分配能够轻易计划。
同样在该情况下,因为必须告诉终端侧没有分配的处理内容,系统配置变化情况下的负担能够最小化地管理。
对于来自终端侧的操作请求,根据内容,传送服务器能够执行监督通信业务量等并且能够动态地改变目的地。
即使这样作,因为具有为服务器指定合适的传送路径并且返回操作响应的功能,操作响应能够正确地返回到操作请求的源节点。
等同于传送服务器的设备也安装在客户环境中,可以使得两个或者更多终端单元所涉及的消息的传送被集中地承担。
在这种情况下,因为客户环境中的传送服务器和终端单元能够考虑通过LAN来连接,因此它们可以将用于LAN中的通信的通用通信协议应用于它们之间的通信。
因此,如果在客户环境的传送服务器中提供了协议转换功能,即使是不支持特殊协议的终端单元,也能够与使用例如多部分传送的特殊协议的分布式处理系统相连接,并且可以获得上面提到的效果。
因为客户环境中的传送服务器和终端单元很小而且是末端,为了它们可以经由网络来进行通信,在所述网络中通信对方一般被限制,即使这样做,通信数目的次数增加,通信效率不会下降这么多。
因为不必使得终端单元与复杂的通信协议对应,构建系统的时间、效果和花费能够被缩减。在这种情况下,通过基于LAN和RS-485规范等的串连和基于SCSI(小计算机系统接口)规范等的并联,客户环境的传送服务器和终端单元间的连接能够得到。
例如,在RS-485规范的情况下,直到有五个终端单元是可串行连接在传送服务器。假设在客户环境中不提供传送服务器,为了预防信息发送的停滞,将独立地执行上面提到的每个终端单元定期需要的信息。
因此,很多需要的信息将通过功能性提供侧流入传送服务器102。因此,优选地,在客户环境中形成许多终端单元时,最好地在客户环境中提供传送服务器,并且通过表示使得传送服务器周期性地执行需要的信息。
在这种情况下,可以考虑图65示出的系统配置。
在图65中,作为控制设备的一个例子,提到了一种与例如电视机10a或者电冰箱10b的家用电器、医疗设备10c、自动贩卖机10d、管理系统10e和空调系统10f连接的网络,其中控制设备单独形成客户环境侧传送服务器112。
汽车10g和飞机10h作为没有单独形成客户环境侧传送服务器112的控制设备的例子来提到。在移动较大区域的设备中,例如汽车10g和飞机10h,具有防火墙(FW)11功能是较好的。
如果需要的信息经常从客户环境侧传送服务器112发出,并且即使防火墙11在客户环境侧传送服务器112和传送服务器102之间,也使得由功能提供侧发送消息,尤其在信息的传送中将没有麻烦。
相同的自动售货机关于功能提供侧不需要提供传送服务器102和服务器103。
如果命令的目的地能够被每个传送服务器掌握,怎样由目的地服务器提供功能将不成问题。
因此,通过终端侧来发送到两个或者更多提供功能的服务器的命令,例如旅游胜地指南、时间表指南、定票和预定住处。
命令响应的XML数据是分别处理的,并且结合在一起,如果执行了转换成HTML文件的处理,传送服务器也能够提供相同的服务,该服务被称为在一个网页中提供两个或者更多地点功能的入口地点。
在上面提到的实施例中,在使用终端单元说明的例子中,没有指示有关目的地的消息以及传送到传送服务器的操作请求和操作响应的目的地。
然而,应该传送终端命令的服务器的目的地以及服务器命令的源节点的信息都由终端侧来掌握,并用来指示传送到传送服务器的命令和命令响应的目的地。
这样做时,将目的地和发送代理的信息标识到SOAP信息的SOAP报头,并且在终端命令表单或者服务器侧命令表单上指示这个并且正好管理它,这些都是必要的。
当指示到从终端单元接收的操作请求和操作响应的目的地是在其中可进行本身或者直接通信的设备,传送服务器不提供目的地表,而是应该通过产生指示到SOAP报头的目的地,将它记录到传送信息表单中。
当经由另一传送服务器传送到目的地的设备能被包含时,目的地信息和作为直接目的地使用的设备间的对应关系作为目的表存储起来,参考这一表来判断下一级目的地是可能的。
为了解译SOAP报头中的内容,并行化SOAP报头中的消息是必要的。即使当这样的组成被采用,通过集中地将寻址到两个或者更多终端单元的操作请求从服务器发送到传送服务器,通信效率的改进效果将象上面所提到的实施例的情况那样被获得。当上面提到的传送服务器是客户环境侧的传送服务器时,效果特别大。
传送服务器捆绑来自寻址到终端单元的两个或者更多服务器的操作请求,并且发送,当集中地接收那些操作请求的操作响应时,同样获得了通信效率的提高的效果。
该效果具有很大的影响,尤其是当传送服务器在功能提供侧提供时。即使当没有处理来自终端侧的操作请求而是仅仅处理来自服务器侧的操作请求和对该请求的操作响应时,这些影响也可以获得。
当然,上面说明的每个变型在不矛盾的范围内能够被组合和应用。
本发明的程序是用于操作作为协调第一通信设备和两个或者更多第二通信设备间通信的传送设备的计算机的程序。
上面提到的能够通过使得计算机执行这样的程序来获得。尽管这样的程序可以存储在计算机初始配置的存储单元中,例如ROM或者HDD。程序也能够记录在非易失记录介质(存储器)上,例如是记录介质或者软盘的CD-ROM,也能够提供SRAM和EEPROM以及存储卡。
通过将记录在所述存储装置上的程序安装入计算机并且执行CPU,或者使得CPU从所述存储装置中读取和执行该程序,上面提到的每个程序都能够被执行。
下载和执行外部指令或者提供在记录介质上的程序是可能的,其连接到网络并且根据存储单元存储的外部指令记录程序。
如上所述,如果利用本发明的传送设备、分布式处理系统、数据发送方法、程序或者记录介质,当构建下述系统时,即,所述系统中特定通信设备发送操作请求到两个或者更多通信设备,并且接收该操作请求的操作响应,那么通过合理地协调通信设备间的通信,能够增加通信效率。
因此,具有小的通信负载的通信系统能够通过将本发明应用于协调这样的通信系统中的通信的传送设备上来构建。
本发明并不限于说明提到的实施例,在不与本发明的精神分离的情况下,能够得到各种变型和修改。
而且,本发明要求申请号为2004-272605并于2004年9月17日提交的日本专利申请的优先级,结合全部内容以供参考。
Claims (28)
1、一种经由网络协调第一通信设备和第二通信设备间的通信的传送设备,包括:
第一接收单元,集中地从第一通信设备接收操作响应,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
第一发送单元,集中地将由第一接收单元接收的操作响应发送给第二通信设备,该第二通信设备作为每个操作响应的目的地;
第二接收单元,集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求;和
第二发送单元,将由第二接收单元接收的操作请求集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求的各自的目的地。
2、一种经由网络协调第一通信设备和第二通信设备间的通信的传送设备,包括:
第一接收单元,集中地从第一通信设备接收操作请求和操作响应,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
第一发送单元,根据第一通信设备的每个操作请求和操作响应的分类,集中地将由第一接收单元接收的操作请求和操作响应发送给作为目的地的第二通信设备;
第二接收单元,集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求以及相对于第一通信设备的操作请求创建并被发送到第一通信设备的操作响应;
第二发送单元,将由第二接收单元接收的操作请求和操作响应集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求和操作响应的各自的目的地。
3、一种经由网络协调第一通信设备和第二通信设备间的通信的传送设备,包括:
第一接收单元,集中地从第一通信设备接收操作请求和操作响应,该操作请求被发送到第二通信设备,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
第一发送机单元,根据第一通信设备的每个操作请求和操作响应的分类,集中地将由第一接收单元接收的操作请求和操作响应发送给作为目的地的第二通信设备;
第二接收机单元,集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求以及相对于第一通信设备的操作请求创建并发送到第一通信设备的操作响应;
第二发送单元,集中地将由第二接收单元接收的操作请求和操作响应集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求和操作响应的各自的目的地。
4、根据权利要求2的发送设备,还包括响应创建单元,用于当传送设备执行操作时执行与第一接收单元的一个接收的操作请求有关的操作,通过操作执行的结果,该响应创建单元相对于一个接收的操作请求创建操作响应,
其中第二发送单元被配置为将由响应创建单元创建的操作响应以及第二接收单元的接收的操作请求和接收的操作响应集中地发送到第一通信设备。
5、一种经由网络协调第一通信设备和第二通信设备间的通信的传送设备,包括:
第一接收单元,从第一通信设备接收单个HTTP请求,该HTTP请求包含第一通信设备各自的SOAP响应,该SOAP响应相对于第二通信设备的SOAP请求而创建,并发送到第二通信设备;
第一发送单元,将由第一接收单元接收的HTTP请求发送给第二通信设备,该第二通信设备作为包含在HTTP请求中的每个SOAP响应的目的地;
第二接收单元,从第二通信设备接收HTTP响应,该HTTP响应相对于HTTP请求创建并且包含第二通信设备的被相应地发送到第一通信设备的SOAP请求;和
第二发送单元,将包含在由第二接收单元接收的HTTP响应中的SOAP请求发送到第一通信设备,该第一通信设备作为SOAP请求的各自的目的地。
6、根据权利要求5的发送设备,其中所述第一发送单元被配置为具有周期地发送HTTP请求到第二通信设备的单元。
7、根据权利要求5的发送设备,其中第二发送单元被配置为在第一接收单元接收HTTP请求时,相应地创建包含所有被发送到第一通信设备的SOAP请求的HTTP响应,并且被配置为发送包含在接收的HTTP响应中的SOAP请求到第一通信设备。
8、一种具有互联的服务器和传送设备的分布式处理系统,该传送设备经由网络协调服务器和终端单元间的通信,该传送设备包括:
第一接收单元,集中地从终端单元接收操作响应,该操作响应相对于服务器的操作请求而创建,并发送到服务器;
第一发送单元,集中地将由第一接收单元接收的操作响应发送给服务器,该服务器作为每个操作响应的目的地;
第二接收单元,集中地从服务器接收由服务器发送到终端单元的操作请求;和
第二发送单元,将由第二接收单元接收的操作请求集中地发送到终端单元,该终端单元作为服务器的操作请求的各自的目的地,
该服务器包括:
发送单元,集中地将被发送到终端单元的操作请求发送到传送设备;和
接收单元,集中地从传送设备接收终端单元的操作响应,该操作响应相对于服务器的操作请求而创建并被发送到终端单元。
9、一种具有互联的服务器和传送设备的分布式处理系统,传送设备经由网络协调服务器和终端单元间的通信,该传送设备包括:
第一接收单元,集中地从终端单元接收操作请求和操作响应,该操作响应相对于服务器的操作请求而创建,并发送到服务器;
第一发送单元,根据终端单元的每个操作请求和操作响应的分类,集中地将由第一接收单元接收的操作请求和操作响应发送给作为目的地的服务器;
第二接收单元,集中地从服务器接收由服务器发送到终端单元的操作请求以及相对于终端单元的操作请求创建并发送到服务器的操作响应;
第二发送单元,将由第二接收单元接收的操作请求和操作响应集中地发送到终端单元,该终端单元作为服务器的操作请求和操作响应的各自的目的地,
服务器包括:
接收单元,集中地从传送设备接发送到服务器的终端单元的操作请求以及相对于服务器的操作请求创建并发送到服务器的终端单元的操作响应;
响应创建单元,相对于由接收单元接收的终端单元的操作请求来创建服务器的操作响应;和
发送单元,集中地将被发送到终端单元的操作请求以及由响应创建单元创建并发送给终端单元的操作响应发送到传送设备。
10.一种具有互联的服务器和传送设备的分布式处理系统,传送设备经由网络协调服务器和终端单元间的通信,该传送设备包括:
第一接收单元,集中地从终端单元接收操作请求和操作响应,该操作请求被发送到服务器,该操作响应相对于服务器的操作请求而创建,并发送到服务器;
第一发送单元,根据终端单元的每个操作请求和操作响应的分类,集中地将由第一接收单元接收的操作请求和操作响应发送给作为目的地的服务器;
第二接收单元,集中地从服务器接收由服务器发送到终端单元的操作请求以及相对于终端单元的操作请求创建并发送到服务器的操作响应;
第二发送单元,集中地将由第二接收单元接收的操作请求和操作响应集中地发送到终端单元,该终端单元作为服务器的操作请求和操作响应各自的目的地,
服务器包括:
接收单元,集中地从传送设备接收发送到服务器的终端单元的操作请求以及相对于服务器的操作请求创建并发送到服务器的终端单元的操作响应;
响应创建单元,相对于由接收单元接收的终端单元的操作请求来创建服务器的操作响应;和
发送单元,集中地将被发送到终端单元的操作请求以及由响应创建单元创建并发送给终端单元的操作响应发送到传送设备。
11、根据权利要求9的分布式处理系统,其中传送设备还包括响应创建单元,当传送设备执行操作时,该响应创建单元执行与第一接收单元的一个接收的操作请求有关的操作,通过操作执行的结果,该响应创建单元相对于一个接收的操作请求创建操作响应,
其中第二发送单元被配置为将由响应创建单元创建的操作响应以及第二接收单元的接收的操作请求和接收的操作响应集中地发送到终端单元。
12、一种具有互联的服务器和传送设备的分布式处理系统,传送设备经由网络协调服务器和终端单元间的通信,该传送设备包括:
第一接收单元,从终端单元接收单个HTTP请求,该HTTP请求包含终端单元各自的SOAP响应,该SOAP响应相对于服务器的SOAP请求而创建,并发送到服务器;
第一发送单元,将由第一接收单元接收的HTTP请求发送给服务器,该第二服务器作为包含在HTTP请求中的每个SOAP响应的目的地;
第二接收单元,从服务器接收HTTP响应,该HTTP响应相对于HTTP请求创建并且包含相应地发送到终端单元的服务器的SOAP请求;和
第二发送单元,将由第二接收单元接收的包含在HTTP响应中的SOAP请求发送到终端单元,该终端单元作为SOAP请求的各自的目的地,
服务器包括:
接收单元,从传送设备接收包含终端单元的SOAP响应的HTTP请求,该响应相对于服务器的SOAP请求创建并发送到终端单元;和
发送单元,将包含发送给终端单元的服务器的SOAP请求的HTTP响应发送到传送设备。
13、根据权利要求12的分布式处理系统,其中传送设备的第一发送单元被配置为具有周期地发送HTTP请求到服务器的单元。
14、根据权利要求12的分布式处理系统,其中传送设备的第二发送单元被配置为在第一接收单元接收HTTP请求时,创建包含所有分别发送到终端单元的SOAP请求的HTTP响应,并且配置为发送包含在接收的HTTP响应中的SOAP请求到终端单元。
15、一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
集中地从第一通信设备接收操作响应,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
集中地将操作响应发送给作为每个操作响应的目的地的第二通信设备;
集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求;和
将接收的操作请求集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求的各自的目的地。
16、一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
集中地从第一通信设备接收操作请求和操作响应,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
根据第一通信设备的每个操作请求和操作响应的分类,集中地将操作请求和操作响应发送给作为目的地的第二通信设备;
集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求以及相对于第一通信设备的操作请求创建并发送到第一通信设备的操作响应;
将操作请求和操作响应集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求和操作响应的各自的目的地。
17、一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
集中地从第一通信设备接收操作请求和操作响应,该操作请求被发送到第二通信设备,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
根据第一通信设备的每个操作请求和操作响应的分类,集中地将操作请求和操作响应发送给作为目的地的第二通信设备;
集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求以及相对于第一通信设备的操作请求创建并发送到第一通信设备的操作响应;
集中地将操作请求和操作响应发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求和操作响应的各自的目的地。
18、根据权利要求16的方法,还包括当传送设备执行操作时,执行与第一接收单元的一个已接收的操作请求相关的操作,其中通过操作执行的结果,该操作响应相对于一个接收的操作请求被创建,
其中第二发送步骤被配置为将创建的操作响应以及第二接收单元的接收的操作请求和接收的操作响应集中地发送到第一通信设备。
19、一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
从第一通信设备接收单个HTTP请求,该HTTP请求包含第一通信设备的各自的SOAP响应,该SOAP响应相对于第二通信设备的SOAP请求而创建,并发送到第二通信设备;
将HTTP请求发送给第二通信设备,该第二通信设备作为包含在HTTP请求中的每个SOAP响应的目的地;
从第二通信设备接收HTTP响应,该HTTP响应相对于HTTP请求被创建并且包含第二通信设备的被相应地发送到第一通信设备的SOAP请求;和
将包含在HTTP响应中的SOAP请求发送到第一通信设备,该第一通信设备作为SOAP请求各自的目的地。
20、根据权利要求19的方法,其中第一发送步骤被配置为包括周期地发送HTTP请求到第二通信设备。
21、根据权利要求19的方法,其中第二发送步骤被设置为在接收HTTP请求时,创建包含所有分别发送到第一通信设备的SOAP请求的HTTP响应,并且被配置为发送包含在接收的HTTP响应中的SOAP请求到第一通信设备。
22、一种计算机程序产品,用于使计算机执行一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
集中地从第一通信设备接收操作响应,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
集中地将操作响应发送给作为每个操作响应的目的地的第二通信设备;
集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求;和
将接收的操作请求集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求的各自的目的地。
23、一种计算机程序产品,用于使计算机执行一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
集中地从第一通信设备接收操作请求和操作响应,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
根据第一通信设备的每个操作请求和操作响应的分类,集中地将操作请求和操作响应发送给作为目的地的第二通信设备;
集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求以及相对于第一通信设备的操作请求创建并发送到第一通信设备的操作响应;和
将操作请求和操作响应集中地发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求和操作响应的各自的目的地。
24、一种计算机程序产品,用于使计算机执行一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
集中地从第一通信设备接收操作请求和操作响应,该操作请求被发送到第二通信设备,该操作响应相对于第二通信设备的操作请求而创建,并发送到第二通信设备;
根据第一通信设备的每个操作请求和操作响应的分类,集中地将操作请求和操作响应发送给作为目的地的第二通信设备;
集中地从第二通信设备接收由第二通信设备发送到第一通信设备的操作请求以及相对于第一通信设备的操作请求创建并发送到第一通信设备的操作响应;
集中地将操作请求和操作响应发送到第一通信设备,该第一通信设备作为第二通信设备的操作请求和操作响应的各自的目的地。
25、根据权利要求23的计算机程序产品,其中该方法还包括当传送设备执行操作时,执行与第一接收单元的一个接收的操作请求相关的操作,其中通过操作执行的结果,该操作响应相对于一个接收的操作请求被创建,
其中第二发送步骤被配置为将创建的操作响应以及第二接收单元的接收的操作请求和接收的操作响应集中地发送到第一通信设备。
26、一种计算机程序产品,用于使计算机执行一种控制传送设备的方法,该传送设备经由网络协调第一通信设备和第二通信设备间的通信,该方法包括:
从第一通信设备接收单个HTTP请求,该HTTP请求包含第一通信设备各自的SOAP响应,该SOAP响应相对于第二通信设备的SOAP请求而创建,并发送到第二通信设备;
将HTTP请求发送给第二通信设备,该第二通信设备作为包含在HTTP请求中的每个SOAP响应的目的地;
从第二通信设备接收HTTP响应,该HTTP响应相对于HTTP请求被创建并且包含被相应地发送到第一通信设备的第二通信设备的SOAP请求;和
将包含在HTTP响应中的SOAP请求发送到第一通信设备,该第一通信设备作为SOAP请求的各自的目的地。
27、根据权利要求26的计算机程序产品,其中第一发送步骤被配置为包括周期地发送HTTP请求到第二通信设备。
28、根据权利要求26的计算机程序产品,其中第二发送步骤被设置为接收HTTP请求时,创建包含所有分别发送到第一通信设备的SOAP请求的HTTP响应,并且被配置为发送包含在接收的HTTP响应中的SOAP请求到第一通信设备。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004272605A JP2005259105A (ja) | 2004-02-09 | 2004-09-17 | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 |
JP272605/04 | 2004-09-17 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1770776A true CN1770776A (zh) | 2006-05-10 |
CN100581161C CN100581161C (zh) | 2010-01-13 |
Family
ID=35045399
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200510119981.2A Expired - Fee Related CN100581161C (zh) | 2004-09-17 | 2005-08-09 | 传送设备及其控制方法、分布式处理系统、程序和记录介质 |
Country Status (4)
Country | Link |
---|---|
US (1) | US7587496B2 (zh) |
EP (1) | EP1638289B1 (zh) |
CN (1) | CN100581161C (zh) |
DE (1) | DE602005013037D1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101483666B (zh) * | 2008-01-10 | 2012-12-26 | 国际商业机器公司 | 管理j2ee和.net交互操作应用的方法和系统 |
CN104429025A (zh) * | 2012-07-13 | 2015-03-18 | 松下知识产权经营株式会社 | 代理装置、通信系统以及程序 |
CN104469043A (zh) * | 2014-12-01 | 2015-03-25 | 成都联宇创新科技有限公司 | 用于远程终端管理系统的调制解调器电路 |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4742784B2 (ja) * | 2005-09-28 | 2011-08-10 | ブラザー工業株式会社 | 情報分配処理プログラム、情報処理装置、および情報分配処理システム |
US20080102903A1 (en) * | 2006-10-30 | 2008-05-01 | Motorola, Inc. | Emergency plan battery energy reservation |
JP4405503B2 (ja) * | 2006-12-28 | 2010-01-27 | キヤノンItソリューションズ株式会社 | 情報処理装置および情報処理装置の制御方法およびプログラムおよび記録媒体 |
US8218165B2 (en) * | 2007-03-26 | 2012-07-10 | Ricoh Company, Ltd. | Interruption management method for an image forming apparatus |
US20090070336A1 (en) * | 2007-09-07 | 2009-03-12 | Sap Ag | Method and system for managing transmitted requests |
US8438567B2 (en) * | 2007-11-07 | 2013-05-07 | Ricoh Company, Ltd. | Information processing device and image processing apparatus |
US8683458B2 (en) * | 2007-11-30 | 2014-03-25 | Red Hat, Inc. | Automatic full install upgrade of a network appliance |
FR2926692B1 (fr) * | 2008-01-23 | 2010-02-19 | Airbus France | Procedes et dispositifs pour ameliorer la fiabilite de communication entre un aeronef et un systeme distant |
US8418164B2 (en) * | 2008-05-29 | 2013-04-09 | Red Hat, Inc. | Image install of a network appliance |
US9986044B2 (en) * | 2013-10-21 | 2018-05-29 | Huawei Technologies Co., Ltd. | Multi-screen interaction method, devices, and system |
US10372515B1 (en) * | 2015-10-30 | 2019-08-06 | American Airlines, Inc. | System agnostic front end application for legacy systems |
US12061709B2 (en) | 2019-08-01 | 2024-08-13 | Palantir Technologies Inc. | Systems and methods for conducting data extraction using dedicated data extraction devices |
US11115458B2 (en) * | 2019-12-24 | 2021-09-07 | Atlassian Pty Ltd. | Monitoring in composite request systems |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0675890A (ja) | 1992-08-26 | 1994-03-18 | Chugoku Nippon Denki Software Kk | クライアント・サーバ間の要求データ応答データ授受方式 |
US6321274B1 (en) | 1996-06-28 | 2001-11-20 | Microsoft Corporation | Multiple procedure calls in a single request |
US6349336B1 (en) | 1999-04-26 | 2002-02-19 | Hewlett-Packard Company | Agent/proxy connection control across a firewall |
US7228350B2 (en) | 2000-08-04 | 2007-06-05 | Avaya Technology Corp. | Intelligent demand driven recognition of URL objects in connection oriented transactions |
FR2813471B1 (fr) | 2000-08-31 | 2002-12-20 | Schneider Automation | Systeme de communication d'un equipement d'automatisme base sur le protocole soap |
JP4065479B2 (ja) | 2000-10-20 | 2008-03-26 | キヤノン株式会社 | 遠隔操作装置及び方法、並びに記憶媒体 |
US7184764B2 (en) | 2001-02-08 | 2007-02-27 | Starhome Gmbh | Method and apparatus for supporting cellular data communication to roaming mobile telephony devices |
US7149813B2 (en) * | 2001-08-14 | 2006-12-12 | Microsoft Corporation | Method and system for synchronizing mobile devices |
US7752331B2 (en) | 2001-10-30 | 2010-07-06 | At&T Intellectual Property I, L.P. | Information gateway manager for multiple devices |
JP3783622B2 (ja) | 2001-12-25 | 2006-06-07 | 日本電信電話株式会社 | Icカード遠隔通信方法及びシステム |
JP2004005418A (ja) | 2002-02-26 | 2004-01-08 | Ricoh Co Ltd | 仲介装置、画像形成装置管理システム、画像形成装置管理方法、画像形成装置管理プログラム及び記録媒体 |
US7428523B2 (en) * | 2002-07-11 | 2008-09-23 | Oracle International Corporation | Portal bridge |
EP1418732B1 (en) | 2002-09-19 | 2016-01-06 | Ricoh Company, Ltd. | Communication system implementing a plurality of communication apparatuses as communication client and communication server for exchanging operation requests and operation responses |
EP2270622B1 (en) * | 2003-06-05 | 2016-08-24 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
-
2005
- 2005-08-05 US US11/197,547 patent/US7587496B2/en not_active Expired - Fee Related
- 2005-08-08 DE DE602005013037T patent/DE602005013037D1/de active Active
- 2005-08-08 EP EP05017208A patent/EP1638289B1/en not_active Not-in-force
- 2005-08-09 CN CN200510119981.2A patent/CN100581161C/zh not_active Expired - Fee Related
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101483666B (zh) * | 2008-01-10 | 2012-12-26 | 国际商业机器公司 | 管理j2ee和.net交互操作应用的方法和系统 |
CN104429025A (zh) * | 2012-07-13 | 2015-03-18 | 松下知识产权经营株式会社 | 代理装置、通信系统以及程序 |
CN104469043A (zh) * | 2014-12-01 | 2015-03-25 | 成都联宇创新科技有限公司 | 用于远程终端管理系统的调制解调器电路 |
Also Published As
Publication number | Publication date |
---|---|
EP1638289A1 (en) | 2006-03-22 |
US20060064459A1 (en) | 2006-03-23 |
DE602005013037D1 (de) | 2009-04-16 |
EP1638289B1 (en) | 2009-03-04 |
US7587496B2 (en) | 2009-09-08 |
CN100581161C (zh) | 2010-01-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1770776A (zh) | 传送设备及其控制方法、分布式处理系统、程序和记录介质 | |
CN100336352C (zh) | 内容发布系统、描述数据发布设备和内容发布方法 | |
CN1278216C (zh) | 设备关联管理系统、网络设备及设备关联管理方法 | |
CN1148041C (zh) | 网络控制系统及其控制器、目标及消费器 | |
CN1273888C (zh) | 成像装置、信息处理装置、程序执行方法及程序生成方法 | |
CN1269337C (zh) | 内容自适应服务控制方法 | |
CN1577324A (zh) | 文档管理方法和程序、记录介质和文档管理装置 | |
CN1444356A (zh) | 数据通信方法 | |
CN1329299A (zh) | 打印控制设备、控制系统及其方法和记录介质 | |
CN1677421A (zh) | 现状系统和现状管理方法 | |
CN1669018A (zh) | 手持终端框架系统 | |
CN1832457A (zh) | 数据包通信装置及功能扩展方法 | |
CN1770772A (zh) | 数据处理系统、数据处理装置和数据处理程序 | |
CN1802818A (zh) | 网络系统、学习桥式节点、学习方法及其程序 | |
CN1949763A (zh) | 共享信息服务器系统 | |
CN1845505A (zh) | 一种家庭网络设备的控制方法及设备管理装置 | |
CN1601474A (zh) | 执行实时操作的方法和系统 | |
CN1428033A (zh) | 语义信息网络 | |
CN1445705A (zh) | 服务提供系统、方法、程序以及存储介质 | |
CN1517849A (zh) | 通过网络设定参数的方法及其主机 | |
CN101069160A (zh) | 信息处理系统、信息处理装置和方法、记录介质以及程序 | |
CN1450483A (zh) | 信息处理装置及信息处理程序 | |
CN1507202A (zh) | 设备管理系统、设备管理终端、网络设备、终端程序、设备程序以及设备管理方法 | |
CN1770773A (zh) | 网络系统、目录服务器和终端装置 | |
CN1539251A (zh) | 通信服务提供系统及方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100113 Termination date: 20150809 |
|
EXPY | Termination of patent right or utility model |