CN102253999A

CN102253999A - 一种服务依赖性的验证方法

Info

Publication number: CN102253999A
Application number: CN2011101941738A
Authority: CN
Inventors: 陈春松
Original assignee: Beijing Feinno Communication Technology Co Ltd
Current assignee: Beijing Feinno Communication Technology Co Ltd
Priority date: 2011-07-12
Filing date: 2011-07-12
Publication date: 2011-11-23
Anticipated expiration: 2031-07-12
Also published as: CN102253999B

Abstract

本发明公开了一种服务依赖性的验证方法。该方法中通过预先定义一定的数据结构，然后根据所定义的数据生成服务依赖树，再验证服务依赖树的方式对服务的依赖性进行验证。本发明的技术方案能对服务的依赖性进行有效的验证。

Description

一种服务依赖性的验证方法

技术领域

本发明涉及计算机技术领域，特别是涉及一种服务依赖性的验证方法。

背景技术

在互联网时代，消费者对虚拟服务的需求日益提高，服务提供商对新服务的快速响应能力是吸引消费者，提高消费者忠诚度的重要指标。

因此快速开发、快速部署服务是提高竞争力的重要条件。随着服务的数量越来越多，依赖关系(服务与服务之间，服务于第三方库之间)会越来越复杂，其复杂程度会超出一个人所能控制的范畴。如何确保度服务和第三方库的每一次修改都不会引起系统的不兼容性，从而导致服务的不可用，是服务开发、部署面临的首要问题。

因此如何实现服务依赖性的验证是服务开发过程的重要步骤。

发明内容

本发明提供了一种服务依赖性的验证方法，该方法能对服务的依赖性进行有效的验证。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种服务依赖性的验证方法，该方法包括：生成服务依赖树，验证服务依赖树；

所述生成服务依赖树包括：

创建一个用于存放节点头对象的节点头集合；创建一个用于存放需要验证的节点对象的节点列表；创建一个用于存放依赖树中的节点的节点集合；

其中，节点头对象包括：节点的类型、节点的标示、节点的最小版本号、节点的最大版本号、要求的版本号、节点的所有版本号；

JDK节点对象包括：节点的类型、节点的标示、节点的版本号；

共享库节点对象包括：节点的类型、节点的标示、节点的版本号、JDK节点、上游共享库节点、下游共享库节点、上游服务节点；

服务节点对象包括：节点的类型、节点的标示、节点的版本号、JDK节点、下游共享库节点、上游服务节点、下游服务节点；

初始时，为待验证的服务生成对应的节点对象，并放入节点列表和节点集合中，然后执行如下的步骤：

步骤11，判断节点列表是否为空，是则结束流程，否则从节点列表中取出一个节点对象作为当前节点对象，并将该节点对象从节点列表中删除；

步骤12，为当前节点对象在节点头集合中维护其对应的节点头对象；

步骤13，判断当前节点对象是否为JDK节点对象，是则返回步骤11，否则继续执行后续步骤；

步骤14，找出当前节点对象所依赖的JDK，并对找到的每个JDK做如下处理：从节点集合中查找该JDK对应的JDK节点对象，如果不存在，则生成对应的JDK节点对象，添加到节点列表和节点集合中；

步骤15，找出当前节点对象所直接依赖的共享库，并对找出的每个共享库做如下处理：从节点集合中查找与该共享库对应的共享库节点对象，如果不存在，则生成对应的共享库节点对象，添加到节点列表和节点集合中；

步骤16，判断当前节点对象是共享库节点对象还是服务节点对象，如果是共享库节点对象，则执行步骤17，如果是服务节点对象，则执行步骤18；

步骤17，找出该共享库节点对象的其他所有版本，对每个版本做如下处理：如果该版本被其他服务直接依赖，则生成该版本对应的节点头对象，添加到节点头集合中；如果该版本没有被其他服务直接依赖，则找出直接或间接依赖该版本的其他共享库，如果找出的这些共享库被其他服务直接依赖，则生成该版本对应的节点头对象，添加到节点头集合中；返回步骤11；

步骤18，找出该服务节点对象直接依赖的所有其他服务，对找出的每个服务做如下处理：从节点集合中查找与该服务对应的服务节点对象，如果不存在，则生成对应的服务节点对象，添加到节点列表和节点集合中；将找到的服务节点作为当前节点的下游服务节点，写入当前节点对象中；返回步骤11；

所述验证服务依赖树包括：

步骤21，创建验证信息列表；

步骤22，按照服务、共享库、JDK的顺序对节点头集合中的节点头对象进行轮询，对于每个节点头对象进行如下处理：如果节点的最小版本号和节点的最大版本号不一致，则将该节点头对象放入验证信息列表中；

步骤23，如果验证信息列表为空，则验证结果为版本一致；如果验证信息列表不为空，则验证结果为版本不一致。

由上述可见，本发明这种通过预先定义一定的数据结构，然后根据所定义的数据生成服务依赖树，再验证服务依赖树的方式对服务的依赖性进行验证的技术方案，能对服务的依赖性进行有效的验证。

附图说明

图1是本发明实施例中的服务开发框架示意图；

图2是本发明实施例中的具体的节点关系的示意图；

图3是本发明实施例中的一种共享库管理方法的流程图；

图4是本发明实施例中的一种服务开发方法的流程图；

图5是本发明实施例中的生成服务依赖树的流程图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

在本发明的方案中，所有的开发以服务为基础，开发人员将专注于服务逻辑的开发，而较少关注其它相关服务的状态。

在本发明的方案中，服务开发将遵循以下规则：

●服务作为最小的开发粒度，不同的服务将在开发中以合理的方式进行隔离。

●服务作为最小的编译粒度，参考服务的依赖关系，服务应该是可单独编译的。

●服务作为最小的打包粒度，以真正实现服务级的热更新。

●服务作为最小的部署粒度。

图1是本发明实施例中的服务开发框架示意图。在图1中，各个部分的描述如下：

●开发人员

●用来开发服务

●管理人员

●用来查看、监测服务的各种信息。

●服务开发环境

●用来快速开发服务

●创建服务，并产生服务描述信息。

●产生服务代码框架，应用服务编码规则。

●查询现有服务

●编译、打包、发布服务

●验证服务一致性

●浏览器

●管理人员用来通过web服务器浏览服务信息。

●服务包

●Jar包，用来发布服务

●版本控制服务器

●用来保存服务代码，服务发布包

●应用服务器

●用来运行服务

●服务信息数据库

●保存服务描述信息

●保存服务依赖信息

●保存服务运行日志

●Web服务器

●实现服务的查询、监测。

服务要正常运行，必须依赖其他资源，一般情况下，其依赖可以有以下几类：

●JDK依赖

●共享库依赖

●第三方包依赖

●共享服务依赖

●公共服务依赖

●工具服务依赖

●业务服务依赖

●兄弟服务依赖

可见服务正常运行可能依赖的包有JDK和共享库，其中，共享库包括：第三方包和共享服务；所述共享服务又包括：公共服务、工具服务、业务服务。

除了对包的依赖，服务还有对协议、标准的依赖。但一般情况下，对协议、标准的依赖可以最终转换成对协议、标准实现包的依赖，因为特定版本的协议、标准实现包一定对应一定版本的协议、标准，因此对协议、标准的依赖性就可以间接表示成对包的依赖性

图2是本发明实施例中的具体的依赖关系的示意图。由图2可以看出JDK不依赖于其他任何包。

接下来对本发明中如果管理被依赖的JDK和共享库，以便其他服务能快速、一致地引用进行说明。

图3是本发明实施例中的一种共享库管理方法的流程图。如图3所示，包括：

301，将JDK的文件上传到版本控制服务器的指定位置，将共享库的文件上传到版本控制服务器中的对应共享库类别的存放位置下。

302，将JDK的描述信息保存到信息数据库中。

其中，JDK的描述信息包括：JDK的标示和JDK在版本控制服务器上的存放位置；

303，将共享库描述信息和共享库依赖信息保存到信息数据库中。

其中，所述共享库的描述信息包括：共享库的类别信息、共享库信息、具体版本的共享库信息、具体版本的共享库包含的文件信息、具体版本共享库的属性信息；其中共享库的类别信息中包含共享库在版本控制服务器中的位置信息；

所述共享库的依赖信息包括：共享库的库标示和被依赖的共享库的库标示；

304，当需要获取指定JDK时，先到信息数据库中查找对应的描述信息，根据描述信息从版本控制服务器获取该指定JDK的文件。

305，当需要获取指定共享库时，先到信息数据库中查找对应的共享库描述信息和共享库依赖信息，根据共享库描述信息从版本控制服务器获取该指定共享库的文件，根据共享库依赖信息获取被该指定共享库所依赖的其它包的文件。

下面对为实现JDK和共享库的合理管理，在信息数据库上保存这些信息时所采用的数据结构进行说明：

