CN103186417B - 一种服务管理的方法 - Google Patents

Abstract

本发明是一种服务管理的方法应用于一软件系统中,包括：通过业务领域细分一服务，每一业务领域具有一业务领域标识；根据细分结果将服务在业务领域上的一投影添加至至少一服务提供者中，投影包括业务领域标识、一服务类型以及一服务创建器；在请求服务时，根据业务领域标识和服务类型，取得投影的服务创建器，由服务创建器返回一服务实例。本发明不仅通过业务领域细分服务，使服务的请求者仅需关心业务领域和服务接口类型，而且使用服务提供者及服务创建器储存及管理服务，根据服务的应用范围将服务投影添加到服务提供者中。同时本发明提供向上寻址的服务提供者链路，保证了服务可被正确定位及储存。此外，本发明还提供不同的服务生命周期类型。

Description

一种服务管理的方法

技术领域

本发明涉及企业资源规划系统领域，尤其涉及一种服务管理的方法。

背景技术

面向服务是一种架构软件系统的方法。面向服务的架构中功能由服务承载，通过接口对外提供功能。

面向服务架构使得公用基础功能可以在服务中进行定义，使得功能的实现更易于管理、维护和扩展，使得软件系统可以快速响应变化的需求与应对不同的应用环境。

将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性，如果划分方式不佳，将会导致越来越多的小粒度的服务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题。

在传统方式中，获取一服务一般是通过服务接口。接口是对服务功能实现的约定，服务实现通过接口对外公开一些方法以提供功能。获取服务是通过指定服务接口类型从而获得服务接口对应的服务实现。服务的定义过程与业务无直接关联，例如保存服务，在订单中以一种方式实现，在售货单中以另一种方式实现，在入货单中又以其他方式实现。因此为了实现业务逻辑不同的同一功能，需要建立不同的服务接口，使得服务接口数量庞大难以管理。例如，（参见图1所示），保存服务的功能需有一保存服务实现。在传统方式中可能需要定义三个不同接口（依次是服务接口M、服务接口N、服务接口O）进而在服务实现M和服务实现O中实现服务，才能在调用服务时指定不同接口以获取对应的服务实现。

发明内容

本发明的目的在于解决上述问题，提供一种服务管理的方法，该方法不仅通过业务领域细分服务，使得服务的请求者仅需关心业务领域和服务接口类型即可，而且通过服务提供者及服务创建器储存及管理服务，根据服务的应用范围将服务添加到服务提供者中。同时该方法提供向上寻址的服务提供者链路，保证了服务可以被正确定位及储存。此外，该方法还提供不同的服务生命周期类型。

为实现上述的目的，本发明采用下述技术方案：

一种服务管理的方法，所述服务管理的方法应用于一软件系统中,包括以下步骤：

(a)通过业务领域细分一服务,每一业务领域具有一业务领域标识；

(b)根据细分结果将所述服务在所述业务领域上的一投影添加至至少一服务提供者中，所述投影包括所述业务领域标识、一服务类型以及一服务创建器；

(c)在请求所述服务时，根据所述业务领域标识和所述服务类型，取得所述投影的服务创建器，由所述的服务创建器返回一服务实例。

进一步，所述至少一服务提供者为多个相链的服务提供者。

进一步，所述的步骤(b)中,依据所述投影的应用范围将所述投影添加至多个所述服务提供者中。

进一步，所述的步骤(c)中,进一步包括以下步骤：

在请求所述服务时，通过所述至少一服务提供者提供的GetService方法请求服务,从所述至少一服务提供者开始逐一检索至其它服务提供者，查找所述投影的服务创建器；以及

当检索到所述投影的服务创建器时,由所述服务创建器返回所述服务实例。

进一步，在返回所述服务实例的步骤中,当检索不到所述投影时,引发异常。

进一步，在检索所述投影的服务创建器的步骤中,进一步包括当发现所述服务类型具有中断标记时,则停止检索。

进一步，在通过业务领域细分所述服务的步骤之后,进一步包括：

按照业务领域标识,分为不同的文件目录,将所述服务配置于所述所有文件目录中。

进一步，所述的软件系统是一企业资源规划系统。

此外，本发明还提供一种服务管理的方法，应用于一软件系统中,包括如下步骤：

在软件系统中识别通用功能并定义服务接口；

根据服务接口，为每个业务领域提供服务接口对应的具体的服务实现；

为每一服务设置生命周期类型，根据生命周期类型指定服务创建器；

按照服务应用范围，将所述服务接口类型、所述业务领域标识以及所述服务创建器一起作为服务投影放入服务提供者中；

当接收服务请求，通过业务领域标识和服务类型，从多层服务提供者的其中一服务提供者开始检索对应的服务创建器；

