CN103186417B - A kind of method of Service Management - Google Patents

Abstract

The present invention is a method of service management applied to a software system, including: subdividing a service through a business domain, each business domain having a business domain identifier; adding a projection of the service on the business domain according to the subdivision result To at least one service provider, the projection includes a business domain identifier, a service type, and a service creator; when requesting a service, obtain the projected service creator according to the business domain identifier and service type, and the service creator returns a service instance. The present invention not only subdivides the service through the business field, so that the service requester only needs to care about the business field and the service interface type, but also uses the service provider and the service creator to store and manage the service, and adds the service projection to the service according to the application scope of the service. provider. At the same time, the present invention provides an upward addressing service provider link, which ensures that the service can be correctly located and stored. In addition, the present invention also provides different service life cycle types.

Description

A method of service management

technical field

The invention relates to the field of enterprise resource planning systems, in particular to a service management method.

Background technique

Service orientation is an approach to architecting software systems. In the service-oriented architecture, the functions are carried by services, and the functions are provided externally through the interface.

Service-oriented architecture enables common basic functions to be defined in services, making the realization of functions easier to manage, maintain and expand, and enabling software systems to quickly respond to changing requirements and respond to different application environments.

Classification of services into service layers is very important, reflecting the composite or irregular nature of services, which, if poorly partitioned, will result in more and more fine-grained services being defined, designed, and deployed with little control , leading to major performance, scalability, and management issues.

In a traditional way, obtaining a service is generally through a service interface. The interface is a contract for the implementation of service functions, and the service implementation exposes some methods through the interface to provide functions. To obtain a service is to obtain the service implementation corresponding to the service interface by specifying the service interface type. The service definition process is not directly related to the business. For example, the storage service is implemented in one way in the order, another way in the sales order, and another way in the receipt. Therefore, in order to realize the same function with different business logics, different service interfaces need to be established, which makes it difficult to manage the large number of service interfaces. For example, (see Figure 1), the functionality of a storage service needs to be implemented by a storage service. In the traditional way, it may be necessary to define three different interfaces (service interface M, service interface N, and service interface O) and then implement services in service implementation M and service implementation O, so that different interfaces can be specified when calling services to obtain corresponding service realization.

Contents of the invention

The purpose of the present invention is to solve the above problems and provide a method of service management. This method not only subdivides services through business domains, so that service requesters only need to care about business domains and service interface types, but also through service providers and The service creator stores and manages the service, and adds the service to the service provider according to the application scope of the service. At the same time, the method provides an upward addressing service provider link, ensuring that the service can be correctly located and stored. Additionally, this method provides different service lifecycle types.

To achieve above-mentioned purpose, the present invention adopts following technical scheme:

A method for service management, where the method for service management is applied to a software system, comprising the following steps:

(a) Subdividing a service by business domain, each business domain has a business domain identifier;

(b) adding a projection of the service on the business domain to at least one service provider according to the segmentation result, the projection including the business domain identifier, a service type, and a service creator;

(c) When requesting the service, obtain the projected service creator according to the business domain identifier and the service type, and return a service instance from the service creator.

Further, the at least one service provider is a plurality of chained service providers.

Further, in the step (b), the projection is added to multiple service providers according to the scope of application of the projection.

Further, in the described step (c), further include the following steps:

When requesting the service, request the service through the GetService method provided by the at least one service provider, search from the at least one service provider to other service providers one by one, and search for the projected service creator; and

When the projected service creator is retrieved, the service instance is returned by the service creator.

Further, in the step of returning the service instance, when the projection cannot be retrieved, an exception is thrown.

Further, in the step of retrieving the projected service creator, it further includes stopping the retrieval when it is found that the service type has an interrupt flag.

Further, after the step of subdividing the service by business domain, it further includes:

According to the identification of the business field, it is divided into different file directories, and the service is configured in all the file directories.

Further, the said software system is an enterprise resource planning system.

In addition, the present invention also provides a service management method, which is applied to a software system, and includes the following steps:

Identify common functions and define service interfaces in software systems;

According to the service interface, provide specific service implementation corresponding to the service interface for each business domain;

Set the life cycle type for each service, and specify the service creator according to the life cycle type;

According to the scope of service application, put the service interface type, the business domain identifier and the service creator together into the service provider as a service projection;

When receiving a service request, retrieve the corresponding service creator from one of the multi-tier service providers through the business domain identifier and service type;

