CN1916856A

CN1916856A - 一种分布式服务系统的服务提供方法

Info

Publication number: CN1916856A
Application number: CN 200510090749
Authority: CN
Inventors: 孙鸣
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2005-08-15
Filing date: 2005-08-15
Publication date: 2007-02-21
Anticipated expiration: 2025-08-15
Also published as: WO2007019745A1; CN100401259C

Abstract

本发明提供一种分布式服务系统的服务提供方法，首先确定要使用的扩展接口、公共管理服务以及要提供的具体服务；然后由所述具体服务实现所述扩展接口，并确定各服务的名称与服务主实现；再根据所述各服务的名称与服务主实现，分别生成描述各服务的配置文件；系统通过读取并解析所述配置文件，分别加载各服务的主实现；发布所述公共管理服务，并将要提供的具体服务在公共管理服务上进行注册发布。本发明克服现有技术中存在的访问不一致，难于扩展，以及由于服务的添加或者更改造成的巨大连锁反应等问题。

Description

一种分布式服务系统的服务提供方法

技术领域

本发明涉及一种计算机数据服务提供方法，尤其涉及一种用于分布式服务系统的服务提供方法。

背景技术

分布式服务系统就是将服务系统的功能拆分，将各个功能放在几个独立的组件上，通过这几个组件之间的相互协作，来完成整个系统的功能。在这里，几个独立的组件可以是指几个独立的CPU，但更通常的是指网络上的几台计算机。

采用分布式系统，最大的优点表现在系统的处理速度上。系统的各个功能放在几个独立的组件上，各部分的组件完成自己的功能块，以并行的方式协同工作。分布式服务系统另外的优点还在于个功能模块分开，便于管理、维护和更新，服务器的管理维护在大型的服务系统中也是相当重要的。

一个典型的分布式服务系统大致包括以下几部分：

表示层，主要负责业务层与用户之间的交流接口和数据传递工作，是唯一一个直接与用户打交道的部分；

业务层，是分布式服务系统的心脏，最主要的数据处理工作和服务就由这一部分完成和提供；

数据源，主要用于存储数据。

然而，和运行在一台机器中的服务提供者和使用者相比，分布式系统在服务提供方面具有大得多的复杂性。造成这种复杂性的原因主要有以下几个方面：

1、由于系统分布，服务器程序和客户程序很可能不是由同一个开发团队开发，这就造成服务提供者和客户之间的接口不规范，导致互操作困难，当涉及多个服务提供者和客户时，情况就会变得更加糟糕。

2、正是由于上面所述的不规范性，造成服务的扩展困难。当由于需求的变化需要增加新的服务或者对现有服务进行更改时，就会造成严重的连锁反应：那些和改动无关的客户(或者服务器)也不得不进行重新的构建和部署。当系统涉及隶属于多个不同公司的开发团队时，这种连锁反应会造成巨大的不必要的浪费。

3、部署是分布式服务中的一项重要工作，这项工作的难度直接影响到分布式服务发布和升级的工作量。遗憾的是，现在有很多服务提供者在需要升级或者提供新的服务时，都不得不重新构建并重启整个系统，这不仅严重影响了服务的可用性，并且也给升级工作带来了很大的工作量。

正是由于上面的这些原因，使得当前很多分布式系统在服务提供方面非常的不一致、难以扩展和部署。而开发这些系统的公司和团体也不得不耗费大量的不必要的资金和精力。

发明内容

本发明所要解决的技术问题在于提供一种分布式服务系统的服务提供方法，克服现有技术中存在的访问不一致，难于扩展，以及由于服务的添加或者更改造成的巨大连锁反应等问题。

本发明提供一种分布式服务系统的服务提供方法，包括如下步骤：

确定要使用的扩展接口、公共管理服务以及要提供的具体服务；

由所述具体服务实现所述扩展接口，并确定各服务的名称与服务主实现；

