CN104079656A - webService中soap消息的效率优化装置及方法 - Google Patents

Abstract

本发明提供了一种webService中soap消息的效率优化装置，包括：服务请求端，用于发出soap请求消息，在获得资源路径时向远程数据服务器请求资源；业务服务器，用于根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求，根据检查结果进行处理；远程数据服务器，用于接收资源标识，检查本地是否已经缓存过这个资源，根据检查结果继续处理。本发明还提供了一种webService中soap消息的效率优化方法。通过本发明的技术方案，可以在现有的效率优化方式基础上，充分利用单对象类型完成多对象类型效率优化，建立多对象类型参与的效率优化的通用、统一优化思路。

Description

webService中soap消息的效率优化装置及方法

技术领域

本发明涉及计算机技术领域，具体地，涉及一种webService中soap消息的效率优化装置和一种webService中soap消息的效率优化方法。

 

背景技术

webservice技术在ERP系统中已经被广泛的使用。在传统的webservice中依靠soap消息传递数据。soap消息使用xml格式，xml消息是比较冗长的。而且在soap消息中，目前不只有简单的数据，而且会有一些复杂类型的数据，比如报表记录，复杂对象以及数据结构等等，还可以包括图像，视频，音频等多媒体数据。并且，在ERP系统中，经常会有短暂的业务高峰期，而在这个时期，某些业务会被频繁的调用，比如月底的业务高峰期，大量的报表数据会使得网络承受很大的压力，如何改善webService的传输效率，尤其是在大数据场景下的效率，使在较低的网络配置下，仍然能正常支持这种业务并保证性能。这是本文的立足点和待解决的问题。

目前对于复杂对象的传输，一般采用两种方式：

⑴直接使用xml表示数据：这种方式中，通过分解复杂类型的对象到基本类型，然后直接用xml来表达一个对象。

⑵序列化对象的方式：在这种方式中，需要先把对象序列化然后传输给对方，对方需要把对象反序列化，这种方式比较消耗系统资源。

另外，如果要在xml中表达多媒体数据，如图像、音频、视频等数据，这样就比较复杂，目前业内一般采用两种方式传输BLOB和CLOB数据：

⑴ 用BASE64编码，把要传输的数据直接作为soap消息中body的一部分；

这种方式的基本过程是：在服务器端读取目标BLOB资源（一般是序列化的对象，或者多媒体资源），将其保存在byte[]数据中。使用BASE64Encoder编码器将byte[]编码为String。当收到客户端对此资源的请求时，就返回这个String。客户端从soap消息中读取这个String后，再使用BASE64Decoder将此String解码为byte[]。对byte[]进行处理还原。

⑵作为MIME附件，附加在soap消息中。

无论采用哪种方式，都会产生一系列的问题，首先如果在业务高峰期，会有大量的重复数据传输，这样，多次的重复传输会大大增加业务服务器的压力。其次，业务服务器在收到多个服务请求，传输远程对象，稳定性也无法保证，这里是有很大的改进余地的。

因此，需要一种新的webService中soap消息的效率优化技术，可以在现有的webService中soap消息的效率优化方式基础上，充分利用单对象类型完成多对象类型webService中soap消息的效率优化，建立多对象类型参与的webService中soap消息的效率优化的通用、统一优化思路。

 

发明内容

本发明正是基于上述问题，提出了一种新的webService中soap消息的效率优化技术，可以在现有的webService中soap消息的效率优化方式基础上，充分利用单对象类型完成多对象类型webService中soap消息的效率优化，建立多对象类型参与的webService中soap消息的效率优化的通用、统一优化思路。

有鉴于此，本发明提出了一种webService中soap消息的效率优化装置，包括：服务请求端，用于发出soap请求消息到业务服务器；以及，用于在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源；业务服务器，用于根据soap请求消息，准备业务数据，根据检查结果向客户端直接返回数据或向远程数据服务器传输资源标识；以及，用于在收到远程数据服务器返回的资源路径时，直接返回给服务请求端；否则，将准备好的业务数据传输给远程数据服务器；远程数据服务器，用于接收资源标识，检查本地是否已经缓存过这个资源，如果在本地发现资源，则直接返回资源路径；否则，返回给业务服务器响应，准备接收业务数据；以及，用于在接收到业务数据后，进行存储，并返回资源路径给业务服务器。在该技术方案中，可以减轻业务服务器压力的soap消息传输机制，并且可以增加消息传输的稳定性。