Retrieving the corresponding service creator layer by layer through the service link of the multi-layer service provider; and

When the corresponding service creator is retrieved, the service creator returns the service instance according to the lifecycle type of the service.

The advantages of the present invention are:

(1) By subdividing services by business domains, service requesters only need to care about business domains and service interface types, which is easier to develop while maintaining the diversity of service implementations;

(2) Organize services and service providers that are closely related to each other, and service providers provide a unified service call method (GetService) externally, which is easier for system development and design;

(3) Provide an upwardly addressable service provider link to ensure that services can be correctly located and stored, and perfectly support the system's complex applications and requirements for the client-server model; and

(4) Provide different service life cycle types to meet complex business requirements in software systems.

Description of drawings

Figure 1 is a schematic diagram of the traditional way of using different interfaces to complete service realization;

Fig. 2 is a flow chart of the steps of the service management method of the present invention;

Fig. 3 is a schematic diagram of the subdivided service of the business field described in the present invention;

Fig. 4 is a schematic diagram of the relationship between service projection and service provider in the present invention;

Fig. 5 is a schematic diagram of the service creator process for the service provider to retrieve the projection layer by layer according to the present invention;

Fig. 6 is a schematic diagram of specific implementation steps of the service management method according to an embodiment of the present invention.

detailed description

The specific implementation of the service management method of the present invention will be described in detail below in conjunction with the accompanying drawings.

Referring to FIG. 2 , it is a block diagram of the steps of a service management method according to the present invention. The service management method is applied to a software system and includes the following steps:

S101: Subdivide a service by business fields, each business field has a business field identifier (M12 in FIG. 3 represents the business field subdivision service). A service is a category of function points in a software system, and the function points are used to complete a required function. The present invention divides services according to the business field, agrees on the realization of the service through a stable general interface, and associates the specific service realization with the business field through the business field identifier (TypeKey), wherein the TypeKey is a kind of business identifier, and is added through the general interface. Business domain identifier (TypeKey), to obtain the correct service implementation in the business domain. An example is given below to illustrate subdividing services according to business domains, see Figure 3: service implementation A (M122) and service implementation C (M124) are two components of the business domain identifier TypekeyA and business domain identifier TypekeyC of the general service interface ISaveService. a projection. When acquiring services, if you are in business domain A, you can find the specific service implementation A corresponding to business domain A, and if you are in business domain C, you can find the specific service implementation C corresponding to business domain C. Therefore, there is no need to inform the service provider which service interface corresponding to the business domain is required, and the service can be accessed without additional interfaces.

S102: According to the business requirements in each business domain, provide service implementation by writing codes for each service interface of each business domain, and reuse the same service implementation for different business domains with the same functional business requirements.

S103: Divide the service into different file directories according to the business field identification, and configure the service in the file directory.

Here, different file directories are distinguished according to the business domain identifier, because when the system loads the service according to the configuration, it determines which application domain the service should be applied to according to the folder where the configuration file is located. Each file directory corresponds to a business domain identifier (TypeKey), that is, corresponds to a business domain. In particular, not all services need to be configured in the file directory identified by the business domain, and there are public services that do not need to specify a TypeKey, which can be configured in the root directory or directly registered in the code.

S104: Add a projection (project) of the service on the business domain to multi-layer chained service providers according to the subdivision result, the projection includes the business domain identifier (TypeKey), a service interface type (ISaveService) and a service creator. The projection refers to different service implementations for service interfaces in different service fields. When one of the service providers in the multi-layer chain receives a service request, a dictionary M111 is built in the service provider M11 of FIG. 4 , and the dictionary M111 includes a plurality of key-value pairs such as key M112 and value M113, the key-value pair is the content of the above projection, the key M112 (key) is the business domain identifier and service interface type, and the value M113 (value) is an internal service creator. The key M112 and the value M113 are in one-to-one correspondence. Another example is given below to illustrate the relationship between service projection and service provider. In Figure 4, the service interface ISaveService has different projections in different business fields A, B, and C, that is, service realization A (M122), service realization B (M123) and service implementation C (M124), where the three keys are set to ISaveService+A, ISaveService+B, ISaveService+C respectively. Since the service type has been provided and the service implementation has been written into the code, for the service provider, when the software system is executed, the service will generate a corresponding service instance, and the service instance is completed through the service creator. Service creators are used to create service instances according to different types of service life cycles. Services have different lifecycle types, including SingleGet, Singleton, Callback, and WeakReference. Among them, SingleGet is to generate a new service instance each time it is called; Singleton is to reuse the same instance, that is, a service instance will be generated when the service is first called, and then the same service instance will be used to complete the service when it is called Function; Callback is the process of creating a service instance, allowing the input of creation logic to determine how to create a service instance, and WeakReference returns a weak reference pointing to the service instance. In addition, SingleGet, Singleton, and WeakReference have fixed creation logic, while Callback can customize the creation logic, which increases flexibility. Both Singleton and WeakReference will check whether a service instance has been created. If there is, it will not be created. If not, a new service instance will be created. However, the service instance of Singleton is not allowed to be destroyed, and the service instance of WeakReference will be released when it is not in use. It needs to be recreated after release.