根据所述各服务的名称与服务主实现，分别生成描述各服务的配置文件；

系统通过读取并解析所述配置文件，分别加载各服务的主实现；

发布所述公共管理服务，并将要提供的具体服务在公共管理服务上进行注册发布。

优选的，本发明进一步包括如下步骤：

公共管理服务根据用户指示确定用户需要获取的具体服务名称；

公共管理服务根据具体服务名称获取该具体服务实体提供给用户使用。

其中，所述通过扩展接口实现服务，并确定服务名称与服务主实现步骤，进一步包括确定该服务的实现策略的步骤，包括如下步骤：

判断并确定该服务需要分解为不同的实现策略；

分解问题领域，解析出需要实现的策略组件；

确定策略与服务之间的协作方式；

实现出与服务相协作的策略组件。

其中，所述生成描述各服务的配置文件步骤，所述配置文件进一步包括信息：组成服务的策略名称、策略实现组件，以及策略在服务实现中的组合方式。

其中，所述加载步骤，进一步包括如下步骤：

判断并确定所述配置文件中含有策略配置信息；

解析出配置文件中的策略实现及其组合方式，并对其进行加载；

根据策略的组合方式，将策略实现组合如服务主实现中。

采用本发明所述方法，与现有技术相比，提供了一种高效，便捷，一致，并且易于扩展的分布式服务提供方法，采用配置文件的方式方便对服务的组织，服务的配置发布不再采用硬编码的方式，而是采用动态加载和控制反转(Inversion of Control)技术使得服务的表示和实现分离，从而可以很方便地实现服务的多样性。运用这种方法，可以极大地节省服务开发的时间，可以帮助分布式服务系统构建底层服务管理框架。由于控制反转的引入，应用对框架不存在直接依赖，提高了服务组件的可测试性，本发明提供的配置文件组织方式和服务访问方式还可以根据实际需要去进行扩展，应用范围更广，实现了服务的可扩展性，访问的一致性，服务实现的多样性，不同类型服务的易配置和易添加性以及动态加载性。本发明可以提供高度模块化且可动态、增量扩展的服务，特别适合于电信设备管理中EMS(网元管理系统)和NMS(网络管理系统)之间的服务提供方式。

附图说明

图1为本发明所述的分布式服务系统的服务提供方法流程示意图；

图2为本发明所述的服务实现及配置文件生成过程示意图；

图3为本发明所述的服务加载与发布流程示意图；

图4为为本发明所述的用户使用服务时的流程示意图。

具体实施方式

如图1所示，为本发明所述的分布式服务提供方法流程示意图。首先，确定要使用的扩展接口、公共管理服务以及要提供的具体服务(步骤101)；由所述具体服务实现所述扩展接口，并确定各服务的名称与服务主实现(步骤102)；根据所述各服务的名称与服务主实现，分别生成描述各服务的配置文件(步骤103)；系统通过读取并解析所述配置文件，分别加载各服务的主实现(步骤104)；发布所述公共管理服务，并将要提供的具体服务在公共管理服务上进行注册发布(步骤105)。

此外，如果具体服务还需要不同的实现策略，那么，本发明还可以进而将不同的策略及其组合方式进一步的描述入配置文件，并在服务加载时，通过读取和解析配置文件，动态的将不同策略组合入服务主实现中。

本发明所使用的扩展接口，是一种运用在框架中的常用技术。该技术可以使得接口的功能变得可扩展而不会影响到已有的使用者。为了达到这个目的，扩展接口技术提供了一个高层的、一致的抽象服务接口，该接口中定义了用于服务扩展所需要的方法，比如：服务查询等，由具体的服务实现该接口。

本发明所述的具体服务，其在实现时必须要继承上述确定好的扩展接口。其中，公共管理服务为系统的一项基本服务，在启动时加载和发布，所有其他服务都通过向公共管理服务注册的方式进行发布。