通过所述多层服务提供者的服务链路逐层向上检索对应的服务创建器；以及

当检索到所述对应的服务创建器时,服务创建器依据所述服务的生命周期类型返回所述服务实例。

本发明的优点在于：

（1）通过业务领域细分服务，服务的请求者仅需关心业务领域和服务接口类型即可，保持服务实现的多样性的同时，更易于开发；

（2）将彼此紧密相关的服务与服务提供者组织在一起，服务提供者对外提供统一的服务调用方法（GetService），更易于系统的开发和设计；

（3）提供向上寻址的服务提供者链路，保证了服务可以被正确定位及储存，完美支持系统对客户机-服务器模式的复杂应用和需求；以及

（4）提供不同的服务生命周期类型，满足软件系统中复杂的业务需求。

附图说明

图1是传统方式利用不同接口完成服务实现的示意图；

图2是本发明所述服务管理方法的步骤流程框图；

图3是本发明所述业务领域细分服务的示意图；

图4是本发明所述服务投影和服务提供者关系的示意图；

图5是本发明所述服务提供者逐层向上检索所述投影的服务创建器过程的示意图；

图6是本发明一实施例所述服务管理方法的具体实施步骤示意图。

具体实施方式

下面结合附图对本发明服务管理的方法的具体实施方式做详细说明。

参见图2是一种依据本发明的服务管理方法的步骤流程框图，所述服务管理方法应用于一软件系统中，包括以下步骤：

S101：通过业务领域细分一服务,每一业务领域具有一业务领域标识(如图3中M12表示所述业务领域细分服务)。服务在软件系统中为一功能点的类别，所述的功能点用于完成一需求的功能。本发明是依照业务领域划分服务，通过一稳定的通用接口约定服务实现，并通过业务领域标识（TypeKey）将具体服务实现与业务领域进行关联，其中TypeKey是一种业务标识，通过通用接口加上业务领域标识（TypeKey），在业务领域内获取正确的服务实现。以下给出一个例子用于说明按照业务领域细分服务，参见图3：服务实现A(M122)和服务实现C(M124)是保存服务通用接口ISaveService在业务领域标识TypekeyA和业务领域标识TypekeyC的两个投影。在获取服务时，若在业务领域A，则可找到业务领域A对应的具体服务实现A，若在业务领域C时，则可找到业务领域C对应的具体服务实现C。因此，不需要告知服务提供者需要哪一业务领域对应的服务接口，也不需要额外接口就能使服务被访问。

S102：根据每一业务领域中的业务需求，为每一业务领域的每一服务接口通过编写代码提供服务实现，对同一功能业务需求相同的不同业务领域可以复用同一服务实现。

S103：按照业务领域标识,分为不同的文件目录,将所述服务配置于所述文件目录中。

在此，根据业务领域标识区分不同的文件目录，是因为系统在根据配置加载服务时，是按照配置文件所处的文件夹确定该服务应该应用于哪个应用领域。每个文件目录对应一个业务领域标识（TypeKey），也即对应于一个业务领域。特别地，并不是所有服务都需要配置在业务领域标识的文件目录中，还有不需要指定TypeKey的公用服务，可以配置在根目录下或者在代码中直接注册服务。

S104：根据细分结果将所述服务在所述业务领域上的一投影(project)添加至多层相链的服务提供者中，所述投影包括所述的业务领域标识(TypeKey)、一服务接口类型(ISaveService)和一服务创建器。所述投影是指在不同业务领域中对于业务接口有不同的业务实现。当所述多层相链的服务提供者的其中一服务提供者接收到服务请求时,参见图4的服务提供者M11内部置有一字典M111，所述的字典M111包括多个键值对如键M112和值M113，所述键值对即为上述投影的内容，所述的键M112(key)为业务领域标识和服务接口类型，所述的值M113(value)为一个内部的服务创建器。所述的键M112和值M113是一一对应的关系。以下再给出一个例子用于说明服务投影和服务提供者关系，在图4中,服务接口ISaveService在不同的业务领域A、B、C具有不同的投影，即服务实现A(M122)、服务实现B(M123)和服务实现C(M124)，此处三个键分别设置为ISaveService+A,ISaveService+B,ISaveService+C。由于服务类型已提供，服务实现已写入代码中，对于服务提供者而言，当软件系统执行时，所述的服务会生成相应的服务实例，所述服务实例是通过服务创建器来完成。服务创建器用于依照服务的生命周期的不同类型以创建服务实例。服务有不同的生命周期类型，所述的生命周期类型包括SingleGet、Singleton、Callback和WeakReference。其中SingleGet为当每次被调用时产生新的一服务实例；Singleton为复用同一个实例，即服务被第一调用时会生成一服务实例，之后所述服务被调用时使用同一服务实例以完成功能；Callback为服务实例创建的过程，允许传入创建逻辑以决定如何创建一服务实例，WeakReference为返回指向服务实例的弱引用。此外，SingleGet、Singleton和WeakReference为固定的创建逻辑，而Callback可自定义创建逻辑，增加了灵活度。Singleton和WeakReference均会检查是否已创建一服务实例，若有则不创建，若无则创建一新服务实例，但Singleton的服务实例不允许销毁，WeakReference的服务实例在不使用时会被释放，被释放后需重新创建。