在上述技术方案中，优选地，所述服务请求端，具体包括：请求发送模块，用于发出soap请求消息到业务服务器；资源路径获取及资源请求模块，用于在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源。在该技术方案中，利用soap消息传输机制，一方面可以减轻业务服务器压力，另外也可以增加消息传输的稳定性和可靠性。

在上述技术方案中，优选地，所述业务服务器，具体包括：业务数据准备模块，用于根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求；检查结果执行模块，用于根据检查结果向客户端直接返回数据或向远程数据服务器传输资源标识；资源路径接收及转发模块，用于在收到远程数据服务器返回的资源路径时，直接返回给服务请求端；待发业务数据传输模块，用于在未收到远程数据服务器返回的资源路径时，将准备好的业务数据传输给远程数据服务器。在该技术方案中，业务服务器可以专注于web服务中的业务计算，使得分工更加明显，结构更加清晰；同时业务服务器的压力也大大的降低，并且可以提高数据传输的稳定性。

在上述技术方案中，优选地，所述远程数据服务器，具体包括：资源标识接收及缓存信息检查模块，用于接收资源标识，检查本地是否已经缓存过这个资源；缓存信息检查结果执行模块，用于在本地发现资源时，直接返回资源路径给业务服务器；以及，在本地未发现资源时，返回给业务服务器响应，准备接收业务数据；业务数据接收、存储及返回资源路径模块，用于在接收到业务数据后，进行存储，并返回资源路径给业务服务器。在该技术方案中，数据服务器采用缓存策略，可以保证短期内的重复请求的资源可以被复用；并且保持资源的退出机制，以保证足够的空间和防止资源版本的过期；这里的数据存储服务可以由FTP服务器来完成，也可以由分布式存储系统来完成。

在上述技术方案中，优选地，所述业务服务器中的检查结果执行模块，具体包括：直接返回数据子模块，用于在不需要远程数据服务器介入时，直接向服务请求端返回数据；资源标识传输子模块，用于在需要远程数据服务器介入时，将相应资源的唯一标识传输给远程数据服务器，以检查是否需要对该资源重新存储；和/或，所述业务服务器中的业务数据准备模块检查待返回的数据是否满足向远程数据服务器存储托管的要求的操作，具体包括：根据数据类型结构和web服务的业务含义，确定相应数据是否是可以进行数据存储的资源，并且需要设置阈值，只有在相应资源的大小高于该阈值的情况下，才对该资源进行远程的存储托管的处理；和/或，所述远程数据服务器中的缓存信息检查结果执行模块，具体包括：资源路径返回子模块，用于在本地发现资源时，直接返回资源路径给业务服务器；响应返回及业务数据准备接收子模块，用于在本地未发现资源时，返回给业务服务器响应，准备接收业务数据。

根据本发明的又一个方面，还提出了一种webService中soap消息的效率优化方法，包括：步骤202：服务请求端即客户端发出soap请求消息到业务服务器；步骤204：业务服务器根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求，根据检查结果进行处理。在该技术方案中，可以减轻业务服务器压力的soap消息传输机制，并且可以增加消息传输的稳定性。

在上述技术方案中，优选地，所述步骤204检查待返回的数据是否满足向远程数据服务器存储托管的要求的操作，具体包括：根据数据类型结构和web服务的业务含义，确定相应数据是否是可以进行数据存储的资源，并且需要设置阈值，只有在相应资源的大小高于该阈值的情况下，才对该资源进行远程的存储托管的处理；以及，所述步骤204根据检查结果进行处理的操作，具体包括：步骤206：业务服务器根据检查结果向客户端直接返回数据。在该技术方案中，利用soap消息传输机制，一方面可以减轻业务服务器压力，另外也可以增加消息传输的稳定性和可靠性。

在上述技术方案中，优选地，所述步骤204根据检查结果进行处理的操作，具体还包括：步骤208：业务服务器根据检查结果向远程数据服务器传输资源标识，根据检查结果继续处理。在该技术方案中，业务服务器可以专注于web服务中的业务计算，使得分工更加明显，结构更加清晰；同时业务服务器的压力也大大的降低，并且可以提高数据传输的稳定性。