本发明所述的描述服务的配置文件采用XML格式，其中的信息可以具体涉及服务名称，服务实现主实现组件，组成服务的策略名称和策略实现组件，以及策略在服务实现中的组合方式。使用服务描述的配置文件，系统可以在运行时动态地加载并根据策略名称、组合方式等灵活地组装服务，从而可以在对系统其他部分没有任何影响的情况下，扩展和改变服务的内容。

所述配置文件的描述格式举例如下：

<strategy name="strategyl"imp="strategylImp"

means="setStrategyl"/>

<strategy name="strategy2"imp="strategy2Imp"

means="setStrategy2"/>

</service>

</servicereg>

优选的，在生成配置文件后，可以把具体的服务、策略实现以及对应的配置文件，复制到系统指定的目录下，为服务的加载和启动做准备。

系统加载、启动并发布服务时，系统在配置目录读取服务配置文件，采用动态加载和控制反转(Inversion Of Control)技术来完成服务的加载、组装，并通过把服务注册到公共管理服务的方式发布服务。控制反转是这样一种技术，它可以在运行时动态、灵活地建立起组件之间的依赖关系，而组件本身却无需知晓和其建立起关系的其他组件的细节。这样就可以使得组件的开发者集中精力于组件本身。

当客户使用服务，客户可以使用一个统一的访问点去获取公共的管理服务。通过该服务，客户可以通过服务名称查询自己感兴趣的具体服务，如果服务存在，就可以获取并使用该服务了。

如图2所示，为本发明所述的服务实现及配置文件生成过程示意图。首先，由具体的服务实现去扩展事先定义的扩展接口，也就是实现服务实现，并确定出服务名称(步骤201)；然后，判断服务是否需要分解为不同的实现策略(步骤202)，若步骤202的判断为假，跳至步骤206；若步骤202的判断为真，则描述服务实现策略(步骤203)，就是分解问题领域，解析出需要实现的策略组件；描述服务策略组合方式(步骤204)，就是确定策略和服务之间的协作方式；实现服务实现策略(步骤205)，就是实现出与服务协作的策略组件；生成用于服务描述的配置文件(步骤206)，就是将上面分析的服务名称，服务实现组件，组成服务的策略名称和策略实现组件，以及策略在服务实现中的组合方式描述在在配置文件中。

如图3所示，为本发明所述的服务加载与发布流程示意图。首先，触发服务加载动作(步骤301)；然后，读取并解析服务配置文件(步骤302)；加载服务主实现，对从文件中解析出的服务主实现组件，动态加载(步骤303)；判断服务配置文件中是否有策略配置，就是看服务配置文件中是否有对服务主实现的策略组件配置(步骤304)；如果步骤304判断为假，则转步骤307；如果步骤304判断为真，则分析并加载策略实现(步骤305)，就是解析出配置文件中的策略组合方式并动态加载策略实现组件；再把策略实现组合进服务实现主体(步骤306)，根据步骤305解析出的策略组合方式，把策略实现组合进服务实现主体；最后把服务实现注册到公共管理服务中(步骤307)，公共管理服务在系统启动时发布，所有的其他服务通过在公共管理服务上注册的方式发布。

如图4所示，为本发明所述的用户使用服务时的流程示意图。首先，客户获取公共管理服务(步骤401)；然后，客户告知公共管理服务自己想获取的具体服务名称(步骤402)；然后，客户使用公共管理服务获取具体服务实体(步骤403)；最后，客户使用具体服务(步骤404)。

下面用JAVA语言实现的一个例子来说明本发明，该例子中采用CORBA作为分布式对象的基础平台。首先确定一个扩展接口，在本例中，这个扩展接口是一个退化接口：

interface CommService{

};

然后我们再确定一个公共管理服务对象：

interface ServiceMng{

CommService getService(in string servname);

};

然后再确定一个要实现的服务，例子采用最简单的HelloWorld样例

interface HelloworldService::CommService{

void sayHello();

};