1.JDK

为公司需要支持的JDK版本建立一个库，所有的第三方包，共享服务包，以及属于一个产品的服务都必须显示指定其所依赖的最小的JDK版本。

一个JDK的描述(jdk_version)信息如表1所示：

字段名称	字段说明	数据类型	主键	可否为空	默认值和备注
						JdkVersionld	Jdk版本标示	Int	PK	N	自增长字段
JdkVersion	Jdk版本	Varchar(10)		N
						Repository	存放位置	Nvarchar(256)		N

表1

备注：在JdkVersionId上建立唯一索引。

表1中，存放位置是指JDK在版本控制服务器上的存放位置。

2.共享库

共享库是需要在全局范围内共享使用的包，包括：

●第三方包依赖

●共享服务依赖

●公共服务依赖

●工具服务依赖

●业务服务依赖

一旦一个包进入共享平台，其他开发人员就能迅速地找到并使用该服务，从而有效地避免重复开发、无序使用的问题

所有共享库将通过一套相同的数据结构管理起来。在本发明中，共享库按类别进行区分。共享库的类别(lib_id_mask，shared_lib_category)信息如表2和表3所示。

表2

备注：

●CategoryId用分区编码的方式来产生库类型标示

XXX XXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 库标示库版本

一般而言：

●Level 1：可以定义三大类：系统级、第三方、本公司

以后的类别，可以根据不同的大类进行各自分级，虽然上面给出的编码中显示每个类别的编码格式一样，但实际运用中，可根据不同的情况，对不同的类别进行不同的分区编码。

可见在本发明的实施例中，类别标示由64个比特组成，其中1-3比特表示第一级类别、4-8比特表示第二级类别、9-16比特表示第三级类别、17-24比特表示第四级类别、25-32比特表示第五级类别、第33-48比特表示第六级类别、第49-56比特表示库标示、第57-64比特标示库版本。

表3

备注：

●在Parent上建立外部键，引用字段是：lib_category.CategoryId

●CategoryId用分区编码的方式来产生库类型标示

XXX XXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 库标示库版本

一般而言：

●Level 1：可以定义三大类：系统级、第三方、本公司

●以后的类别，可以根据不同的大类进行各自分级，虽然上面给出的编码中显示每个类别的编码格式一样，但实际运用中，可根据不同的情况，对不同的类别进行不同的分区编码。

Repository：指向该共享库类别在版本控制服务器中的存放位置。

共享库(share_lib)信息如表4所示：

表4

备注：

●LibName：必须用英文字母、数字、下划线、连线字符等。

该共享库在版本控制服务器中的存放位置是该共享库所属类别的存放位置下的子目录，子目录名称为“LibName”。

具体版本的共享库(share_versioned_lib)信息如表5所示：

表5

备注：

●LibName：必须用英文字母、数字、下划线、连线字符等。

该共享库在版本控制服务器中的存放位置是该共享库所属类别的存放位置下的子目录，子目录名称为“LibName”。该共享版本的所有版本都存放在该位置的一个子目录下。子目录名称直接采用版本号。

具体版本的共享库包含的文件(share_versioned_lib_file)信息如表6所示：

表6

具体版本共享库的属性(share_versioned_lib_property)信息如表7所示：

表7

备注：

●Seq：当属性值太大时，一个属性值可能需要多行来保存数据，这是候用Seq来表示顺序。大部分情况，属性值都可以用一行表示，这种情况下，Seq总是为1。

共享库的依赖(share_versioned_lib_depedency)信息如表8所示：

表8

在本发明的实施例中，第三方包的具体依赖又可分为两大类：系统级和第三方。

系统级表现为属于java标准的一些包，比如j2ee等。

系统级包对应的类别标示将采用以下规则：

XX X XXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 库标示库版本

Level1：001表示系统库

Leve2：表示系统库对应的领域，比如

■00001：http

■00010：ejb

■00011：xml

■00100：jms

■00101：jdbc

Level3：不用

Level4：不用

Level5：不用

Level6：不用

库标示：库名称

库版本：具体版本的库

第三方包对应的类别标示将采用以下规则：

XX X XXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 库标示库版本

Level 1：010表示第三方包

Level2：表示第三方包对应的领域，比如

00001：http

00010：xml

00011：jdbc

00100：rpc

Level3：细分领域

Level4：进一步细分领域

Level5：更精伊布细分领域

Level6：实现类型

库标示：库名称

库版本：具体版本的库

在本发明的实施例中，

共享服务依赖是指依赖公司开发的、且发布到共享平台的服务。

共享服务有三种类型

公共服务：不支持热插拔功能。

工具服务：支持热插拔功能，具有服务接口和多个服务方法。

业务服务：支持热插拔功能，具有服务接口和多个服务方法。对工具服务、业务服务，提供服务方法的详细描述，以方便客户端的共享。

也就是说工具服务和业务服务的描述信息还包括：方法信息。

一个具体版本共享库(工具服务或业务服务)的方法信息如表9所示：

表9

前面介绍的信息数据库中保存的信息的数据结构。基于上述数据结构可以对共享库进行新增、废弃、删除、展示以及获取等操作。具体介绍如下。

本发明的方案实现对企业共享库的一致性管理，该共享库包括第三方的共享库和公司自己开发的共享服务；具体功能包括：

增加共享库类别。

增加共享库

上传特定版本的共享库

废弃特定版本的共享库

删除特定版本的共享库

验证特定版本的共享库依赖性

展示特定版本的共享库依赖性

1.增加共享库类别

在共享库类别中增加一条记录；增加时，必须指定以下信息：类别名称、类别描述、父类别

2.增加共享库

在共享库类别中增加一条记录；增加时，须遵循以下步骤：

1)找到该共享库的类别，如果不存在，则创建它。

2)创建该共享库，

a)库名称

b)库描述

c)库类型

d)库提供商

e)库的官网

f)引入原因

3)对需要上传的特定版本共享库，并提供以下信息

a)包版本

b)该版本的兼容版本号

c)该版本的描述

d)需要的jdk版本

e)上传原因

f)服务标示(如果该服务是公司自己开发的共享服务，则需要标示)

g)许可类型

4)上传共享库文件到版本控制服务器，同时对每一个文件提供以下信息

a)文件类型

b)文件名

5)如果该库有一些特殊属性，则需要将特殊属性一一配置；特别是对企业内部开发的共享服务，经常需要一些属性来简化开发。

a)属性名称

b)属性类型

c)属性值

6)如果该库依赖了其他共享库，则检查每一个共享库，如果该共享库以及依赖的共享库版本已经存在，则不需要处理该共享库；否则

a)如果共享库不存在，则必须按照增加共享库的逻辑增加该依赖的共享库以及共享库版本；

b)如果共享库存在，但依赖的版本不存在，则必须按照增加共享库版本的逻辑增加该依赖的共享库版本。

3.增加具体版本的共享库

为共享库增加一个共享库版本，增加时，遵循以下步骤：

1)找到该共享库

2)对需要上传的特定版本共享库，提供以下信息：

a)包版本

b)该版本的兼容版本号

c)该版本的描述

d)需要的jdk版本

e)上传原因

g)License类型

3)上传共享库文件到版本控制服务器，同时对每一个文件提供以下信息：

a)文件类型

b)文件名

4)如果该库有一些特殊属性，则需要将特殊属性一一配置；特别是对企业内部开发的共享服务，经常需要一些属性来简化开发。

a)属性名称

b)属性类型

c)属性值

5)如果该库依赖了其他共享库，则检查每一个共享库，如果该共享库以及依赖的共享库版本已经存在，则不需要处理该共享库；否则

4.废弃特定版本的共享库

即标示一个特定版本的共享库为废弃状态；标示后，以后的服务将不能再引用该库。但已经存在的引用则可以继续引用。

废弃步骤很简单：

1)找到需要废弃的共享库的特定版本。

2)点击“确认”。

3)系统将找出依赖(直接和间接)该共享库的其他所共享库(第三方共享库，共享服务)；而且如果共享库管理和面向服务的共享开发一起使用，则同时找出依赖该共享库的其他正在开发的服务。并将它们显示出来。

4)用户检查后，可以点击“取消”，来取消该次操作；也可选择“确认”，来继续废弃该版本。

5.删除特定版本的共享库

即删除一个特定版本的共享库；删除后，该版本将不再存在。

废弃步骤很简单：

1)找到需要废弃的共享库的特定版本。

2)点击“确认”。

4)如果存在依赖的其它共享库和正在开发的服务，则直接退出；否则，显示“取消”按钮，让用户取消该次操作；显示“确认”按钮，让用户继续删除。

6.展示特定版本的共享库依赖性

对一个特定版本的共享库，用图形方式展示其所有的依赖关系，包括在上下游依赖链中，所有服务、共享库的完整依赖关系。