在上述技术方案中，优选地，所述步骤208根据检查结果继续处理的操作，具体包括：步骤212：远程数据服务器接收资源标识，检查本地是否已经缓存过这个资源，如果在本地未发现资源，则返回给业务服务器响应，准备接收业务数据；步骤216：业务服务器在未收到远程数据服务器返回的资源路径时，将准备好的业务数据传输给远程数据服务器；步骤218：远程数据服务器在接收到业务数据后，进行存储，并返回资源路径给业务服务器；步骤220：服务请求端在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源。在该技术方案中，数据服务器采用缓存策略，可以保证短期内的重复请求的资源可以被复用；并且保持资源的退出机制，以保证足够的空间和防止资源版本的过期；这里的数据存储服务可以由FTP服务器来完成，也可以由分布式存储系统来完成。

在上述技术方案中，优选地，所述步骤208根据检查结果继续处理的操作，具体还包括：步骤210：远程数据服务器接收资源标识，检查本地是否已经缓存过这个资源，如果在本地发现资源，则直接向业务服务器返回资源路径；步骤214：业务服务器在收到远程数据服务器返回的资源路径时，直接返回给服务请求端，然后执行步骤220。在该技术方案中，有针对性地进行数据传输，可以避免客户端和业务服务器的长时间的资源传输。

通过以上技术方案，可以在现有的webService中soap消息的效率优化方式基础上，充分利用单对象类型完成多对象类型webService中soap消息的效率优化，建立多对象类型参与的webService中soap消息的效率优化的通用、统一优化思路。

 

附图说明

图1示出了根据本发明的实施例的webService中soap消息的效率优化装置的框图；

图2示出了根据本发明的实施例的webService中soap消息的效率优化方法的流程图；

图3示出了根据本发明的实施例的webService中soap消息的效率优化装置的原理示意图；

图4示出了根据本发明的实施例的webService中soap消息的效率优化方法的详细流程图。

 

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的webService中soap消息的效率优化装置的框图。

如图1所示，根据本发明的实施例的webService中soap消息的效率优化装置100，包括：服务请求端102，用于发出soap请求消息到业务服务器104；以及，用于在从业务服务器获得资源路径时，根据资源路径向远程数据服务器106请求资源；业务服务器104，用于根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器106存储托管的要求，根据检查结果向客户端直接返回数据或向远程数据服务器106传输资源标识；以及，用于在收到远程数据服务器106返回的资源路径时，直接返回给服务请求端；否则，将准备好的业务数据传输给远程数据服务器106；远程数据服务器106，用于接收资源标识，检查本地是否已经缓存过这个资源，如果在本地发现资源，则直接返回资源路径给业务服务器104；否则，返回给业务服务器104响应，准备接收业务数据；以及，用于在接收到业务数据后，进行存储，并返回资源路径给业务服务器104。在该技术方案中，可以减轻业务服务器压力的soap消息传输机制，并且可以增加消息传输的稳定性。

在上述技术方案中，优选地，服务请求端102，具体包括：请求发送模块1022，用于发出soap请求消息到业务服务器；资源路径获取及资源请求模块1024，用于在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源。在该技术方案中，利用soap消息传输机制，一方面可以减轻业务服务器压力，另外也可以增加消息传输的稳定性和可靠性。

在上述技术方案中，优选地，业务服务器104，具体包括：业务数据准备模块1042，用于根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求；检查结果执行模块1044，用于根据检查结果向客户端直接返回数据或向远程数据服务器传输资源标识；资源路径接收及转发模块1046，用于在收到远程数据服务器返回的资源路径时，直接返回给服务请求端；待发业务数据传输模块1048，用于在未收到远程数据服务器返回的资源路径时，将准备好的业务数据传输给远程数据服务器。在该技术方案中，业务服务器可以专注于web服务中的业务计算，使得分工更加明显，结构更加清晰；同时业务服务器的压力也大大的降低，并且可以提高数据传输的稳定性。

