CN102314358A - 一种在云平台上以soa的方式部署常规应用的方法 - Google Patents

Abstract

一种在云平台上以SOA的方式部署常规应用的方法，开发者无需学习新知识，就能开发云服务模式的应用系统，还能将大量已有的应用系统部署到云平台中。本发明介绍的方法主要包括：系统分析用户提交的配置文件和源程序，获取用户配置的服务类并生成对应的WSDL文件，接着生成对应的Stub服务调用代码，Stub服务调用代码向外提供服务调用的接口。接着将Stub服务调用代码添加到源程序包中，并自动更新客户类，将原先调用服务类的代码自动更新为调用Stub服务调用的代码，最后将应用与服务分别部署。利用本方法能大大提高云平台上应用系统部署的效率。降低新应用系统的开发成本，同时也减少了已有系统向云平台迁移的成本。

Description

一种在云平台上以SOA的方式部署常规应用的方法

技术领域

本发明涉及计算机应用技术领域，尤其涉及云平台中SOA与程序分析等方面的内容。

背景技术

云计算的核心思想是将大量用网络连接的计算资源统一管理和调度，构成一个计算资源池向用户或应用提供按需服务。云计算将所有的计算资源集中起来，并由软件实现自动管理，无需人为参与。这使得应用提供者无需为繁琐的细节而烦恼，能够更加专注于自己的业务，有利于创新和降低成本。

云计算的提出，虽然解决了单一服务器性能不足的问题，但也带来了多个计算资源之间的通信问题，SOA(Service Oriented Architecture)很大程度上解决了这一问题。SOA是一类分布式系统的体系结构，这类系统是将异构平台上应用程序的不同功能部件(称为服务)通过这些服务之间定义良好的接口和规范按松耦合方式整合在一起，即将多个现有的应用软件通过网络将其整合成一个新系统。

云计算提供强大的计算能力，SOA实现多个资源之间的调度。采用面向服务架构的云计算平台集这两种方式于一身，具有众多优点，如：实现大量计算资源的整合，凸显云计算的强大计算能力。将服务分发、部署到不同的服务器上，从而实现服务调度的负载均衡以及计算资源的并行利用。云计算平台能够预先集成众多云服务，方便应用系统的开发。服务开发与应用系统开发分开，使得需要开发者关心的部分互相之间松耦合，一方面解决了项目人员之间沟通难的问题，另一方面也简化了开发者的工作任务，提高了生产效率。

发明内容

本发明中所涉及的在云计算平台上以SOA的方式部署常规应用的方法及系统，解决了将大量已有系统(或者按照常规方式开发的应用系统)向基于SOA的云计算平台平滑迁移的诸多问题。其包含了以下几个方面的含义：

首先，用户部署源程序及配置文件，配置文件中记录了源程序中哪些类将以服务的方式运行，叫做服务类，其未包含在配置文件中的类叫做客户类。系统读取配置文件，并在内存中生成对应的服务类列表。

其次，系统自动更新客户类的代码结构，将原先调用服务类的部分转变为调用Stub服务调用代码，其中需要转变的部分包括与服务类相关的声明语句、方法调用语句及声明同时调用其方法的语句。

最后，将用户上传的源代码中与服务类相关的部分部署到服务容器中，将剩下的部分结合Stub服务调用代码一起部署到应用服务器中。

本发明提供一种在云计算平台上以SOA的方式部署常规应用的方法，包括下列步骤：

1)解析用户设定的配置文件，并在内存结构中生成一个服务类列表，方便通过服务类生成对应的WSDL文件及客户类代码的动态更新。

2)根据服务类列表中的信息，从用户部署的源代码文件中提取服务类，并生成相应的WSDL文件。

3)根据生成的WSDL文件产生对应的Stub服务代码，将Stub服务调用代码添加到用户部署的源文件中。

4)根据服务类列表，自动更新客户类，将与服务类相关的声明语句、方法调用语句等动态调整为与Stub服务调用相匹配的方式。

5)将源代码中与服务类相关的部分分别部署到不同的服务容器中，剩下的部分类结合Stub服务调用代码一起部署到应用服务器中。