7.获取一个共享库

当一个服务需要从共享库中获取一个第三方包或共享服务时，遵循以下步骤：

1)找到该第三方包或者共享服务的具体类别。

2)系统显示该类别下的所有共享库，以及相关信息。

3)如果该系统和面向服务开发一起使用，则系统将查询该服务的兄弟服务是否依赖了相同共享库类别中的共享库，如果依赖了，则将依赖的共享库选中，作为这次依赖的共享库以及共享库版本。跳过第4)、5)步骤，直接运行第6)步；

4)如果没有预先选好的共享库及其版本，则选择一个共享库。然后，系统列出选择的共享库中的所有版本，用户进一步选择共享库版本。

5)用户点击“确认”，系统将验证选择的共享库的特定版本与服务的依赖性是否兼容，如不兼容，则提示错误信息，然后返回第4步。

6)系统将找到共享库在版本控制服务器中的路径，自动从版本控制服务器中下载这些文件。当然如果与maven合作，则可以在pom文件中，生成对该版本的共享库的依赖。

前面介绍了共享库以及共享库的管理，接下来基于前述的共享库的基础上介绍本发明中的服务开发的过程。

本发明中的开发过程与规范建立在服务的基础之上，因此如何定义、鉴别一个服务是该开发过程与规范的基石。

作为该开发过程与规范下的服务可以从两个方面来定义：

●服务的可描述性。

●服务依赖性申明；一个服务依赖的所有其他组件，包括jdk、

第三方组件、公司自己开发的类库、以及其他服务都必须申明。

本发明中的面向服务的开发理念，用面向服务的方式来设计系统，使得一个系统能像搭积木似的搭建起来。但在开发过程中，开发人员却没有一个合适的环境来开发服务，就像工人没有特定的工厂、模具来生产积木一样，靠纯手工方式生产出来的服务，无法确保服务的高产出、高标准、高质量，进而影响由这种服务搭建的系统的稳定性和健壮性。

图4是本发明实施例中的一种服务开发方法的流程图。如图4所示，该方法包括：

401，定义服务的基本信息；其中，服务的基本信息包括：服务类别信息、服务类别属性信息、服务信息、服务属性信息、服务方法信息、服务依赖信息；

402，定义服务的边界，具体为：为服务所包含的累、配置文件和属性文件定义边界；

403，定义服务的客户端标示；服务的客户端标示用于标示被客户端用到的类；

404，对服务的依赖性进行验证。

下面对图4所示方法中提到的如果定义服务的描述，即定义服务的基本信息、服务的边界和服务的客户端标示进行一一说明。

1.服务的基本信息

服务的基本信息包括：服务类别信息、服务类别属性信息、服务信息、服务属性信息、服务方法信息、服务依赖信息；在本发明中的开发过程与规范中用下列数据结构存放服务的基本信息。

服务类别信息(service_category)的数据结构如表10所示：

表10

备注：

●CategoryId采用分段编码的方式来定义服务类型标示，用该方式的好处在于，通过一个CategoryId就可以知道该类别的父类别标识。

其具体规则如下：

CategoryId采用64位长整型，每个bit位按如下方式分配

XXXX XXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX 0000000 0000000 0 000000000

产品线产品项目项目代码线服务类别1 服务类别2 服务标示

具有如下约束

●只支持6级类别，分别为

●产品线：支持15个产品线

●产品：支持15个产品

●项目：支持255个项目

●项目代码线：支持255个项目代码线

●服务类别1：支持255个子服务类别

●服务类别2：支持255个子服务类别

●每个类别下支持16,777,215个服务。

●在字段Parent上建立外部健，引用的字段是

service_category.CategoryId

服务类别属性(service_category_property)信息的数据结构如表11所示：

字段名称	字段说明	数据类型	主键	可否为空	默认值和备注
						Categoryld	服务类型标示	long	PK	N
PropertyName	属性名称	varchar(30)	PK	N
						Seq	服务类型序列号	Int	PK	Y
PropertyType	属性类型	Varchar(128)		N	属性的类型
						PropertyValue	属性值	nvarchar(256)		N

表11

备注：

●目前预留的属性名有

●Interface：对应于该类别的接口，该类别下的服务必须继承或实现该接口

●InterfaceMetaData：接口的注解、父类、形参。

●Workspace：对应的工作室

●Project：对应的项目

●VcsPath：指明对应文件在版本控制服务器中的位置。

服务(service)信息的数据结构如表12所示：

表12

备注：

●ServiceCategory，ServiceName能唯一标示一个服务。

●在ServiceCategory上建立外部键，引用字段是：

service_category.CategoryId

●ServiceId的产生方式是：利用表中service_category字段

sequence产生一个属于该服务类别的服务标示，然后加上服务类别标示构成ServiceId。

ServiceId采用分段编码的方式来定义服务类型标示，用该方式的好处在于，通过一个CategoryId就可以知道该类别的父类别标识。

其具体规则如下：

CategoryId采用64位长整型，每个bit位按如下方式分配

XXXX XXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX 0000000 0000000 0 000000000

产品线产品项目项目代码线服务类别1 服务类别2 服务标示

具有如下约束

●只支持6级类别，分别为

●产品线：支持15个产品线

●产品：支持15个产品

●项目：支持255个项目

●项目代码线：支持255个项目代码线

●服务类别1：支持255个子服务类别

●服务类别2：支持255个子服务类别

●每个类别下支持16,777,215个服务。

●Version，服务的版本号，服务的版本号由三部分组成：版本号：3位；次版本号：3位：微版本号：3位；在表现上，版本号的格式为：2.01.12；但在存储的时候，将版本号变成一个整型，目的是为了方便版本之间的比较。相关的计算公式如下：

●版本号到整形：主版本号*1000000+次版本号*

1000+微版本号；

●整形到版本号：

●主版本号＝版本号/1000000

●次版本号＝(版本号-主版本号*1000000)/1000

●微版本号＝版本号-主版本号*1000000-次版本

号*1000

●格式化逻辑为：主版本号+“.”+次版本号/

(float)1000+“.”+微版本号/(float)1000

服务属性(service_property)信息的数据结构如表13所示：

表13

备注：

●在ServiceId上建立外部键，引用字段是：service.S erviceId服务方法(service_method)信息的数据结构如表14所示：

表14

所述服务依赖信息的包括：服务的共享库依赖信息和服务对其它服务的依赖信息；

服务的共享库依赖信息(service_share_lib_depedency)的数据结构如表15所示：

表15

备注：

●在ServiceId上建立外部键，引用字段是：service.ServiceId

●在DependentVerLibId上建立外部键，引用字段是

share_versioned_lib.VersionedLibId

服务对其它服务的依赖信息(service_service_depedency)的数据结构如表16所示：

备注：

●在ServiceId上建立外部键，引用字段是：service.ServiceId

●在DependentServiceId上建立外部键，引用字段是service.ServiceId

2.服务的边界定义

服务边界定义用来为服务所包含的类、配置文件、属性文件等定义一个清晰的边界，该边界定义必须具有两个特点：

●可读性；开发人员或其他人员根据该定义可以清晰的定位出该服务包含的所有信息。

●可计算性；能够以程序逻辑来判断服务的边界，从而实现面向服务的开发视图、以及面向服务的编译、打包。

为此，定义一个服务边界接口来帮助开发环境找出服务包含的所有信息，在具体实现时，可以根据不同的用户场景，提供特定的实现类。

在本发明的一个实施例中，以java包作为分割策略进行服务的边界定义，这能够很好满足要求，该策略具有以下特点

●所有服务的源代码和测试代码放在相同的位置。

●每个服务有个单独的java包，该包以及其子包将包含该服务的所有源代码和测试代码；

●每个服务有个单独的java包，该包以及其子包将包含该服务的所有测试代码；

●服务与服务对应的java包必须是并行的，不能有任何嵌套关系。

将每个服务的测试数据、资源和配置文件都存在不同的子目录中：

●每个服务的测试数据都在java项目的测试数据根目录下的子目录中，子目录名称为服务的名称；

●每个服务的资源都在java项目的资源根目录下的子目录中，子目录名称为服务的名称；

●每个服务的配置文件都在java项目的配置目录下的子目录中，子目录名称为服务的名称。

3.服务的客户端标示

服务客户端标示用来标示哪些类需要被客户端用到。这个信息将被打包工具访问来为服务生成满足各种需求的包：

●客户端stub包

●服务接口，以及接口的集成类和实现类

●服务异常，被服务接口抛出的、需要客户端处理的异常

●传入参数类。

●结果返回类。

●服务变种选择类

●服务端包

●服务javadoc

在本发明的一个实施例中，利用java注解的方式来标注哪些类是客户端的类：

package com.feinno.soa.devenv.annotation；

Retention(RetentionPolicy.RUNTIME)