在上述技术方案中，优选地，远程数据服务器106，具体包括：资源标识接收及缓存信息检查模块1062，用于接收资源标识，检查本地是否已经缓存过这个资源；缓存信息检查结果执行模块1064，用于在本地发现资源时，直接返回资源路径给业务服务器；以及，在本地未发现资源时，返回给业务服务器响应，准备接收业务数据；业务数据接收、存储及返回资源路径模块1066，用于在接收到业务数据后，进行存储，并返回资源路径给业务服务器。在该技术方案中，数据服务器采用缓存策略，可以保证短期内的重复请求的资源可以被复用；并且保持资源的退出机制，以保证足够的空间和防止资源版本的过期；这里的数据存储服务可以由FTP服务器来完成，也可以由分布式存储系统来完成。

在上述技术方案中，优选地，业务服务器中的检查结果执行模块1044，具体包括：直接返回数据子模块10442，用于在不需要远程数据服务器介入时，直接向服务请求端返回数据；资源标识传输子模块10444，用于在需要远程数据服务器介入时，将相应资源的唯一标识传输给远程数据服务器，以检查是否需要对该资源重新存储；和/或，业务服务器中的业务数据准备模块1042检查待返回的数据是否满足向远程数据服务器存储托管的要求的操作，具体包括：根据数据类型结构和web服务的业务含义，确定相应数据是否是可以进行数据存储的资源，并且需要设置阈值，只有在相应资源的大小高于该阈值的情况下，才对该资源进行远程的存储托管的处理；和/或，远程数据服务器中的缓存信息检查结果执行模块1062，具体包括：资源路径返回子模块10622，用于在本地发现资源时，直接返回资源路径给业务服务器；响应返回及业务数据准备接收子模块10624，用于在本地未发现资源时，返回给业务服务器响应，准备接收业务数据。

图2示出了根据本发明的实施例的webService中soap消息的效率优化方法的流程图。

如图2所示，根据本发明的实施例的webService中soap消息的效率优化方法，包括：步骤202：服务请求端即客户端发出soap请求消息到业务服务器；步骤204：业务服务器根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求，根据检查结果进行处理。在该技术方案中，可以减轻业务服务器压力的soap消息传输机制，并且可以增加消息传输的稳定性。

在上述技术方案中，优选地，步骤204检查待返回的数据是否满足向远程数据服务器存储托管的要求的操作，具体包括：根据数据类型结构和web服务的业务含义，确定相应数据是否是可以进行数据存储的资源，并且需要设置阈值，只有在相应资源的大小高于该阈值的情况下，才对该资源进行远程的存储托管的处理；以及，步骤204根据检查结果进行处理的操作，具体包括：步骤206：业务服务器根据检查结果向客户端直接返回数据。在该技术方案中，利用soap消息传输机制，一方面可以减轻业务服务器压力，另外也可以增加消息传输的稳定性和可靠性。

在上述技术方案中，优选地，步骤204根据检查结果进行处理的操作，具体还包括：步骤208：业务服务器根据检查结果向远程数据服务器传输资源标识，根据检查结果继续处理。在该技术方案中，业务服务器可以专注于web服务中的业务计算，使得分工更加明显，结构更加清晰；同时业务服务器的压力也大大的降低，并且可以提高数据传输的稳定性。

在上述技术方案中，优选地，步骤208根据检查结果继续处理的操作，具体包括：步骤212：远程数据服务器接收资源标识，检查本地是否已经缓存过这个资源，如果在本地未发现资源，则返回给业务服务器响应，准备接收业务数据；步骤216：业务服务器在未收到远程数据服务器返回的资源路径时，将准备好的业务数据传输给远程数据服务器；步骤218：远程数据服务器在接收到业务数据后，进行存储，并返回资源路径给业务服务器；步骤220：服务请求端在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源。在该技术方案中，数据服务器采用缓存策略，可以保证短期内的重复请求的资源可以被复用；并且保持资源的退出机制，以保证足够的空间和防止资源版本的过期；这里的数据存储服务可以由FTP服务器来完成，也可以由分布式存储系统来完成。

在上述技术方案中，优选地，步骤208根据检查结果继续处理的操作，具体还包括：步骤210：远程数据服务器接收资源标识，检查本地是否已经缓存过这个资源，如果在本地发现资源，则直接向业务服务器返回资源路径；步骤214：业务服务器在收到远程数据服务器返回的资源路径时，直接返回给服务请求端，然后执行步骤220。在该技术方案中，有针对性地进行数据传输，可以避免客户端和业务服务器的长时间的资源传输。