其中，在所述步骤1)中，通过解析用户部署的配置文件，将用户配置的服务类在内存结构中构建一张对应的服务类别表。用户配置的服务类表示需要在云计算平台中以服务的方式运行，与调用它们的客户类区别开来。用户设定的配置文件格式是XML文件，服务类以namel-class对的形似存在。通过DOM技术即可完成XML配置文件的解析。

其中，在所述步骤2)中，首先根据服务类列表的内容，从用户上传的源文件中提取对应的服务类，接着使用工具(如java2wsdl命令)为每一个服务类生成对应的WSDL文件，整个过程由程序自动完成。

其中，在所述步骤3)中，首先根据生成的WSDL文件，使用工具(如wsdl2java命令)生成对应的Stub服务调用代码，wsdl2java并不是java2wsdl的逆向运算，而是产生对WSDL文件的封装代码。接着将产生的Stub服务调用代码嵌入源程序中，整个过程由程序自动完成。

其中，所述步骤4)中，自动更新客户类是通过动态分析客户类源程序，将与服务类相关的声明语句、方法调用语句以及声明同时调用其方法的语句动态调整为与Stub服务调用相匹配的方式。通过词法分析，定位到与服务类相关的语句，接着判断属于哪一类语句，如果是服务类声明语句，就更新服务类为Stub服务调用代码中相应类的声明语句。如果是服务对象方法调用语句，同样更新为对Stub服务调用相关的语句。如果是声明同时调用其方法的语句，按照前述两种方法分别完成更新，直到所有与服务类相关的语句更新完毕后结束，整个过程由程序自动完成。

其中，所述步骤5)中，应用系统的部署是分两部分完成的。一部分是服务，首先将服务自动转化为可部署部件，其中包含服务类本身和对应的部署描述文件。然后将服务部署到服务容器中。另一部分是与用户相关的应用部分，此部分部署到应用服务器中。

附图说明

图1为使用本发明前应用部署架构图。

图2为使用本发明后应用部署架构图。

图3为本发明方法原理示意图。

图4为更新客户类方法原理示意图。

具体实施方式

为使本发明的特征及优点得到更加清楚的了解，以下结合附图，做详细说明如下：如图1所示，常规应用是作为一个整体部署到应用服务器中的。这对应用服务器的性能提出了很高的要求，所有应用同时运行在一台服务器上，当部署的应用较多时，对CPU、存储等资源争夺将变得非常激烈，从而导致服务器性能下降，同时也影响所部署应用的正常运行。为了解决这一问题，提出了将应用系统以SOA方式部署到云计算平台的思想。云计算的核心思想是将大量用网络连接的计算资源统一管理和调度，构成一个计算资源池向用户或应用服务，虽然解决了单一服务器性能不足的问题，但也带来了多个计算资源之间的通信问题，SOA的引入很好的弥补了这一缺陷。将计算资源分为应用服务器和服务容器，这样就可以将大量耗时的逻辑处理及数据存取操作封装为服务，并运行在服务容器中。图2显示了使用本发明方法之后，常规应用部署到云计算平台以SOA方式运行示意图，如图所示，用户使用配置文件标注常规应用中哪些类需要以服务的方式运行，并结合应用本身一同部署到云计算平台上。接着，云计算平台将常规应用SOA化，将与用户交互相关的部分保留部署到应用服务器中，而将用户配置的服务通过云计算平台的分发机制部署到分散的服务容器中。使用这种方式部署常规应用将带来以下好处：应用服务器只运行与用户交互部分相关的应用，而将大量耗时的逻辑处理、数据存取移交服务容器中的服务执行，大大减少应用服务器的计算量，保证应用服务器能够良好的运行。将多个服务分发到不同的服务容器中，能够实现计算能力的负载均衡，同时支持多个服务的并行执行，提高了应用系统的整体性能。将逻辑处理、数据存取转换为服务的方式运行，通过服务共享实现逻辑处理、数据存取的复用。