S105：在所述多层相链的服务提供者的其中一服务提供者被请求该服务时，根据指定所述业务领域标识和所述服务接口类型，从所述的其中一服务提供者开始检索该投影的服务创建器。服务提供者又称服务容器，在服务提供者中使用键值对，所述键值对存放服务创建器。任一服务提供者在接收到服务请求的时候，将返回所需的服务实例，服务实例由服务创建器提供。将一个服务与服务环境进行动态挂接，有2种方式。一种方式是直接与服务提供者有关联。在运行时，通过设置服务对象关联的服务提供者，可将服务对象动态连接到服务环境中，或从一服务环境中断开。另一方式是与另一服务进行挂接，不直接与服务提供者关联，通过该另一服务获取服务提供者。例如，服务A与另一服务B进行挂接，服务B是处于客户端服务环境中，那么，服务A也能共享到客户端服务环境中的服务。

S106：若未找到所述投影的服务创建器，从被请求的服务提供者逐层向上检索至其它的服务提供者。如在图5中，底层首先调用服务，用户控件(UserControl)（例如打开服务表单）打开窗口即包含一服务容器（服务提供者M11），其中包含一些与此控件相关的控制服务。例如格式控制、某一字段显示颜色的服务，这些服务都注册在用户控件的服务提供者内，直接获取即可。又如，点击保存工具栏按钮，调用客户端合法性检查，由于合法性检查服务是直接注册在此窗体之内，因此可以直接在窗体的服务提供者获取。例如若要执行保存服务，而保存服务是注册在服务端，于是，通过所述多层相链的服务提供者的服务链路逐层向上检索。首先在用户控件的服务提供者中，即在服务提供者M11的内部字典中进行查找，若没有找到，则此请求转发至上一层的服务提供者M20，若在所述的上一层的服务提供者M20中也没有找到，则再一次转发至客户端服务提供者M30，在客户端服务提供者M30内部查找有无该键，若有则返回服务实例，若无则继续向上查找（即在服务端服务提供者M40的内部字典中查找）。若在服务端（在服务器或appdomain机器上）查找，需要跨越网络边界。

S107：当检索到所述投影的服务创建器时,返回所述服务实例。服务端服务提供者M40接收到保存服务的调用后，在字典中检索并找到所述键，从对应的值中获取业务领域中的保存服务对应的服务创建器，根据生命周期类型的设置，创建一保存服务实例，并予以返回。在每一服务提供者中设置有一标记（字段），用于标识当前等级的服务提供者的上级服务提供者。在逐层向上检索所述投影步骤中，当需要跨越网络边界时，若发现所述服务类型具有中断标记，则停止逐层向上检索该投影的服务创建器。也就是说，只在本地的服务提供者的字典中进行查找，不进行跨越网络。如果在整个检索过程中检索不到所述投影的服务创建器（检索过程结束包括检索完最上层的服务提供者以及在跨越网络边界时中断检索）时，会引发异常，即服务找不到。

参见图6，以下给出本发明一具体实施例的方法，其具体步骤如下：

步骤S601：首先在软件系统中定义一些通用功能和通用接口，例如ISaveService,IApproveService,IDeleteService等通用接口。然后在一业务领域，比如为了实现订单的业务逻辑，订单业务逻辑中需运用一保存的服务实现。若发现没有所述保存订单的服务实现，需为订单服务创建所述保存的服务实现，即实现ISaveService接口。

步骤S602：在定义服务时，设置一功能点类别标记（服务类型）。当功能包应用时所述服务功能点被实现。

步骤S603：在定义服务（实现服务）时，根据服务接口中的方法约定及业务领域中的业务需求来进行实现。在服务接口ISaveService中声明了Save方法，在实现保存服务时，实现ISaveService接口，需提供Save方法的具体实现。

步骤S604：服务的功能点和服务的功能点解释器预先设定。功能点解释器在接收功能点集合之后，依据功能点类别标记，将所述功能点对应的服务投影置于相应的服务提供者的服务容器中，功能点的应用方法也存放于解释器中。