上述过程可以采用IDL语言进行描述，IDL是用于CORBA协议的接口定义语言，与此相似的，如果采用其他的协议，可是使用其他的定义语言来完成定义。

进一步，分析该服务实现中是否需要不同的实现策略，例如在本例的服务中，可以采用不同的语言策略。对中文来说，要说：“世界，你好！”，对英文来说，要说：“Hello World！”，所以，需要两种不同的语言策略。

下面是这两种策略的具体实现。

public interface HelloWorld{

public String getHello();

}

Public class EnglishHelloworld implements HelloWorld{

public String getHello(){

return“Hello World!";

}

public class ChineseHelloWorld implements HelloWorld{

public String getHello(){

return"世界,你好!";}}

接着，实现服务，在该服务实现中，确定了策略的组合方式。

public class HelloworldServiceImpl extends HelloworldService POA{

private ORB orb=null;

private HelloWorld hello;

public void setORBEnv(ORB orb){

this.orb=orb;

}

public void sayHello(){

System.out.println(hello.getHello());}Public void setHello(Hello World helloworld){

this.hello=helloworld;}}接下来，生成描述该服务的配置文件，对于英文来说如下：<servicereg>

<strategy name="language"imp="EnglishHelloworld"

means="setHello"/>

</service></servicereg>对于中文来说如下：<servicereg>

<strategy name="language"imp="ChineseHelloWorld"

means="setHello"/>

</service>

</servicereg>

对于本例来说，公共管理服务的实现如下：

public class ServiceMngImpl extends ServiceMngPOA{

public CommService getService(String servname){

return services.getservname);

}

public void registerService(String name,CommService srv){

services_.put(name,srv);

}

private Hashtable services_=new Hashtable();

}

系统在加载HelloWorld服务时，会读取并分析HelloWorld服务的配置文件。首先动态加载该服务的主实现HelloworldServiceImpl，然后分析并加载相应的策略，并根据所配置的组合手段把策略组合进服务实现中，并通过调用公共管理服务ServiceMngImpl的registerService方法把自己发布出去。

客户要访问HelloWorld服务时，首先获得CORBA的命名服务，然后获得公共管理服务ServiceMngImpl，调用ServiceMngImpl的getService(“HelloWorld”)方法获得HelloWorld服务。

Claims

1、一种分布式服务系统的服务提供方法，其特征在于，包括如下步骤：

2、如权利要求1所述的方法，其特征在于，进一步包括如下步骤：

3、如权利要求1所述的方法，其特征在于，所述通过扩展接口实现服务，并确定服务名称与服务主实现步骤，进一步包括确定该服务的实现策略的步骤，包括：

判断并确定该服务需要分解为不同的实现策略；

分解问题领域，解析出需要实现的策略组件；

确定策略与服务之间的协作方式；

实现出与服务相协作的策略组件。

4、如权利要求3所述的方法，其特征在于，所述生成描述各服务的配置文件步骤，所述配置文件进一步包括信息：组成服务的策略名称、策略实现组件，以及策略在服务实现中的组合方式。

5、如权利要求1所述的方法，其特征在于，所述生成描述各服务的配置文件步骤后，进一步包括步骤：

将具体的服务实现以及对应的配置文件复制到系统指定的目录下，为加载做准备。

6、如权利要求4所述的方法，其特征在于，所述生成描述各服务的配置文件步骤后，进一步包括步骤：

将具体的服务、策略实现以及对应的配置文件复制到系统指定的目录下。

7、如权利要求4所述的方法，其特征在于，所述加载步骤，进一步包括如下步骤：

判断并确定所述配置文件中含有策略配置信息；

根据策略的组合方式，将策略实现组合如服务主实现中。

8、如权利要求1所述的方法，其特征在于，所述加载步骤中，使用控制反转技术来建立起组件之间的依赖关系。

9、如权利要求1或4所述的方法，其特征在于，所述的配置文件采用XML格式文件描述。