本发明的技术方案，涉及一种在ERP系统中可以优化webservice中soap消息的数据传输效率的技术。针对现有技术中存在的缺陷，本发明提出一种可以减轻业务服务器压力的soap消息传输机制，并且可以增加消息传输的稳定性，在使用复杂数据类型的业务高峰期，这种机制发挥的作用尤其明显。

为了克服现有技术中存在的缺陷，本发明提出一种soap消息传输机制，一方面可以减轻业务服务器压力，另外也增加了消息传输的稳定性和可靠性。

本发明的技术方案中，在提供web服务的业务服务器收到soap请求时，首先计算并准备数据，等到数据准备完毕，如果数据格式符合预定义的复杂对象的结构和业务要求，并且客户端请求的资源大小超过一定的阈值，则将该对象发送到第三方的数据服务器（可以是FTP站点，或者分布式缓存系统等等）。而应用服务器返回给请求服务的客户端的soap消息中不再是完整的资源，而是该资源在数据服务器上的路径。这样客户端再根据返回的路径从数据服务器上获取资源。同时，数据服务器提供缓存机制，如果多次请求都针对重复对象，则业务服务器不再需要重复构造对象，则需要获取之前对象的路径，返回给客户端即可。这样就避免了客户端和业务服务器的长时间的资源传输。业务服务器可以专注于web服务中的业务计算，这样也使得分工更加明显，结构更加清晰。同时业务服务器的压力也大大的降低，并且可以提高数据传输的稳定性。

例如，参见图3，请求的详细步骤：

⑴ 客户端发出soap请求消息到业务服务器。

⑵ 业务服务器根据请求准备业务数据。

⑶在业务数据准备完毕之后，业务服务器检查待返回的数据是否满足向远程数据服务器存储的要求。

这里的是否满足要求主要根据数据类型结构和web服务的业务含义来确定此数据是否是可以进行数据存储的资源，并且需要在此处设置一个阈值，只有在资源的大小高于此阈值的情况下，才会对此资源进行远程的存储托管的处理。

⑷如果不需要远程数据服务器介入则直接返回数据。如果需要远程数据服务器介入则将此资源的唯一标识传输给数据服务器，以检查是否需要对此资源重新存储。

⑸数据服务器接到资源标识，首先检查自己是否已经缓存过这个资源，如果在本地发现资源，则直接返回资源路径，否则，返回给业务服务器响应，并做好准备接收业务数据。

⑹业务服务器如果收到数据服务器的资源路径，则直接返回给服务请求端。否则，就需要将之前准备好的数据传输给数据服务器。数据服务器负责接收和存储，并返回资源路径给业务服务器。

这里，数据服务器会有一定的缓存策略，这样可以保证短期内的重复请求的资源可以被复用。并且保持资源的退出机制，以保证足够的空间和防止资源版本的过期。这里的数据存储服务可以由FTP服务器来完成，也可以由分布式存储系统来完成。

⑺服务请求端，从业务服务器获得资源路径，则根据此路径向数据服务器请求资源。

⑻服务结束。

实际场景中，同时会有多个客户端向业务服务器请求数据，并且在业务高峰期，其中有一定的重复数据，则此模式的优势会非常明显，尤其使用于数据密集型的请求场景当中。业务服务器只需要返回资源路径，之后，所有的客户端均从数据服务器下载资源，这样，业务服务器的压力大大减轻，可以专注于业务处理。

又如，参见图4，应用举例：

以一个商品信息请求的服务为例来描述这个机制：

因为一个信息中包含大量的描述图片或者视频介绍，因此这个数据量比较大。用传统的webservice服务，需要将这些多媒体数据都包含在soap消息的消息体或者附件当中，这样，客户端在接收返回值的时候，会是一个相当耗时的操作。同时在返回soap消息的过程中，可能有海量的多个客户端同时向应用服务器发送请求的时候，会造成应用服务器在处理数据传输方面的压力过大，无法保证正常执行业务计算等操作。另外，在传输的过程中出现网络异常，则用户无法拿到完整数据。基于这两个问题来看这个示例：

这里我们有一个客户端client1，这个客户端将发起获取商品信息soap请求，一个应用服务器appServer，一个FTP服务器dataServer。