Target(ElementType.TYPE)

public interface StubClass{}

该注解是一个标示注解，没有任何属性。

服务依赖性的验证

在本发明中，对服务的依赖性进行验证为：对服务以及其所依赖的所有其它服务、共享库和JDK的版本是否一致或兼容进行验证；

对服务的依赖性进行验证具体包括：JDK版本冲突验证、服务版本冲突验证、共享库版本冲突验证。

服务依赖性的验证包括：生成服务依赖树，验证服务依赖树。

生成服务依赖树需要以下数据结构：

由上述可见：

节点头对象包括：节点的类型、节点的标示、节点的最小版本号、节点的最大版本号、要求的版本号、节点的所有版本号；

服务节点对象包括：节点的类型、节点的标示、节点的版本号、JDK节点、下游共享库节点、上游服务节点、下游服务节点。

基于上述定义的数据结构，本发明中的生成服务依赖树的过程如图5所示。

图5是本发明实施例中的生成服务依赖树的流程图。如图5所示，包括以下步骤：

501，创建一个用于存放节点头对象的节点头集合；创建一个用于存放需要验证的节点对象的节点列表；创建一个用于存放依赖树中的节点的节点集合。

本步骤中，创建节点头集合具体为创建一个Set<NodeHeader>，创建节点列表具体为创建List<Node>，创建节点集合具体为创建Set<Node>。

502，为待验证的服务生成对应的节点对象，并放入节点列表和节点集合中。

本步骤中，具体是为需要验证的服务生成相应的Node对象，并将之放入List<Node>和Set<Node>中，同时将其变成rootNode。

503，判断节点列表是否为空，是则结束流程，否则从节点列表中取出一个节点对象作为当前节点对象，并将该节点对象从节点列表中删除。

本步骤中，如果List<Node>为空，则退出整个服务依赖树生成逻辑；否则从List<Node>中取出一个Node对象作为下一个需要处理的对象，并将该Node对象从List<Node>中删除。

504，为当前节点对象在节点头集合中维护其对应的节点头对象。

如果其对应的节点头对象在节点头集合中已存在，且需要验证的服务的版本信息已经包含在节点头对象中，则返回步骤11；

如果其对应的节点头对象在节点头集合中已存在，但需要验证的服务的版本信息不包含在节点头对象中，则执行后续步骤；

如果其对应的节点头对象在节点头集合中不存在，则生成对应的节点头对象，添加到节点头集合中，执行后续步骤。

具体为：

a.如果该节点头对象在Set<NodeHeader>中存在，且需要验证的服务的版本信息，已经包含在头对象中，则表示该服务的依赖性已经被处理，则跳过对该服务的验证，转到步骤503，进行下一节点的处理。

b.如果该节点头对象在Set<NodeHeader>中存在，但需要验证的服务的版本信息，不包含在头对象中，则将该服务的版本信息修改到头对象中，继续执行对版本的后续验证。

c.如果该节点的节点头对象在Set<NodeHeader>中不存在，则生成相应的节点头对象，然后放入Set<NodeHeader>t中。

505，判断当前节点对象是否为JDK节点对象，是则返回步骤503，否则继续执行后续步骤。

这是因为JDK不依赖于其它任何资源。

506，找出当前节点对象所依赖的JDK，并对找到的每个JDK做如下处理：从节点集合中查找该JDK对应的JDK节点对象，如果不存在，则生成对应的JDK节点对象，添加到节点列表和节点集合中。

本步骤具体为：

a.从Set<Node>中，查找与该jdk版本相对应的JdkNode节点；

如果存在，则将找到的JdkNode节点，作为该jdk的节点对象；

如果不存在，则生成一个新的JdkNode对象，并将该对象加入List<Node>中，准备处理；同时加入Set<Node>中；

b.将找到的JdkNode对象，放入正在处理的Node对象的属性”_jdk”中。

507，找出当前节点对象所直接依赖的共享库，并对找出的每个共享库做如下处理：从节点集合中查找与该共享库对应的共享库节点对象，如果不存在，则生成对应的共享库节点对象，添加到节点列表和节点集合中。

本步骤具体为：

a.从Set<Node>中，查找与该共享库相对应的SharedLibNode节点；

如果存在，则将找到的SharedLibNode节点，作为该共享库的节点对象；

如果不存在，则生成一个新的SharedLibNode对象，并将该对象加入List<Node>中，准备处理；同时加入Set<Node>中。

b.将找到的SharedLibNode对象，放入正在处理的Node对象的属性”_lowerLibNodes”中。

508，判断当前节点对象是共享库节点对象还是服务节点对象，如果是共享库节点对象，则执行509，如果是服务节点对象，则执行510。

509，找出该共享库节点对象的其他所有版本，对每个版本做如下处理：如果该版本被其他服务直接依赖，则生成该版本对应的节点头对象，添加到节点头集合中；如果该版本没有被其他服务直接依赖，则找出直接或间接依赖该版本的其他共享库，如果找出的这些共享库被其他服务直接依赖，则生成该版本对应的节点头对象，添加到节点头集合中；返回步骤11。

本步骤具体为：

a.如果该版本被工作室里的其他服务直接依赖，则直接将该共享库版本的信息修改到该Node对象的节点头对象中，处理过程退出；

b.如果该版本没有被工作室其他服务直接依赖，则找到直接和间接依赖该共享库的其他共享库。

c.如果找到的这些共享库被工作室里的其他服务直接依赖，则直接将该共享库版本的信息修改到该Node对象的节点头对象中。

510，找出该服务节点对象直接依赖的所有其他服务，对找出的每个服务做如下处理：从节点集合中查找与该服务对应的服务节点对象，如果不存在，则生成对应的服务节点对象，添加到节点列表和节点集合中；将找到的服务节点作为当前节点的下游服务节点，写入当前节点对象中；

本步骤具体为：

a.从Set<Node>中，查找与该共享库相对应的ServiceNode节点；

如果存在，则将找到的ServiceNode节点，作为该服务的节点对象；

如果不存在，则生成一个新的ServiceNode对象，并将该对象加入List<Node>中，准备处理；同时加入Set<Node>中。

b.将找到的ServiceNode对象，放入正在处理的Node对象的属性”_lowerServiceNodes”中。

至此服务依赖树建成。

服务依赖验证基于服务依赖树的建立；在服务依赖树生成完成后，能得到以下对象：

rootNode对象，这是服务依赖树的根节点。

节点头集合Set<NodeHeader>：该集合保存了所有相关的不带版本好的jdk，服务包，以及共享包。

节点集合Set<Node>：该集合保存了依赖树中的所有节点

则验证服务依赖树包括：

步骤21，创建验证信息列表；

一个验证服务依赖树的具体实施例的过程如下：

1.创建List<NodeHeader>对象，并命名为warningList，用来保存依赖了不同版本，但兼容的节点头信息。

2.创建List<NodeHeader>对象，并命名为ErrorList，用来保存依赖了不同版本，且不兼容的节点头信息。

3.按照服务、共享包、jdk的顺序对Set<NodeHeader>中的节点头信息进行轮询，处理每一个节点头：

a)如果_minVersion和_maxVersion一致，则版本完全匹配；

b)如果_minVersion和_maxVersion不一致，且

_requiredVersion不大于_minVersion，则虽然有版本不一致，但兼容，将该版本头信息放入warningList中。

c)如果_minVersion和_maxVersion不一致，且

_requiredVersion大于_minVersion，则不但有版本不一致，且不兼容，将该版本头信息放入errorList中。

4.如果errorList不为空，则展示errorList中版本不一致且不兼容的信息。

5.如果warningList不为空，则展示wangingList中版本不一致但兼容的信息。

本发明的实施例中还对服务依赖关系进行展示：

指定一个服务，以图形方式，展示该服务，以及该服务依赖的所有其他服务、共享包、jdk之间的关系。

服务依赖关系展示基于服务依赖树的建立；

在服务依赖树生成完成后，能得到以下对象：

rootNode对象，这是服务依赖树的根节点。

节点集合Set<Node>：该集合保存了依赖树中的所有节点。依赖树展示要求如下：

以根节点在上，从上至下以树形的方式展示依赖树中的每个节点。要求如下

■对有兼容问题的节点(版本兼容节点，版本不兼容节点)，以不同的颜色标示。

■对依赖版本不兼容节点的节点以某种颜色标出。

■对依赖版本兼容节点的节点以某种颜色标出。

■对其他节点，根据不同的类型(SharedLibNode，ServiceNode)，以不同的颜色标示。

■需要的jdk版本号作为属性出现在节点中。

节点跟节点之间的依赖用带箭头的线条标出。要求如下

■服务与服务之间的依赖用与服务节点同样颜色的实线标出。

■服务与共享库，共享库与共享库之间的依赖用与共享库节点同样颜色的虚线标出。