如上所述，SOA非常适合云计算平台，直接采用SOA的方式开发应用并部署到云计算平台上是值得推崇的方式。但这一方面对开发者来说要求太高，难度较大，还需重新学习SOA相关的知识，另一方面也将已有的应用拒之门外，要想将已有的应用部署到云计算平台上，还要根据云计算平台的规定，采用SOA的方式重新开发，这无疑对人力、物力来说都是巨大的浪费。于是本发明提出一种在云计算平台上以SOA的方式部署常规应用的方法，旨在解决常规应用与云计算平台部署之间的鸿沟，同时能够将大量已有的应用部署到云计算平台中，免去了再次开发带来的成本。

以上阐述了在云计算平台上以SOA的方式部署常规应用方法的诸多优点，下面详细介绍该方法的实现原理，如图3所示，描述了实现该方法的详细步骤。

步骤一：通过读取配置文件，初始化服务类列表。配置文件采用XML(Extensive Makeup Language)的形式存储数据，其结构如下所示：

将XML文件转化为服务类列表的内存结构，服务类在XML文件中是以namel-class对的形式存在的。通过DOM技术即可完成XML配置文件的解析。

步骤二：根据步骤一中生成的服务类列表，在源文件中定位这些服务类，并使用java2wsdl命令将服务类生成对应的WSDL文件。具体用法如下：

java2wsdl-cp.-cn package.TestClassService-of TestClassService.wsdl

其中，-cp参数指定类路径，-cn表示类名称，-of表示输出文件名称。所以上述方法表示在当前类路径下，使用名为package.TestClassService的类生成名为TestClassService.wsdl的文件。TestClassService.wsdl跟package.TestClassService类一一对应，描述了package.TestClassService所包含的所有方法，也就是描述了与package.TestClassService服务进行交互时需要绑定的协议和信息格式。

步骤三：生成Stub服务调用代码。生成Stub服务调用代码并不是必须的，客户类直接访问WSDL文件也能够实现服务调用。但直接访问WSDL文件调用服务比较复杂，这为后面自动更新客户类提出了挑战。而使用wsdl2java命令可使用WSDL文件生成对应的Stub服务调用代码。客户类通过操作Stub服务调用代码实现服务调用，而不需要再与WSDL文件直接通信。Wsdl2java具体用法如下：

wsdl2java-uri TestClassService.wsdl-p package-s-ssi-o build/service

其中，-uri参数指定WSDL文件的路径，-p指定生成java程序代码的包名，-s指定产生的代码的服务调用方式为同步访问方式，-ssi指定产生服务实现的接口，-o指定产生程序代码的存放目录。执行此方法，将自动生成Stub服务调用代码。需要注意，wsdl2java并不是java2wsdl的逆向过程，java2wsdl是将真实的服务类生成对应的WSDL文件，即服务的详细描述文件。而wsdl2java是用于产生解析WSDL文件，产生调用实际服务的代码封装。也就是说，wsdl2java产生的Stub服务调用代码是通过WSDL文件调用实际的服务类执行相应操作的。而实际的服务类就是在java2wsdl命令中用于产生WSDL文件的类。

步骤四：更新客户类。如上所述，根据用户配置的服务类生成对应的WSDL文件，接着产生了对应的Stub服务调用代码。服务类和客户类最终将部署到不同的服务器上。他们之间通过Stub服务调用代码进行通信，即客户类通过Stub服务调用代码，调用实际服务类提供的逻辑处理。但用户提交的源文件中，客户类使用的还是直接对服务类的调用，这就产生了矛盾。解决这一问题的方法是动态更新客户类，将原先直接通过服务类实现的逻辑转变为通过Stub服务调用代码实现。通过分析，需要更新的地方包括三个方面，分别是：声明语句部分、属性&方法调用语句部分和声明同时包含方法调用的语句部分。具体更新过程如图4所示。

由于需要动态更新客户类，需要进行词法分析，从而标记哪些地方需要更新。词法分析采用有穷自动机实现，由于并不需要对每一个词都进行分析，因为所有需要更新的语句均在一个句子中，于是采用简化的词法分析方法，以句为单位进行分析，衡量句子的标准为‘{’、‘}’、‘；’字符。这样就得到了客户类代码中的每一个句子。