具体步骤如下：

⑴client1首先向appServer发起针对一个商品详细信息的请求。

⑵appServer在准备好资源后，资源包括（imag1，imag2，video1），appServer首先计算资源的数据量大小，这时会发现数据量太大，而且资源的数据格式可以进行数据缓存，因此并没有直接把多媒体数据返回给客户端，而是把当前的多媒体数据的资源标识发送给FTP服务器dataServer。

⑶dataServer检查这些资源标识，发现imag1在本地存在，这里只把本地不存在的资源标识(imag2，video1)返回给appServer。

这里，FTP服务器dataServer需要有一个退出机制，以防止数据量太大。另外需要有更新机制，以防止缓存的资源过期。

⑷appServer将返回标识的资源imag2，video1，打包，发送到dataServer上并得到所有资源在dataServer上的路径。

⑸appServer把资源路径返回给client1，client1根据路径去dataServer上下载这些资源。

⑹因为资源的数据量很大，因此下载将会比较耗时。这时，如果有网络异常，由于FTP支持断点续传，因此，在网络恢复后，client1仍然可以继续获取资源。

⑺这时候，又有另外的客户端client2请求相同的资源，在重复⑴、⑵步骤之后，appserver发现在dataServer上已经缓存了相关数据，只需要在soap消息中返回相应的路径，这样soap消息中则不需要再使用附件或者消息体来存储复杂数据了，soap消息的消长度也大大降低，从而减少了客户端和应用服务器之间通信的时间。这种做法也很大的提高了webService的网络传输的效率。

⑻同时，对于应用服务器appServer。则只需要把准备好的资源发送到数据服务器上，而且由于数据服务器上有缓存，极大的降低了在处理数据传输方面的压力。这样数据服务器和应用服务器明确分工。使得appServer能够专注于处理业务逻辑。

本发明的技术方案，根据ERP系统使用的实际场景进行分析，对通过web服务请求大对象数据的过程进行了优化。不再由业务服务器直接提供大对象给请求的客户端，而是构造大对象在数据服务器或者FTP服务器或者分布式缓存系统，只给远程的客户端提供资源路径，这样大大的缓解了业务服务器的压力。

同时数据服务器根据可以根据实际需要设置传输协议，比如FTP协议，这样即便遇到网络异常，也可以根据相应协议的具体机制来采取补救方法，比如FTP协议的断点续传等。

通过采用本发明的技术方案提供的这种方式，也提升了信息系统的灵活性，稳定性和效率，能应付更大压力的业务需求。

以上结合附图详细说明了本发明的技术方案，考虑到相关技术中没有简便的、统一的针对复杂类型webService中soap消息的效率优化的解决办法。现有的webService中soap消息的效率优化无法完成有复杂类型参与的webService中soap消息的效率优化过程。因此，本发明提出了一种webService中soap消息的效率优化装置和一种webService中soap消息的效率优化方法，可以在现有的webService中soap消息的效率优化方式基础上，充分利用单对象类型完成多对象类型webService中soap消息的效率优化，建立多对象类型参与的webService中soap消息的效率优化的通用、统一优化思路。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种webService中soap消息的效率优化装置，其特征在于，包括：

服务请求端，用于发出soap请求消息到业务服务器；以及，

用于在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源；

业务服务器，用于根据soap请求消息，准备业务数据，根据检查结果向客户端直接返回数据或向远程数据服务器传输资源标识；以及，

用于在收到远程数据服务器返回的资源路径时，直接返回给服务请求端；否则，将准备好的业务数据传输给远程数据服务器；

远程数据服务器，用于接收资源标识，检查本地是否已经缓存过这个资源，如果在本地发现资源，则直接返回资源路径；否则，返回给业务服务器响应，准备接收业务数据；以及，

用于在接收到业务数据后，进行存储，并返回资源路径给业务服务器。

2.根据权利要求1所述的webService中soap消息的效率优化装置，其特征在于，所述服务请求端，具体包括：

请求发送模块，用于发出soap请求消息到业务服务器；

资源路径获取及资源请求模块，用于在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源。

3.根据权利要求1所述的webService中soap消息的效率优化装置，其特征在于，所述业务服务器，具体包括：

业务数据准备模块，用于根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求；