选中某个节点，可以查看该节点的相关信息

■节点类型

■节点的兼容类型。

■节点基本信息，节点标示、名称等

■节点对jdk版本的依赖

■节点对服务的依赖

■节点对共享库的依赖

■节点头信息。

服务影响检测

从指定的服务出发，找出该服务修改引起的所有可能的不一致性、不兼容性，并将情况呈现给开发人员。

该功能假设该服务已经开发完毕，并且已经验证其依赖关系。

服务修改影响程度分为以下级别：

严重：服务修改导致出现不兼容情况。这种情况一旦发生，必须通过修改相应服务来消除不兼容现象。

警告：服务修改导致出现版本不一致，但兼容的情况。这种情况一旦发生，必须由其他服务的相关人员再三确认兼容的正确性。

完全匹配：该次修改没有导致任何不一致性发生。

服务修改影响范围与程度鉴定包含两个步骤：

服务影响树创建：以修改的服务为根节点，找出直接、间接依赖该服务的其他服务。

服务影响树检测：显示影响程度

最后还可以进一步新型服务影响树展示：以树结构显示影响树。

则，在本发明中创建服务影响树包括：

创建一个用于存放节点头对象的第二节点头集合；创建一个用于存放需要处理的节点对象的第二节点列表；创建一个用于存放影响树中的节点的第二节点集合；

初始时，为待处理的服务生成对应的节点对象，并放入第二节点列表和第二节点集合中，然后执行如下的步骤：

步骤1，判断第二节点列表是否为空，是则结束流程，否则从第二节点列表中取出一个节点对象作为当前节点对象，并将该节点对象从第二节点列表中删除；

步骤2，为当前节点对象在第二节点头集合中维护其对应的节点头对象；

步骤3，找出直接依赖当前节点对象的所有其它服务，并对超出的每个服务做如下处理：从第二节点集合中查找与该服务对应的服务节点对象，如果不存在，则生成对应的服务节点对象，添加到第二节点列表和第二节点集合中；将找到的服务节点作为当前节点的上游服务节点，写入当前节点对象中；返回步骤1。

一个创建服务影响树的具体实施例的过程如下：

1.创建一个Set<NodeHeader>，用来存放所有的节点头对象。

2.创建一个List<Node>，用来存放需要处理的节点，包括需要处理的依赖该服务或库的其他服务和共享库。

3.创建一个Set<Node>，用来存放影响树中所有的节点。

4.为需要检测的服务生成相应的Node对象，并将之放入List<Node>和Set<Node>中，同时将其变成rootNode。

5.如果List<Node>为空，则退出整个服务依赖树生成逻辑；否则从List<Node>中取出一个Node对象作为下一个需要处理的对象，并将该Node对象从List<Node>中删除。

6.为刚取出Node对象维护相关的节点头对象：

a.如果该节点头对象在Set中存在，且需要验证的服务的版本信息，已经包含在头对象中，则表示该服务的依赖性已经被处理，则跳过对该服务的验证，转到步骤5，进行下一节点的处理。

b.如果该节点头对象在Set中存在，且需要验证的服务的版本信息，不包含在头对象中，则将该服务的版本信息修改到头对象中，继续执行对版本的后续验证。

c.如果该节点的节点头对象在Set中不存在，则生成相应的节点头对象，然后放入Set中。

7.找出直接依赖该Node对象的所有其他服务，并对每一个服务做如下处理：

a.从Set<Node>中，查找与该共享库相对应的ServiceNode节点

如果存在，则将找到的ServiceNode节点，作为该服务的节点对象。

b.将找到的ServiceNode对象，放入正在处理的Node对象的属性”_upperServiceNodes”中。

8.回到步骤5，处理下一个节点对象。

服务影响检测证基于服务影响树树的建立；在服务影响树生成完成后，能得到以下对象：

rootNode对象，这是服务影响树的根节点。

节点集合Set<Node>：该集合保存了影响树中的所有节点。

则检测服务影响树的逻辑包括：

步骤1，创建第二告警列表和第二出错列表；

步骤2，按照服务、共享库、JDK的顺序对第二节点头集合中的节点头对象进行轮询，对于每个节点头对象进行如下处理：如果节点的最小版本号和节点的最大版本号不一致，且要求的版本号不大于节点的最小版本号，则将该节点头对象放入第二告警列表中；如果节点的最小版本号和节点的最大版本号不一致，且要求的版本号大于节点的最小版本号，则将该节点头对象放入第二出错列表中；

步骤3，如果第二告警列表不为空，则影响级别为告警；如果第二出错列表不为空，则影响级别为严重。

一个检测服务影响树的具体实施例的过程如下：

a)如果_minVersion和_maxVersion一致，则版本完全匹配；

b)如果_minVersion和_maxVersion不一致，且

c)如果_minVersion和_maxVersion不一致，且

4.如果errorList不为空，则表示该服务的影响级别属于：严重；如果warningList不为空，则表示该服务的影响级别属于：警告；否则，表示该服务的影响级别属于：完全匹配。

影响树的展示：采用与服务依赖树展示同样的逻辑进行展示，唯一的区别是，在服务依赖树展示中，根节点在上面，图中展示的是其下游的依赖；而在服务影响树展示中，根节点在下面，图中展示的是其上游的依赖。

环境配置

1.服务边界定义接口实现：

在配置文件中，指定一个服务边界定义接口“ServiceBoundary”的实现；该接口将被开发环境用来在开发视图和文件存放方面进行关联操作。

2.数据库配置：

所有的信息，包括共享库信息、服务信息、依赖关系等都将存入数据库中，已被全公司访问。

该数据库配置包含以下配置：数据库连接串、用户名、密码。

3.版本控制服务器配置：

所有的源代码，共享库等都将让如版本控制服务器中，已被全公司员工访问。权限功能由具体的版本控制服务器控制。版本控制服务器包含以下配置：版本服务器连接串、用户名、密码。

4.Web服务器配置：

开发环境可以访问web服务器提供的查询、管理功能来快速开发服务。

Web服务器包含以下配置：Web服务登录地址、用户名、密码。

5.工作室

工作室一般会对应到一个软件产品线或者在多层体系机构系统中的某一层。

一个工作室通常具有以下特点：

●工作室是自包含的，即工作室所包含的软件是可以单独运行的。

●工作室对应的代码是统一设计、开发、部署的。

●在版本控制系统中，工作室包含的资源一般会放在某一个目录中。

在共享环境中，工作室的配置文件是需要提交到版本控制服务器，是所有开发人员共享的；即只需要配置一次，所有开发人员共享。

除了以前的环境所对应的功能外，本方案将赋予工作室其他功能(通常以菜单方式)。

●维护参数

●创建工作室

●打开工作室

●编译工作室

●打包工作室

●提交工作室

●同步工作室

●验证依赖性

●查看依赖性

6.创建工作室

工作室一般对应一个大的产品或平台，工作室一旦创建后，所有相关的开发人员都将共享这一个工作室，进行开发。

创建工作室需要指定下列参数：

●工作室名称

●工作室需要的jdk版本

●工作室在版本控制系统中对应的路径。

●包输出格式。

●包输出目录。

创建工作室包括以下步骤：

a.在大的产品线下，为该工作室生成一条记录，表示该工作室对应的服务类别；并为该服务类别生成以下的属性。

●jdk_version

●vcs_path

●out_dir

●package_format

b.生成一个工作室的文件，来存相关信息，目的是让工作室在offline的环境下，同样能打开。

7.打开工作室

打开工作室就是把工作室的内容结构以树形展现出来；

该功能包含以下步骤：

a.访问服务定义数据库，如果访问失败，则直接用本地的工作室配置文件；如果访问成功，则用数据库的配置刷新本地工作室配置文件；

b.得到工作室包含的所有项目。

c.对每一个项目调用“打开”功能。

d.暂时工作室的其他内容。

8.维护参数

用属性页面的方式来显示和维护工作室参数；工作室的参数信息是共享的，所以开发人员不要轻易改变参数值。

基本参数包括：工作室名称、工作室需要的jdk版本、工作室在版本控制系统中对应的路径、包输出格式、包输出目录。

维护参数包含以下步骤：更新服务定义数据库中的数据；更新工作室配置文件中的数据。

9.编译工作室

该功能将包括以下几步：找出工作室包含的所有项目；按照项目的依赖关系，对项目进行排序；从最底层的项目开始，顺序调用项目的编译功能，进行编译。

10.打包工作室

该功能将包括以下几步：调用“编译”功能，对工作室进行编译，如果编译失败，则退出。调用“依赖性验证”功能，对工作室中所有的服务进行依赖性验证，如果不一致，则退出。找出工作室包含的所有项目；按照项目的依赖关系，对项目进行排序；从最底层的项目开始，顺序调用项目的打包功能(项目打包功能不应该再调用项目的“编译”和“依赖性验证”功能)，进行打包。根据打包策略，对所有的包进行归纳整理，最后以tar包或zip包的方式，将所有包按照合理的结构、合理的格式打包。