前面采用简化的词法分析方法，每一次产生一个句子。服务类语句定位就是在一个句子中定位服务类相关语句出现的地方，然后更新对应的客户类。服务类相关语句在客户类中有3种表现形式。它们分别是：

1)服务类声明语句。

2)服务类所声明的对象调用其方法的语句。

3)服务类声明的同时调用其方法的语句。

由于2)中可能并不出现服务类名称，而只是出现服务类所声明的对象，所以在整个系统中维持一个服务类与其对象名称的映射非常有必要，这样总能保证定位到服务类所声明的对象，因为对象在调用前必须声明，这恰好在1)中完成。

服务类相关语句定位以后，就需要对客户类进行动态更新。下面举例说明更新规则：

服务类声明语句，当服务定位到某个类包含在服务类列表中，并进行声明时，就需要进行更新，更新规则为：将服务类后面添加Stub字符串，表示一个新的类，这个类在Stub服务调用代码中。这个新类需要传入参数，使用已经配置好的url加上类名称定位到具体服务的地址即可。

举例说明如下：

更新前：

TestClassService tcs＝new TestClassService()；

更新后：

url＝base_url+″TestClassService″；

TestClassServiceStub tcs＝new TestClassServiceStub(url)；

其中，url和base_url为预先定义的变量，其中

url＝″″；

base_url＝″http://localhost:8080/axis2/services/″；

base_url指定了部署单个服务的地址，加上TestClassService表示完整的服务路径，而声明语句的变化仅仅只是在类名后面添加Stub字符串，TestClassServicestub就是自动生成的Stub服务调用代码中的类，封装了访问具体服务的细节。当更新完声明语句后，需要记录服务类及其映射对TestClassServiceStub-tcs。

服务类所声明的对象调用其方法的语句，此时更新规则为：根据方法调用的对象找出对应的服务类。然后在Stub服务调用代码中找出对应的与方法名、方法返回值相关的类，并为方法名所对应的内设置属性，属性名为方法声明中参数名的首字母大写。通过前面找出的类与属性，声明方法名对应的类、设置属性、声明方法返回值对应的类并使用前面声明的Stub对象调用方法并将结果返回给返回值对应的类，通过返回值对应的类即可获得实际的值。举例说明如下：

更新前：

int s1＝tcs.add(10，20)；

更新后：

TestClassServiceStub.Add add＝new TestClassServiceStub.Add()；

add.setl1(10)；

add.setl2(20)；

TestClassServiceStub.AddResponse addResponse＝tcs.add(add)；

int s1＝addResponse.get_return()；

方法调用语句的语义是传入两个参数，分别为10和20，并调用服务类所声明的对象tcs的add方法处理参数，并将处理结果存入s1中。I1是方法类的属性，也即是服务类add方法的参数。

服务类声明的同时调用其方法的语句，更新规则是前面两种情况的总和，更新方法基本不变，只是服务类声明为对象的名称上做了小的变更，为了避免重名，采用服务类名首字母小写加上一个全局递增的整型变量。最后也需要记录服务类及其映射对TestClassServiceStub-testClassServiceStub1。举例说明如下：

更新前：

int s5＝new TestClassService().sub(20，10)；

更新后：

TestClassServiceStub testClassServiceStub1＝

new TestClassServiceStub(base_url+″TestClassService″)；

TestClassServiceStub.Sub sub＝new TestClassServiceStub.Sub()；

su b.setl1(20)；

sub.setl2(10)；

TestClassServiceStub.SubResponse subResponse＝testClassServiceStub1.sub(sub)；

int s5＝subResponse.get_return()；

步骤五：系统部署。系统部署包含两个部分，一部分是服务的部署，另一部分是客户类的部署。客户类的部署跟传统应用系统部署没有区别，只需要复制到应用服务器相应的目录下即可，如Tomcat下的webapps目录下。服务的部署相对繁琐一些，首先需要为服务类生成匹配的描述配置文件services.xml，然后打包成一个整体文件(*.aar)发布。Services.xml配置文件由系统自动生成，其文件格式如下：