S105: When one of the service providers in the multi-layer chain is requested for the service, start searching from one of the service providers according to the specified business domain identifier and the service interface type The service creator for this projection. The service provider is also called the service container, and the key-value pair is used in the service provider, and the key-value pair is stored in the service creator. When any service provider receives a service request, it will return the required service instance, which is provided by the service creator. There are two ways to dynamically attach a service to the service environment. One way is to be directly associated with the service provider. At runtime, by setting the service provider associated with the service object, the service object can be dynamically connected to or disconnected from a service environment. Another way is to hook up with another service, not directly associated with the service provider, and obtain the service provider through the other service. For example, service A is hooked to another service B, and service B is in the client service environment, then service A can also share services in the client service environment.

S106: If the projected service creator is not found, search upward layer by layer from the requested service provider to other service providers. As shown in Figure 5, the bottom layer first calls the service, and the user control (UserControl) (for example, opening the service form) opens the window and contains a service container (service provider M11), which contains some control services related to this control. For example, the format control, the service of displaying the color of a certain field, these services are all registered in the service provider of the user control, and can be obtained directly. For another example, click the save toolbar button to call the client legitimacy check. Since the legitimacy check service is directly registered in this form, it can be obtained directly from the service provider of the form. For example, if the storage service is to be executed, and the storage service is registered at the server end, then the service link of the multi-layer chained service provider is searched upward layer by layer. First, search in the service provider of the user control, that is, in the internal dictionary of the service provider M11, if not found, the request is forwarded to the service provider M20 of the upper layer, if the above-mentioned service provider If it is not found in the provider M20, it will be forwarded to the client service provider M30 again, and whether the key is found inside the client service provider M30, if there is, the service instance will be returned, and if not, then continue to search upwards (that is, in the client service provider M30). in the internal dictionary of the server service provider M40). If you look it up on the server side (on a server or appdomain machine), you need to cross network boundaries.

S107: When the projected service creator is retrieved, return the service instance. After receiving the save service call, the server service provider M40 retrieves and finds the key in the dictionary, obtains the service creator corresponding to the save service in the business domain from the corresponding value, and creates - Save the service instance and return it. A flag (field) is set in each service provider, which is used to identify the upper-level service provider of the service provider of the current level. In the step of retrieving the projection layer by layer, when it is necessary to cross the network boundary, if it is found that the service type has an interrupt flag, then stop searching the projected service creator layer by layer. That is to say, only search in the dictionary of the local service provider, and do not cross the network. If the projected service creator cannot be retrieved during the entire retrieval process (the retrieval process ends including searching the top-level service provider and interrupting the retrieval when crossing the network boundary), an exception will be thrown, that is, the service cannot be found.

Referring to Fig. 6, the method of a specific embodiment of the present invention is provided below, and its specific steps are as follows:

Step S601: First define some common functions and common interfaces in the software system, such as ISaveService, IApproveService, IDeleteService and other common interfaces. Then in a business field, for example, in order to realize the business logic of an order, a saved service implementation needs to be used in the order business logic. If it is found that there is no service implementation for saving an order, it is necessary to create a service implementation for saving the order service, that is, implement the ISaveService interface.

Step S602: When defining a service, set a function point category flag (service type). The service function point is realized when the function package is applied.

Step S603: When defining the service (implementing the service), implement it according to the method agreement in the service interface and the business requirements in the business domain. The Save method is declared in the service interface ISaveService. When implementing the save service, the implementation of the ISaveService interface needs to provide the specific implementation of the Save method.

Step S604: The function point of the service and the interpreter of the function point of the service are preset. After receiving the function point set, the function point interpreter places the service projection corresponding to the function point in the service container of the corresponding service provider according to the function point category mark, and the application method of the function point is also stored in the interpreter.