11.提交工作室

该功能将包括以下几步：先调用编译功能，对工作室进行编译，以确保所有的修改都是可编译的；如果编译不通过，则不能进行提交；找出工作室包含的所有项目；顺序调用项目的提交功能(项目提交功能不应该再调用项目的“编译”功能)，将最新的服务修改提交到版本控制服务器，并同时修改开发管理数据库；提交完成后，将调用“依赖性验证”功能，提示该次修改是否会引起依赖性不一致性问题，如有，则用图形方式显示。

12.同步工作室

该功能将实现工作室中的所有服务的定义同步到数据库的服务定义库中。

该功能将包括以下几步：找出工作室包含的所有项目；按照项目的依赖关系，对项目进行排序；从最底层的项目开始，顺序调用项目的“同步”功能进行同步。

13.验证工作室

该功能用来验证工作室中所有服务的依赖性是否满足。

该功能将包括以下几步：找出工作室包含的所有项目；按照项目的依赖关系，对项目进行排序；从最底层的项目开始，顺序调用项目的“验证依赖”功能进行依赖性验证。

14.查看依赖性

该功能将服务与服务之间的依赖性，用图形的方式展现出来。

该功能将包括以下几步：从服务定义数据库中，找出工作室对应的所有服务。将所有服务合理的分布在画布中，并将具有依赖关系的服务与服务之间用线连起来。

项目

项目是服务的集合，一个项目可以包含多个服务；一般情况下，设计人员可以通过服务在整个体系结构中所处的位置，加上服务与服务之间是否具有内聚性，来将服务进行归纳处理，放入一个合适的项目中。

项目的配置文件同样是共享的，即只需要配置一次，所有开发人员共享。

开发人员需要提供以下的信息：项目名称；项目在版本控制系统中对应的路径；项目的打包策略：是面向服务打包，还是面向项目打包；项目依赖性：对工作室中其他项目的依赖性。

项目支持以下功能：创建项目、维护参数、打开项目、删除项目、编译项目、打包项目、提交项目。

1.创建项目

创建项目将在当前的工作室中，创建一个新的项目。项目是共享的，一旦创建，所有开发人员都可以访问。

在向导中，需要指定以下参数：项目名称，在工作室中必须唯一；在版本控制系统中，项目对应的路径；项目对工作室中其他项目的依赖；项目的打包策略：是整体打包，还是按服务打包。

创建项目向导包含以下步骤：检查项目名称是否唯一，不唯一则退出；在工作室对应的服务类别下，为该项目生成一个新的服务类别来表示该项目；为该服务类别添加以下属性：vcs_path和project_dependency；生成一个项目配置文件，该文件可以用来实现offline的项目操作；在工作室中加入该项目依赖。

2.维护参数

用属性页的方式来显示和维护项目的参数：项目名称，在工作室中必须唯一；在版本控制系统中，项目对应的路径；项目对工作室中其他项目的依赖；项目的打包策略：是整体打包，还是按服务打包。

维护参数包含以下步骤：更新服务定义数据库中的数据；更新项目配置文件中的数据。

3.打开项目

打开项目就是将项目的内容结构以树形展示出来。

打开项目包含以下步骤：访问服务定义数据库；如果访问失败，则直接用本地的项目配置文件；如果访问成功，则用数据库的配置刷新本地项目配置文件；得到工作室包含的所有服务；对每一个服务调用“打开”功能；展示项目的其他内容。

4.删除项目

删除项目用来删除一个不需要的项目。

删除项目包含以下步骤：检查该项目中的服务有没有被其他项目中的服务引用，如果有，则退出；从数据库中删除该项目对应的服务类别的属性；从数据库中删除该项目对应的服务列别；从版本控制服务器中删除项目配置文件；从工作室的视图中，删除该项目；如果删除项目，不需要删除项目内容，则退出；从版本控制服务器中删除所有项目的内容；从本地文件系统中删除内容。

5.编译项目

编译项目用来编译项目中的所有服务。

该功能包含以下步骤：找到该项目包含的所有服务；根据服务的依赖关系，对服务进行排序；从依赖关系最底层的服务开始，依次对服务进行编译。

6.打包

打包是用来对项目包含的服务进行打包，以便发布。

该功能包含以下步骤：找到项目所在工作区所对应的服务类别；找到服务类别属性“out_dir”；在out_dir下查找名称为“项目名”的子目录，如果不存在，则创建，如果存在，则清空该子目录；找到项目下的所有服务；对每个服务，依次调用服务的打包功能。

7.提交项目

提交项目即对项目中所有正在修改的服务提交到版本服务器，同时修改服务定义数据库，把服务的状态改成发布状态。

该功能包含以下功能：从服务定义数据库中，找到该项目中所有正在修改的服务。对每个正在修改的服务，调用“提交服务”功能，提交服务。

服务

服务是该方案中最小的自包含的开发单元，即一个服务可以根据服务的配置来单独进行开发、编译与打包。

服务支持以下功能：创建服务、打开服务、维护服务、删除服务、编译服务、打包服务、提交服务、发布服务。

1.创建服务

创建服务用来在一个项目中创建一个服务。

在面向服务的开发环境中，所有的类都属于一个服务，根据服务的目的不一样，可以将服务分成以下几类

公共服务：这种服务其实是包含以下公共的类，比如Java Bean类、异常类、服务类型的基类、标注类、枚举类等。这种服务是最基础的，不支持热插拔功能。

工具服务：这种服务其实包含的是一些工具类，比如StringUtil、IntegerUtil、DateUtil等；为了实现服务的热插拔功能，这些服务基本上都需要用Singleton来实现。一般情况下，工具服务中，会包含多个服务；

业务服务：这是真正意义上的服务，一般需要部署在一个容器中，等待客户端的访问。这种服务必须实现热插拔功能。

1.1.创建公共服务

创建公共服务向导需要下面的参数：服务名称、服务描述、服务边界接口实现类需要的参数、服务依赖关系。

创建公共服务向导会包含下面步骤：检查服务名称是否唯一，如不唯一，则退出。检查服务依赖关系，如果有不兼容性，则退出。在服务定义数据库中，在项目对应的服务类别下，增加一个服务。并为服务生成必须的属性。在服务定义数据库中，增加服务依赖关系。在项目配置文件中，增加服务条目信息，包含服务依赖关系。生成相应的服务配置文件。修改开发试图，增加该服务信息。

对公共服务，除了基本功能之外，需要增加以下功能：

a.修改服务依赖关系，需要遵循以下步骤：检查服务依赖关系，如果有不兼容性或不完整，则退出。在服务定义数据库中，修改服务依赖关系。

b.创捷服务类别的java类，需要遵循以下步骤：指定该类的名称，该类的父类别；生成指定的类的源代码；在服务定义数据库中，在指定的父类别下，为该服务类别增加一个子类，来表示该服务类别；并填写相应的信息；在服务定义数据库中，为该类别生成相应的服务属性信息；调用版本控制模块，将该类加入版本控制服务器中，但不提交；刷新开发试图，显示新建的服务类别。

C.删除服务类别：需要遵循以下步骤：检查该类别有没有子类别；如果则退出；检查该类别有没有服务，如有则退出；从服务定义数据库中，删除类别属性和类别信息；调用版本控制模块，从版本控制服务器中删除该类，但不提交；从本地目录中删除该类；从开发环境视图中删除该服务类别。

1.2.创建工具服务

工具服务具有以下特征：包含多个服务；支持热插拔。

在实现上，工具服务具有以下要求：

工具服务，有一个top level的服务接口，该接口实际上是一个服务的工厂模式；

Top level的服务接口将将返回具体工具服务，以便用户调用。为了支持热插拔，返回的工具服务实例实际上是特定服务实例的一个代理，即实现一个代理模式；

Top level服务和具体的服务都是单一实例，即实现一个Singleton模式；

所有服务包括top level，都必须实现接口和实现的分离，即实现松散绑定模式。

Top level的服务接口实现，将利用服务容器的功能，对管理的具体工具服务进行注册、刷新、注销功能，从而实现具体工具服务的热插拔功能。

该功能不属于本方案的内容。

创建工具服务向导需要下面的参数：服务名称、服务描述、服务边界接口实现类需要的参数、服务top level的类的接口、服务依赖关系。

创建工具服务向导会遵循以下步骤：检查服务名称是否唯一，如不唯一，则退出。检查服务依赖关系是否兼容，如不兼容，则退出。在服务定义数据库中，在项目对应的服务类别下，增加一个服务。并为服务生成必须的属性。在服务定义数据库中，增加服务依赖关系。生成相应的top level类的接口以及简单的接口实现，该实现将Singleton模式。调用版本控制模块，将生成的类加入版本控制服务器，但不提交。生成相应的服务配置文件。刷新开发试图，显示新建的工具服务。