自动生成完services.xml后，将其放入/tmp/META-INF/目录下，接着将源文件生成的二进制文件拷贝到/tmp目录下，最后通过jar命令生成相应的服务部署文件，jar命令使用如下所示：

cd/tmp

jar cvf TestClassService.aar.

首先进入/tmp目录，然后将当前目录下的所有文件打包成TestClassService.aar，最后将TestClassService.aar复制到服务容器下相应的目录即可。当使用Axis作为服务运行容器时，其目录为：AXI_HOME/WEB-INF/services。

以上所述的内容对本发明方法的各个步骤作了详细的说明，但是本发明的具体实现形式并不局限于此，对于本技术领域的一般技术人员来说，在不背离本发明所述方法的精神和权利要求范围的情况下对它进行的各种显而易见的改变都在本发明的保护范围之内。

Claims (10)

1.一种在云平台上以SOA的方式部署常规应用的方法，其特征在于，其包括以下步骤：

1)解析用户设定的配置文件，并在内存结构中生成一个服务类列表；

2)根据服务类列表中的信息，从用户部署的源代码文件中提取服务类，并生成相应的WSDL文件；

3)根据生成的WSDL文件产生对应的Stub服务代码，将Stub服务调用代码添加到用户部署的源文件中；

4)根据服务类列表，自动更新客户类，将与服务类相关的声明语句、方法调用语句等动态调整为与Stub服务调用相匹配的方式；

5)将源代码中与服务类相关的部分分别部署到不同的服务容器中，剩余部分结合Stub服务调用代码一起部署到应用服务器中。

2.如权利要求1所述的方法，其特征在于：在所述步骤1)中，通过解析用户部署的配置文件，将用户配置的服务类在内存结构中构建一张对应的服务类列表，用户配置的服务类表示需要在云计算平台中以服务的方式运行，与调用它们的客户类区别开来。

3.如权利要求1所述的方法，其特征在于：在所述步骤2)中，首先根据服务类列表的内容，从用户上传的源文件中提取对应的服务类，接着为每一个服务类生成对应的WSDL文件。

4.如权利要求1所述的方法，其特征在于：在所述步骤3)中，首先根据生成的WSDL文件，生成对应的Stub服务调用代码，接着将产生的Stub服务调用代码嵌入源程序中。

5.如权利要求1所述的方法，其特征在于：所述步骤4)中，通过词法分析，定位到与服务类相关的语句，接着判断属于哪一类语句，然后根据对应的转化规则更新相应的服务类为Stub服务调用代码，完成客户类的更新。

6.如权利要求2所述的方法，其特征在于：用户设定的配置文件格式是XML文件，服务类以namel-class对的形式存放，通过DOM技术完成XML配置文件的解析。

7.如权利要求5所述的方法，其特征在于：其转换规则包含三个部分，分别是声明语句的转化规则、方法调用语句的转化规则以及声明同时调用方法语句的转化规则。

8.如权利要求7所述的方法，其特征在于，所述声明语句的转化规则为：将服务类后面添加Stub字符串，表示一个新的类，这个类在Stub服务调用代码中，这个新类需要传入参数，使用已经配置好的url加上类名称作为参数，表示具体服务的地址。

9.如权利要求7所述的方法，其特征在于，所述方法调用语句的转化规则为：根据方法调用的对象找出对应的服务类；然后在Stub服务调用代码中找出对应的与方法名、方法返回值相关的类，并为方法名所对应的内设置属性，属性名为方法声明中参数名的首字母大写；通过前面找出的类与属性，声明方法名对应的类、设置属性、声明方法返回值对应的类并使用前面声明的Stub对象调用方法并将结果返回给返回值对应的类，通过返回值对应的类即可获得实际的值。

10.如权利要求7所述的方法，其特征在于，所述声明同时调用方法语句的更新规则是前面两种情况的总和，更新方法基本不变，只是服务类的声明时需做较小变更，为了避免重名，采用服务类名首字母小写加一个全局递增的整型变量作为新的对象名。

Images