Step S605: The storage service is marked as a service type on the function point of the storage service. When the software system is loaded, the storage service is placed in the service provider container. At the same time, it is necessary to define and set the life cycle type of the storage service (for example, the life cycle type of the storage service is Singleton). At this point, the save service definition is complete.

Step S606: Configure the storage service in a function package, for example, place the storage service in the function package of the order. The business field of the order is identified as A. During the order loading process, the system registers the save service to the server service provider. In the internal dictionary of the server service provider, the key is ISaveService+A, and the value is the service corresponding to the save service creator. So far, the system has completed the process of loading the service stored in the order.

Step S607: When the software system is executed, the client front-end interface saves the documents of business domain A, and the back-end requests the saving service from the service provider of the current control, adopts the general method entry GetService, and uses ISaveService as the service interface type , with A as the business domain identifier. After receiving the save service call, the service provider of the current user control retrieves the key of (ISaveService+A) in the dictionary of the service provider of the user control.

Step S608: When the service provider of the user control is not found in the dictionary, find the upper-level window service provider according to the service link. When the form service provider receives the save service call, it retrieves the key of (ISaveService+A) in the form service provider's dictionary. When the form service provider finds that it is not found in the dictionary, find the client service provider according to the service link. When the client service provider receives the save service call, it retrieves the key of (ISaveService+A) in the dictionary of the client service provider. If the client service provider service discovery is not found in the dictionary, according to the service link, across the network boundary to the server service provider.

Step S609: After the server service provider receives the save service call, it searches for the key (ISaveService+A) in the dictionary of the server service provider. If the server-side service provider finds the key, it obtains the service creator corresponding to the save service in business domain A from the corresponding value, and since the life cycle type of the save service is Singleton, it is judged whether there is an existing SaveService service If there is an instance, it will not be created, if not, the service creator will create a new save service (SaveService) instance.

Step S610: call the service instance business implementation method of the saving service, and execute the saving logic of document A.

The beneficial effect of the present invention is that, by subdividing services in the business field, the service requester can use the combination of the business field and the service interface type, as well as the upwardly addressed service provider link, to correctly locate and store the service, and fulfill the development requirement.

The above is only a preferred embodiment of the present invention, it should be pointed out that for those of ordinary skill in the art, without departing from the principle of the present invention, some improvements and modifications can also be made, and these improvements and modifications should also be considered Be the protection scope of the present invention.

Claims (6)

1. A method for service management, the method for service management is applied in a software system, characterized in that it comprises the following steps: (a) Subdividing a service by business domain, each business domain has a business domain identifier; (b) adding a projection (project) of the service on the business domain to at least one service provider according to the segmentation result, the projection including the business domain identifier, a service type, and a service creator ; (c) when requesting the service, obtain the projected service creator according to the business domain identifier and the service type, and return a service instance from the service creator; Wherein, the at least one service provider is a plurality of chained service providers; In the step (b), add to the plurality of service providers according to the application scope of the projection; In described step (c), further comprise the following steps: When requesting the service, request the service through the GetService method provided by the at least one service provider, search from the at least one service provider to other service providers one by one, and search for the projected service creator; and When the projected service creator is retrieved, the service instance is returned by the service creator. 2. The service management method according to claim 1, wherein in the step of returning the service instance, when the projection cannot be retrieved, an exception is thrown. 3. The service management method according to claim 1, characterized in that, in the step of retrieving the projected service creator, further comprising stopping the retrieval when it is found that the service type has an interrupt flag. 4. The service management method according to claim 1, characterized in that, after the step (a), further comprising: According to the identification of the business field, it is divided into different file directories, and the service is defined in all the file directories. 5. The service management method according to claim 1, wherein said software system is an enterprise resource planning system. 6. A method for service management, comprising the following steps: Identify common functions and define service interfaces in software systems; According to the service interface, provide specific service implementation corresponding to the service interface for each business domain; Set the life cycle type for each service, and specify the service creator according to the life cycle type; Put the service interface type, the business domain identifier and the service creator together into the service provider as a service projection according to the service application scope; When receiving a service request, retrieve the corresponding service creator from one of the multi-tier service providers through the business domain identifier and service type; Retrieving the corresponding service creator layer by layer through the service link of the multi-layer service provider; and When the corresponding service creator is retrieved, the service creator returns the service instance according to the life cycle type of the service.