对工具服务，除了基本功能之外，需要增加以下功能：

增加工具服务：需要遵循以下步骤：指定工具服务类名称；制定工具服务类类名；检查该工具服务类是否已经存在，如存在，则退出；生成工具服务类接口与接口实现，接口实现以Singleton的模式；调用版本控制模块，从版本控制服务器中，将top level的服务接口、服务接口实现类check out；修改top level的服务接口，以工具服务类的名称为方法名的一部分，生成一个特定的接口方法，返回工具服务类的实例；修改top level的服务接口实现类，对新增的工具服务类实现向容器的注册、注销、刷新功能；修改top level的服务接口实现类，实现刚刚新增的访问该工具类的方法；调用版本控制模块，将新增的工具服务接口、工具服务接口实现加到版本控制服务器中，但不提交；修改服务定义数据库，将新增的服务方法加入数据库中，并生成相应的属性；修改服务配置文件，将新增的工具类服务加进去。刷新开发视图，显示新增的工具服务类信息。

删除工具服务：需要遵循以下步骤：检查需要删除的工具服务类，如果存在依赖关系，则退出；从服务配置文件中，找到该工具服务的接口类，以及实现类；调用版本控制模块，从版本控制服务器中，将top level的服务接口、服务接口实现类check out；修改top level的服务接口，将对应的方法从服务类中删除；修改top level的服务接口实现类，删除对要删除的工具服务类实现向容器的注册、注销、刷新功能的代码；修改top level的服务接口实现类，删除访问该工具类的方法；调用版本控制模块，将要删除的工具服务接口、工具服务接口实现从版本控制服务器中删除，但不提交；修改服务定义数据库，将要删除的工具服务方法从数据库中删除，并删除相应的属性；修改服务配置文件，将工具类服务信息删除；刷新开发视图，删除相应的工具服务类信息。

1.3.创建业务服务

业务服务是最重要的服务，是用来实现一定的业务需求。

在实现上，业务服务具有以下需求：业务服务具有热插拔功能；业务服务一般实现为Singleton模式。

创建业务服务向导需要下面的参数：服务名称、服务描述、服务所属服务类别、服务边界接口实现类需要的参数、服务类的接口、服务依赖关系。

创建工具服务向导会遵循以下步骤：检查服务名称是否唯一，如不唯一，则退出；检查服务依赖关系是否兼容，如不兼容，则退出；在服务定义数据库中，在项目对应的服务类别下，增加一个服务。并为服务生成必须的属性；在服务定义数据库中，增加服务依赖关系；生成相应的服务类的接口以及简单的接口实现，该实现将采用Singleton模式；调用版本控制模块，将生成的类加入版本控制服务器，但不提交；生成相应的服务配置文件；刷新开发试图，显示新建的业务服务。

2.打开服务

打开服务就是把服务的内容结构以树形展现出来；

该功能包含以下步骤：访问服务定义数据库；如果访问失败，则直接用本地的服务配置文件；如果访问成功，则用数据库的配置刷新服务配置文件；用服务边界接口实现类找到该服务的所有资源；参考服务配置信息，将服务的所有资源用树形结构展现出来。

3.维护服务

维护服务就是对已经存在的服务改为编辑模式。

在这个模式下：开发人员可以从版本服务器checkout文件；开发人员可以将修改提交到版本服务器；使用该服务的开发人员将知道该服务在修改当中，可以提前检查自己是否要做相应修改。

该功能包含以下步骤：如果该服务已经出在编辑模式，则退出；在服务定义数据库中，标记该服务为编辑状态；在服务配置文件中，标记该服务为编辑状态；启用版本控制模块对该服务的操作。

4.删除服务

删除服务就是删除已经存在的服务。

该功能包含以下步骤：检查该服务是否被其他服务依赖，如有，则退出；从服务定义数据库中，删除该服务所有信息；从版本控制服务器中，删除该服务对应的所有文件，但不提交；从本地文件中，删除该服务对应的所有文件；修改项目配置文件，删除该服务信息；刷新开发视图，将服务从视图中删除。

5.编译服务

编译服务就是编译服务对应的所有类。

该功能包含以下步骤：服务的所有依赖是否满足；检查依赖的所有共享库，是否已经存在于本地，如果不存在，则从共享库中获得相应信息，并下载相应的共享库；将共享库、依赖的其他服务，加到编译的classpath中，编译服务包含的所有类。

6.提交服务

提交服务就是将服务的修改提交到版本控制服务器。

该功能包含以下步骤：检查该服务是否处于编辑模式，如果不是，则退出；调用“编译”服务，查看该服务是否能编译，如不能，则退出；调用版本控制模块，将修改信息提交到版本控制服务器；在服务定义数据库中，更改服务版本、服务状态和修改描述；在服务定义数据库中，将对应的版本控制服务器生成的修改序列号，作为服务属性“changelist_”+版本号，放入服务属性表中。

7.打包服务

打包服务就是将服务相关资源打成jar包，进行发布。

该功能包含以下步骤：调用“编译”服务，查看该服务是否能编译，如不能，则退出；将编译后所有的类，服务配置文件，属性文件，其他配置文件打成jar包；将客户端需要的类，打成一个客户端jar包，供客户端使用；对客户端需要的类，调用javadoc工具，生成javadoc，并打成zip包。

8.发布服务

发布服务就是对服务作为共享服务发布到共享库，以便其他部门的人调用。

该功能包含以下步骤：检查该服务依赖的所有其他服务，是不是都已经发布，如果不是，则退出；找到所属的共享库类别：如果是第一次发布，则要求用户选择一个共享库类别，并将该信息保存到服务属性表中，如果不是第一次发布，则从服务属性表中，找到该共享库类别；将服务相关的所有包，放到共享库仓库中；修改共享库，反应该服务：如果是第一次发布，则在指定的共享库类别下，加入一个服务库，并且在服务库下，加入一个版本，并填写相关的属性，如果不是第一次发布，则在指定的服务库中，加入该新版本，并填写相关的属性。

服务的Web管理

该模块将对企业所开发的服务进行查询。

代码线创建

查询服务

验证服务依赖性

展示服务依赖性

服务编译与打包

服务发布

1.代码线创建

当项目发布时，需要对发布的版本单独建立一个代码线，自从建立后，该代码线中的服务能独立的维护，并发布。而代码线创建是为了创建一套基于代码线的不同的服务。

其步骤如下：选定一个代码线。指定一个新的代码线：代码线的名字，代码线在版本控制服务器中的位置。点击“确认”，系统将做以下工作：为新的代码线创建一个新的类别；将老的代码线包含的所有类别按照新的代码线复制一份，同时类别的属性同样进行复制，但在复制的过程中将根据新的代码线进行对应修改；将老的代码线所包含的所有服务按照对应的新的代码线类别复制一份，同时，服务的属性，方法等数据都将进行复制；调用版本控制服务，例如svn，从老代码线中取出所有的代码；将所有代码复制到新的代码线位置；修改所有配置文件：工作区配置文件、项目配置文件、服务配置文件，将文件中对服务类别，服务的引用指向新的代码线下的服务类别和服务；调用版本控制服务，例如svn，将新的代码线提交到版本控制服务器。

2.查询服务

根据一定的条件，查询对应的服务，以及服务的相关信息。

3.验证服务依赖性

对一个服务或一组服务，验证其依赖性是否完整、是否一致性。依赖性包括jdk依赖、共享库依赖、其他服务依赖。

4.展示服务依赖性

对一个指定的服务，以图形的方式，显示一个完整的依赖关系图，包括在上下游依赖链中，所有服务、共享库的完整依赖关系。

5.服务编译与打包

对一个指定的服务，实现编译打包功能。

该功能包含以下步骤：从服务定义数据库中，获取该服务与版本控制服务器之间的关系。从版本控制服务器中，获取最新的代码。从服务定义数据库中，获取该服务对共享库的依赖。从版本控制服务器中，获取需要的共享库。从服务定义数据库中，获取该服务对其他服务的依赖。检查该依赖的服务是否已经打包，如果没有打包，对该服务递归调用编译、打包功能。将共享库、依赖的服务包放入classpath中，对该服务的源代码进行编译。将编译后的类，打包成不同的包，比如客户端包、javadoc包、服务实现包等。

6.服务发布

在服务开发完毕，并且已经验证其依赖关系后。如果该服务能够被公司内其他产品所访问，则可以选择发布该服务至共享库中。

服务发布三种服务类型的发布：

a.公共服务发布：公共服务是被动服务，客户端需要所有的代码才能实现公共服务的共享。

b.工具服务发布：工具服务是被动服务，客户端需要所有的代码才能实现工具服务的共享。