步骤S605：所述保存服务，在保存服务的功能点上标注为服务类型。在软件系统加载的时候，将保存服务置于服务提供者容器中。同时需要对保存服务的生命周期类型进行定义设置（例如，所述保存服务生命周期类型为Singleton）。至此，保存服务定义完毕。

步骤S606：将所述的保存服务配置于一功能包中，例如将所述保存服务置于订单的功能包中。订单的业务领域标识为A，在订单加载过程中，系统将保存服务注册至服务端服务提供者，在服务端服务提供者的内部字典中，键为ISaveService+A，值为保存服务对应的服务创建器。至此，完成系统对订单中保存服务的加载过程。

步骤S607：在软件系统执行时，客户端前端界面对业务领域A的单据进行保存操作，后端即向当前控件的服务提供者请求保存服务，采用通用的方法入口GetService，以ISaveService作为服务接口类型，以A为业务领域标识。当前用户控件的服务提供者接收到保存服务的调用后，在用户控件的服务提供者的字典中检索（ISaveService+A）的键。

步骤S608：当用户控件的服务提供者发现在字典中没有找到，根据服务链路，找到上层窗体服务提供者。当窗体服务提供者接收到保存服务的调用后，在窗体服务提供者的字典中检索（ISaveService+A）的键。当窗体服务提供者发现在字典中没有找到，根据服务链路，找到客户端服务提供者。当客户端服务提供者接收到保存服务的调用后，在客户端服务提供者的字典中检索（ISaveService+A）的键。如果客户端服提供者务发现在字典中没有找到，根据服务链路，跨越网络边界至服务端服务提供者。

步骤S609：当服务端服务提供者接收到保存服务的调用后，在服务端服务提供者的字典中检索（ISaveService+A）的键。如果服务端服务提供者找到该键，从对应的值中获取业务领域A中的保存服务对应的服务创建器，由于所述保存服务的生命周期类型为Singleton，所以进行判断是否已有的SaveService服务实例，若有则不创建，若无则所述服务创建器创建一个新的保存服务（SaveService）实例。

步骤S610：调用所述保存服务的服务实例业务实现方法，执行单据A的保存逻辑。

本发明有益效果在于，通过业务领域细分服务，使得服务请求者可以利用业务领域和服务接口类型组合方式，以及向上寻址的服务提供者链路，正确定位及存储服务，完成开发需求。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (6)

1.一种服务管理的方法，所述服务管理的方法应用于一软件系统中,其特征在于，包括以下步骤：

(a)通过业务领域细分一服务,每一业务领域具有一业务领域标识；

(b)根据细分结果将所述服务在所述业务领域上的一投影(project)添加至至少一服务提供者中，所述投影包括所述业务领域标识、一服务类型以及一服务创建器；

(c)在请求所述服务时，根据所述业务领域标识和所述服务类型，取得所述投影的服务创建器，由所述的服务创建器返回一服务实例；

其中，所述至少一服务提供者为多个相链的服务提供者；

在所述的步骤(b)中,依据所述投影的应用范围添加至所述多个服务提供者中；

在所述的步骤(c)中,进一步包括以下步骤：

在请求所述服务时，通过所述至少一服务提供者提供的GetService方法请求服务，从所述至少一服务提供者开始逐一检索至其它服务提供者，查找所述投影的服务创建器；以及

当检索到所述投影的服务创建器时,由所述服务创建器返回所述服务实例。

2.如权利要求1所述的服务管理的方法，其特征在于，在返回所述服务实例的步骤中,当检索不到所述投影时,引发异常。

3.如权利要求1所述的服务管理的方法，其特征在于，在检索所述投影的服务创建器的步骤中,进一步包括当发现所述服务类型具有中断标记时,则停止检索。

4.如权利要求1所述的服务管理的方法，其特征在于，所述的步骤(a)后,还包括：

按照业务领域标识,分为不同的文件目录,将所述服务定义于所述所有文件目录中。

5.如权利要求1所述的服务管理的方法，其特征在于，所述的软件系统是一企业资源规划系统。

6.一种服务管理的方法，其特征在于，包括以下步骤：

在软件系统中识别通用功能并定义服务接口；

根据服务接口，为每个业务领域提供服务接口对应的具体的服务实现；

为每一服务设置生命周期类型，根据生命周期类型指定服务创建器；

按照服务应用范围，将所述服务接口类型、所述业务领域标识以及所述服务创建器一起作为服务投影放入服务提供者中；

当接收服务请求，通过业务领域标识和服务类型，从多层服务提供者的其中一服务提供者开始检索对应的服务创建器；

通过所述多层服务提供者的服务链路逐层向上检索对应的服务创建器；以及

当检索到所述对应的服务创建器时,服务创建器依据所述服务的生命周期类型返回所述服务实例。