检查结果执行模块，用于根据检查结果向客户端直接返回数据或向远程数据服务器传输资源标识；

资源路径接收及转发模块，用于在收到远程数据服务器返回的资源路径时，直接返回给服务请求端；

待发业务数据传输模块，用于在未收到远程数据服务器返回的资源路径时，将准备好的业务数据传输给远程数据服务器。

4.根据权利要求1-3中任一项所述的webService中soap消息的效率优化装置，其特征在于，所述远程数据服务器，具体包括：

资源标识接收及缓存信息检查模块，用于接收资源标识，检查本地是否已经缓存过这个资源；

缓存信息检查结果执行模块，用于在本地发现资源时，直接返回资源路径给业务服务器；以及，在本地未发现资源时，返回给业务服务器响应，准备接收业务数据；

业务数据接收、存储及返回资源路径模块，用于在接收到业务数据后，进行存储，并返回资源路径给业务服务器。

5.根据权利要求4所述的webService中soap消息的效率优化装置，其特征在于，所述业务服务器中的检查结果执行模块，具体包括：

直接返回数据子模块，用于在不需要远程数据服务器介入时，直接向服务请求端返回数据；

资源标识传输子模块，用于在需要远程数据服务器介入时，将相应资源的唯一标识传输给远程数据服务器，以检查是否需要对该资源重新存储；

和/或，

所述业务服务器中的业务数据准备模块检查待返回的数据是否满足向远程数据服务器存储托管的要求的操作，具体包括：

根据数据类型结构和web服务的业务含义，确定相应数据是否是可以进行数据存储的资源，并且需要设置阈值，只有在相应资源的大小高于该阈值的情况下，才对该资源进行远程的存储托管的处理；

和/或，

所述远程数据服务器中的缓存信息检查结果执行模块，具体包括：

资源路径返回子模块，用于在本地发现资源时，直接返回资源路径给业务服务器；

响应返回及业务数据准备接收子模块，用于在本地未发现资源时，返回给业务服务器响应，准备接收业务数据。

6.一种webService中soap消息的效率优化方法，其特征在于，包括：

步骤202：服务请求端即客户端发出soap请求消息到业务服务器；

步骤204：业务服务器根据soap请求消息，准备业务数据，检查待返回的数据是否满足向远程数据服务器存储托管的要求，根据检查结果进行处理。

7.根据权利要求6所述的webService中soap消息的效率优化方法，其特征在于，所述步骤204检查待返回的数据是否满足向远程数据服务器存储托管的要求的操作，具体包括：

根据数据类型结构和web服务的业务含义，确定相应数据是否是可以进行数据存储的资源，并且需要设置阈值，只有在相应资源的大小高于该阈值的情况下，才对该资源进行远程的存储托管的处理；以及，

所述步骤204根据检查结果进行处理的操作，具体包括：

步骤206：业务服务器根据检查结果向客户端直接返回数据。

8.根据权利要求6或7所述的webService中soap消息的效率优化方法，其特征在于，所述步骤204根据检查结果进行处理的操作，具体还包括：

步骤208：业务服务器根据检查结果向远程数据服务器传输资源标识，根据检查结果继续处理。

9.根据权利要求8所述的webService中soap消息的效率优化方法，其特征在于，所述步骤208根据检查结果继续处理的操作，具体包括：

步骤212：远程数据服务器接收资源标识，检查本地是否已经缓存过这个资源，如果在本地未发现资源，则返回给业务服务器响应，准备接收业务数据；

步骤216：业务服务器在未收到远程数据服务器返回的资源路径时，将准备好的业务数据传输给远程数据服务器；

步骤218：远程数据服务器在接收到业务数据后，进行存储，并返回资源路径给业务服务器；

步骤220：服务请求端在从业务服务器获得资源路径时，根据资源路径向远程数据服务器请求资源。

10.根据权利要求9所述的webService中soap消息的效率优化方法，其特征在于，所述步骤208根据检查结果继续处理的操作，具体还包括：

步骤210：远程数据服务器接收资源标识，检查本地是否已经缓存过这个资源，如果在本地发现资源，则直接向业务服务器返回资源路径；

步骤214：业务服务器在收到远程数据服务器返回的资源路径时，直接返回给服务请求端，然后执行步骤220。