c.业务服务发布：业务服务是主动服务，客户端只需要客户端相关的包就能实现业务服务的共享。

公共服务发布包含以下步骤：

1)检查该公共服务直接依赖的其他服务是否已经发布，如果没有发布，则必须先发布公共服务依赖的其他服务，并退出发布过程。

2)检查该公共服务之前是否已经发布过；

如果发布过，则用以有的共享库标识作为该公共服务的共享库标识；

如果没有发布过，在共享库中选择该服务所属的共享库类别，如果该类别存在，则直接选择它。否则，则创建它

在指定的共享库类别中，创建一个共享库标识，并以该共享库标识作为该公共服务的共享库标识。

3)在找到的共享库标识下，为该公共服务创建一个具体版本的共享库标识。

4)对指定的服务进行打包。

5)将包上传到具体版本共享库标识在版本控制服务器中对应的位置。

6)将服务包相关的信息复制到服务共享库中，包括属性信息，服务方法信息，依赖信息等。

工具服务发布包含以下步骤：

1)检查该工具服务直接依赖的其他服务是否已经发布，如果没有发布，则必须先发布工具服务依赖的其他服务，并退出发布过程。

2)检查该工具服务之前是否已经发布过；

如果发布过，则用以有的共享库标识作为该工具服务的共享库标识；

3)在找到的共享库标识下，为该工具服务创建一个具体版本的共享库标识。

4)对指定的服务进行打包。

6)将服务包相关的信息复制到服务共享库中。

业务服务发布包含以下步骤：

1)检查该业务服务之前是否已经发布过；

如果发布过，则用以有的共享库标识作为该业务服务的共享库标识；

如果没有发布过，在共享库中选择该服务所属的共享库类别，如果该类别存在，则直接选择它，否则，则创建它；

2)在找到的共享库标识下，为该业务服务创建一个具体版本的共享库标识。

3)对指定的服务进行打包。

4)将客户端相关包上传到具体版本共享库标识在版本控制服务器中对应的位置。

5)将服务包相关的信息复制到服务共享库中。

由上述可见，本发明这种定义服务的基本信息、定义服务的边界定义服务的客户端标示，并对服务的依赖性进行验证的技术方案，由于给出了定义的服务描述信息，因此能实现服务的快速开发，并且进行服务依赖验证的方案能保证系统的兼容性。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种服务依赖性的验证方法，其特征在于，该方法包括：生成服务依赖树，验证服务依赖树；

所述生成服务依赖树包括：

所述验证服务依赖树包括：

步骤21，创建验证信息列表；

2.根据权利要求1所述的方法，其特征在于，步骤12所述的为当前节点对象在节点头集合中维护其对应的节点头对象包括：

3.根据权利要求1所述的方法，其特征在于，

所述验证信息列表包括：告警列表和出错列表；

所述步骤22包括：如果节点的最小版本号和节点的最大版本号不一致，且要求的版本号不大于节点的最小版本号，则将该节点头对象放入告警列表中；如果节点的最小版本号和节点的最大版本号不一致，且要求的版本号大于节点的最小版本号，则将该节点头对象放入出错列表中；

所述步骤23包括：如果告警列表不为空，则验证结果为版本不一致且不兼容；如果出错列表不为空，则验证结果为版本不一致但兼容。

4.根据权利要求1至3中任一项所述的方法，其特征在于，该方法进一步包括：展示服务依赖树，具体为：

以根节点在上，从上至下以树形的方式展示依赖树中的每个节点；

节点与节点之间的依赖用带箭头的线条标示出；

展示每个节点的相关信息。

5.根据权利要求1至3中任一项所述的方法，其特征在于，该方法进一步包括：创建服务影响树，检测服务影响树；

所述创建服务影响树包括：

步骤31，判断第二节点列表是否为空，是则结束流程，否则从第二节点列表中取出一个节点对象作为当前节点对象，并将该节点对象从第二节点列表中删除；

步骤32，为当前节点对象在第二节点头集合中维护其对应的节点头对象；

步骤33，找出直接依赖当前节点对象的所有其它服务，并对超出的每个服务做如下处理：从第二节点集合中查找与该服务对应的服务节点对象，如果不存在，则生成对应的服务节点对象，添加到第二节点列表和第二节点集合中；将找到的服务节点作为当前节点的上游服务节点，写入当前节点对象中；返回步骤31；

所述检测服务影响树包括：

步骤41，创建第二告警列表和第二出错列表；

步骤42，按照服务、共享库、JDK的顺序对第二节点头集合中的节点头对象进行轮询，对于每个节点头对象进行如下处理：如果节点的最小版本号和节点的最大版本号不一致，且要求的版本号不大于节点的最小版本号，则将该节点头对象放入第二告警列表中；如果节点的最小版本号和节点的最大版本号不一致，且要求的版本号大于节点的最小版本号，则将该节点头对象放入第二出错列表中；

步骤43，如果第二告警列表不为空，则影响级别为告警；如果第二出错列表不为空，则影响级别为严重。

6.根据权利要求1至3中任一项所述的方法，其特征在于，在生成服务依赖树，验证服务依赖树之前该方法进一步包括：

定义服务的基本信息；其中，服务的基本信息包括：服务类别信息、服务类别属性信息、服务信息、服务属性信息、服务方法信息、服务依赖信息；

定义服务的边界，具体为：为服务所包含的累、配置文件和属性文件定义边界；

定义服务的客户端标示；服务的客户端标示用于标示被客户端用到的类。

7.根据权利要求6所述的方法，其特征在于，

所述服务类别信息的数据结构为：服务类别标示、服务类别名称、服务类别描述、父服务类别标示、服务类别序列号；

所述服务类别属性信息的数据结构为：服务类别标示、属性名称、服务类别序列号、属性类型、属性值；

所述服务信息的数据结构为：服务标示、服务类别标示、服务名称、服务描述、服务接口元数据、服务版本、最小的兼容版本号、服务类型、服务状态、创建者、创建时间、最后一次发布时间；

所述服务属性信息的数据结构为：服务标示、属性名称、属性类型、属性值；

所述服务方法信息的数据结构为：服务标示、服务方法签名、服务方法描述、服务是否过时；

所述服务依赖信息的包括：服务的共享库依赖信息和服务对其它服务的依赖信息；其中，服务的共享库依赖信息的数据结构为：服务标示、依赖的共享库标示、依赖的特定版本的共享库标示；服务对其它服务的依赖信息的数据结构为：服务标示、依赖的服务标示、依赖服务的版本号。

8.根据权利要求7所述的方法，其特征在于，该方法进一步包括：

将JDK的文件上传到版本控制服务器的指定位置，将共享库的文件上传到版本控制服务器中的对应共享库类别的存放位置下；

将JDK的描述信息保存到信息数据库中；其中，JDK的描述信息包括：JDK的标示和JDK在版本控制服务器上的存放位置；

将共享库描述信息和共享库依赖信息保存到信息数据库中；

所述共享库的描述信息包括：共享库的类别信息、共享库信息、具体版本的共享库信息、具体版本的共享库包含的文件信息、具体版本共享库的属性信息；其中共享库的类别信息中包含共享库在版本控制服务器中的位置信息；

所述共享库的依赖信息包括：具体版本共享库的库标示和被依赖的共享库的库标示；

当需要获取指定JDK时，先到信息数据库中查找对应的描述信息，根据描述信息从版本控制服务器获取该指定JDK的文件；

当需要获取指定共享库时，先到信息数据库中查找对应的共享库描述信息和共享库依赖信息，根据共享库描述信息从版本控制服务器获取该指定共享库的文件，根据共享库依赖信息获取被该指定共享库所依赖的其它包的文件。

9.根据权利要求8所述的方法，其特征在于，

所述共享库包括：第三方包和共享服务；其中，所述共享服务包括：公共服务、工具服务、业务服务；

其中工具服务和业务服务器的描述信息还包括：方法信息。

10.根据权利要求9所述的方法，其特征在于，

所述JDK的标示包括：JDK版本标示和JDK版本；

所述共享库的类别信息的数据结构为：分区标示、分区名称、类型掩码、针对该区的最小值、针对该区的最大标示，以及类别标示、类别名称、类别描述、类别掩码、父类别、在版本控制服务器中的位置信息；

所述共享库信息的数据结构为：库标示、类别标示、库名称、库描述、库类型、库提供商、官网、引入者、引入原因、服务是否过时；

所述具体版本的共享库信息的数据结构为：具体版本的库标示、库标示、库版本、兼容版本号、该版本的特别描述、JDK版本标示、上传者、上传原因、服务标示、是否已过时、许可类型；

具体版本的共享库包含的文件信息的数据结构为：具体版本的库标示、文件类型、文件名、文件路径；

具体版本共享库的属性信息的数据结构为：具体版本的库标示、属性名称、服务类型序列号、属性类型、属性值。