JP4444944B2 - Service linkage method - Google Patents

Description

  The present invention relates to a service cooperation method for providing an appropriate service by detecting and linking service components on a network.

  With the advancement of IT technology, not only PCs but also various devices such as mobile phones, home appliances, and sensors are connected to a network, and a ubiquitous environment for supporting the lives of users is being realized. In the ubiquitous environment, these devices and functions are organically linked, and a context-aware service that has been difficult to realize is expected. Because user needs change dynamically according to real-world conditions such as location, service components do not have to be created in advance by the service provider as in the past. The concept of service cooperation that provides services by combining the two is important.

As an existing technology, BPEL (Business Process Execution Language for Web Services), which is a technique for linking individual WSs (Web Services), is attracting attention (see, for example, Non-Patent Document 1). The BPEL is a language for describing a procedure for sequentially calling and executing a plurality of Web services as a series of business flows. Using the BPEL, it is possible to define which WS is to be called when and under what conditions in a series of business processes such as “accepting an order” and “checking inventory”.
OASIS, Web Service Business Process Execution Language Version 2.0 Committee Draft, [online], 17th May, 2006, [October 19, 2006 search], Internet <URL: http://www.oasis-open.org/committees /download.php/18714/webpel-specification-draft-May17.htm

  However, BPEL is originally targeted for B2B (Business to Business), and it is necessary to determine the WS to be used in advance and deploy the BPEL document and connection definition corresponding to the service flow to the BPEL execution engine. Therefore, it is difficult to detect, bind, and execute WS according to the user's situation. Note that the term “deployment” means close to “installation”, which is to prepare a network application, WS, etc. for use, but “install” means to introduce software into a computer. On the other hand, the deployment is to make a software that is used from the outside via a network or a component that is referenced by other software available.

When BPEL is applied to service composition in accordance with the user situation, specifically, there are the following problems. That is,
(1) Since the BPEL document describes the port type name and operation name of WSDL (Web Service Description Language), which is interface information of each WS, there is a problem that it can be applied only to WS that perfectly matches them. is there.
(2) For BPEL execution, it is necessary to deploy in advance the connection definition information indicating which BPEL document and which WS to connect to, and WS has already been determined before execution.

  The present invention has been made in consideration of such circumstances, and its purpose is to provide a service user with an appropriate service by linking a plurality of service components on the network according to the service user situation. It is to provide a service cooperation method that can be provided.

  In order to solve the above-described problem, the present invention provides a service linkage method for linking service components based on a specified service scenario, and a first storage step for storing a plurality of service components, and a service user A second storage step for storing a user context indicating a situation; a service scenario setting step for setting a service scenario in which metadata information representing service component interface information or service component operation is described; Service component group detection step of detecting a service component group to be used from the plurality of service components based on interface information or metadata information described in the service scenario A service component selection step of selecting a service component corresponding to the user context from the detected service component group, and a service component execution / cooperation step of executing and linking the selected service component. And

  In the above invention, the present invention further includes a third storing step of storing an equivalence relationship or inheritance relationship between metadata of service components, wherein the service component group detection step includes an equivalence relationship or inheritance between the metadata. A service component group to be used is detected based on the relationship.

  According to the present invention, in the above-described invention, user policy information indicating service user status and information indicating what service component the service user prioritizes from the detected service component group. And a scoring step of scoring based on the degree of matching with the metadata information representing the nature of the service component, wherein the service component selection step selects a service component with a higher score It is characterized by.

  According to the present invention, in the above-described invention, the service component execution / cooperation step includes metadata information described in the service scenario, metadata information representing an operation of the selected service component, and the service component. Using the mapping information that represents the mapping between the interface information and the interface information, the service information is converted into an actual interface of the service component, and the selected service component is executed and linked.

  In the present invention, the interface information includes at least operation information, input message information, and output message information, and the service component group detection step includes the operation information, input message information, and output message information. A service component group that can be used is detected based on the interface information.

  The present invention further includes a presenting step of presenting the detected service component group to be selected by a service user in the above invention, wherein the service component selecting step includes a service component selected by the service user, It is selected as a service component to be executed and linked.

  The present invention is characterized in that, in the above invention, the service component selection step randomly selects a service component to be executed and linked from the detected service component group.

  According to the present invention, in the above-described invention, when the service component is specified by the interface information in the service scenario, the service component execution / cooperation step executes the selected service component based on the interface information. And work together.

  According to the present invention, in the above invention, the service scenario is directly input via a network, or is acquired by acquiring a service scenario to be used from a plurality of service scenarios stored in advance. Alternatively, the identification information of the service scenario to be used is designated from among a plurality of service scenarios stored in advance.

  According to the present invention, a service in which a plurality of service components are stored, a user context indicating a service user situation is stored, and interface information of the service component or metadata information indicating the operation of the service component is described. When a scenario is set, a service component group to be used is detected from a plurality of service components based on interface information or metadata information described in the set service scenario, and the detected service is detected. A service component corresponding to the user context is selected from the component group, and the selected service component is executed and linked. Therefore, the service component to be used can be detected and selected by abstractly describing the service component's operation using metadata information that has the same interface but different functions. By doing so, an advantage that an appropriate service according to the user situation can be provided is obtained.

  Further, according to the present invention, the equivalence relationship or the inheritance relationship between the metadata of the service components is stored, and used when detecting the service component group based on the equivalence relationship or the inheritance relationship between the metadata. Detect service component groups. Therefore, even if the vocabulary of metadata is different, there is an advantage that it is possible to detect a service component of equivalent metadata.

  Further, according to the present invention, from the detected service component group, user context information indicating a service user status, user policy information which is information indicating what service component the service user prioritizes, A score is assigned based on the degree of matching with metadata information representing the nature of the service component, and the service component with the higher score is selected. Therefore, there is an advantage that an appropriate service component can be selected with respect to the service user's situation and request priority.

  Further, according to the present invention, the metadata information described in the service scenario includes the mapping information indicating the mapping between the metadata information indicating the operation of the selected service component and the interface information of the service component. Is used to execute and link the selected service component by converting to the actual interface of the service component. Therefore, even if the service component operation call is described in the service scenario with metadata, it can be converted into the actual interface of the service component, and an appropriate service according to the user situation can be provided. Is obtained.

  According to the present invention, when detecting a service component group, an available service component group is detected based on interface information including operation information, input message information, and output message information. Therefore, there is an advantage that a service component can be easily detected according to interface information such as a port type name, an operation name, an input message name, and an output message name.

  In addition, according to the present invention, when selecting a service component, the service component group that is detected is presented to be selected by the service user, and the service component selected by the service user is to be executed and linked. Select as a component. Therefore, even when there is no metadata such as Profile information, there is an advantage that a service component can be selected flexibly.

  In addition, according to the present invention, a service component to be executed and linked is randomly selected from the detected service component group. Therefore, even when there is no metadata such as Profile information, there is an advantage that a service component can be selected flexibly.

  Further, according to the present invention, when a service component is specified by interface information in a service scenario, the selected service component is executed and linked based on the interface information. Therefore, there is an advantage that the service component can be executed and linked more easily without converting the metadata of the service scenario into an actual interface.

  According to the present invention, the service scenario is input directly via the network, or is a service scenario to be used acquired from a plurality of service scenarios stored in advance. Alternatively, identification information of a service scenario to be used among a plurality of service scenarios stored in advance is designated. Therefore, by diversifying the service scenario input method, there is an advantage that it is possible to deal with more flexibility.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

<System configuration>
FIG. 1 is a block diagram showing a configuration of a service cooperation system according to an embodiment of the present invention. In FIG. 1, the system according to the present embodiment includes a service cooperation engine 1, a service component information DB (database) 2, a user context policy DB 3, an ontology DB 4, a service scenario DB 5, a service component providing terminal 6, and a user terminal 7. Are connected via a network 8.

  The service cooperation engine 1 detects, selects, and executes a service component based on a service scenario. The service component providing terminal 6 is a terminal that provides a service component. The service scenario DB 5 stores the service scenario. The service component information DB 2 stores service component information, and both search using interface information and search using metadata information are possible.

  The ontology DB 4 stores relationships such as equivalence relationships between metadata and inheritance relationships, and is used for solving relationships between metadata of different vocabularies. The user context policy DB 3 stores user context information and user policy information, and can acquire user context information and user policy information according to a user identifier. The user terminal 7 is a terminal operated by the user, and is an instruction terminal for inputting and executing a service scenario to the service cooperation engine 1 or terminating the service.

  The present embodiment is characterized in that a user establishes a technique for using a service cooperation engine 1 installed in a personal terminal or a server to link service components in accordance with a user situation so that an appropriate service can be used. It is said.

In the present embodiment, the following two matters are assumed regarding the service component.
(1) The target component is a loosely coupled component such as WS or UPnP (Universal Plug and Play).
(2) Further, it is assumed that the service component publishes a service description (interface, attribute, etc.) indicating what function it is on the network.

<Example of service scenario description>
FIG. 2 is an example of a description of a service scenario according to this embodiment. In the above-described BPEL and PD4J (Process Definition for Java (Java is a registered trademark)), description is made with strict interface information using a WSDL port type and an operation name. On the other hand, in the service scenario according to the present embodiment, a service component is specified using metadata such as a category and a process. Further, as another difference from BPEL, PD4J, and the like, there is a search tag that searches for a service component during execution of the cooperation service, which is a feature of the service scenario according to the present embodiment. In BPEL, all WSs are determined before the service starts, and it is impossible to switch WSs during execution. On the other hand, in the service scenario according to the present embodiment, it is possible to describe that a service component is searched based on a parameter value during service execution.

  That is, the service scenario according to the present embodiment is different from BPEL in that the service component is specified by metadata and there is a description for searching for the service component during execution of the service called search.

<Service scenario and service component description>
In order to solve the problem of BPEL, in this embodiment, the interface information of each service component is not described in the service scenario which is a service flow, but is described abstractly using metadata representing the operation of a desired function. However, it aims to realize services according to the situation by detecting and selecting service component groups with the same functions but different interface names.

  FIG. 3 is a conceptual diagram for explaining a service scenario according to the present embodiment. The round block, square block, and hexagonal block shown in FIG. 3 indicate semantically equivalent functions, and the arrows indicate the order of control. In BPEL, it is necessary to describe a control flow in which each WS is strictly specified, but in a service scenario, it is possible to select from equivalent service components.

  Here, when considering service cooperation by describing service scenarios using metadata, it is possible to detect and use many service components that match the desired function. In order to achieve this, the following three are required.

(1) The service scenario writer must be able to describe in a unified format so that it can be described without being aware of the detailed implementation of each service component.
(2) The description of the service component shall adopt the description of the standard or standard candidate so that the existing component can be used as it is.
(3) Since it is difficult to uniformly define the vocabulary definition of metadata, the difference in vocabulary is solved, and it can be used if it is an equivalent function (for example, both car and car can be used).

  Next, functions will be described. The function refers to an operation such as a method or an event that can be used via the interface by exposing the interface to the network using WSDL, UPnPdoc, or the like. An equivalent function service component is a service component that operates in the same manner even if the URL and interface are different (for example, the URLs of the printers of manufacturer A of 5F and manufacturer B of 6F are Although different, the operation is the same).

  Based on the above three conditions, OWL-S (Web Ontology Language for Services: http://www.daml.org/services) of the SemanticWeb Services technology that has been advanced in recent years for service component description is used. OWL-S consists of three descriptions. The Profile description describes what service is provided, and the Process description describes the input / output, conditions, and effects of the abstract process of how it operates. Describe and Grounding description describes the abstract process of how to access and the mapping of the actual operation.

  Next, the reason for using OWL-S will be described. First, the process mapped to the actual operation is neutral with respect to UPnP, WS, etc., and the user uses the process as metadata of the actual operation, so that the service component is not conscious of detailed implementation of the service component. Can describe scenarios. Next, OWL-S is listed as a standard candidate, and in the future, services described in OWL-S are expected to be ubiquitous in the network. Also solve vocabulary differences. It is highly compatible with a method (service component selection method described later) in which metadata relations are described in OWL and the link is traced to solve the relationship.

  For this reason, the service component publishes information described in OWL-S to the network, and correspondingly, the service scenario is described as follows. In the service scenario, the function of the service component to be used is specified by the category name (unit in which the equivalent service component function is categorized) and the operation metadata, and information passing between the specified categories and control logic are also described. . Here, the operation metadata corresponds to the OWL-S process and its parameters. In the information transfer between categories, a mapping of the parameters of the previous category into which parameters of another category is described. The control logic is logic for controlling the service flow such as operation call, branching, repetition, event reception, parallel processing, etc., and these are the same as the control logic such as BPEL and PD4J.

  The present embodiment is characterized in that service components are specified abstractly and can be selected according to the user situation, and the conventional technology may be used for the control logic of the service components. For example, in BPEL, control tags such as “invoke” for operation call, “switch” for branch, and “while” for repeat are prepared, and a BPEL document is described using XML. A service scenario can also be described in a control tag language such as XML as in BPEL.

<Configuration of service cooperation engine>
Next, FIG. 4 is a block diagram illustrating a configuration of the service cooperation engine according to the present embodiment. The service cooperation engine 1 includes a service scenario setting unit 1-1, a service component group detection unit 1-2, a service component selection unit 1-3, and a service component execution / cooperation unit 1-4. The service scenario setting unit 1-1 sets a service scenario from the user terminal 7 or a service scenario specified by the user terminal 7 and detected from the service scenario DB 5. The service component group detection unit 1-2 searches and detects an available equivalent service component group by searching the service component information DB 2 using the service component metadata described in the service scenario.

  The service component selection unit 1-3 selects a service component corresponding to the user situation stored in the user context policy DB 3 from the service component group detected by the service component group detection unit 1-2. The service component execution / linkage unit 1-4 executes and links the selected service component according to the control logic described in the service scenario.

<Operation by service cooperation engine>
Next, a flow when the user uses the service will be described. Here, FIG. 5 is a conceptual diagram for explaining the operation of the service cooperation engine. When the user uses the service, the user terminal 7 is used to input and set the service scenario of the service to be used for the service cooperation engine 1 that cooperates the service (S1). In setting a service scenario, a service scenario described by itself may be transmitted to the service cooperation engine 1 according to a service scenario setting method described later, or a service scenario detected from the service scenario DB 5 may be specified. At this time, the user terminal 7 also transmits a user identifier to the service cooperation engine 1.

  When a service scenario is set in the service scenario setting unit 1-1, the service cooperation engine 1 can use the service component metadata described in the service scenario by the service component group detection unit 1-2. A service component group is searched and detected (S2). When detecting, by searching the service component information DB 2 using the metadata of the service component described in the service scenario as a key, a service component matching the metadata can be detected.

<Detection of service components>
When detecting a service component group, the service cooperation engine 1 detects an available service component group from the service component information DB 2 using metadata described in the service scenario as a key. The metadata includes category information that indicates what category the service component is, an atomic process that indicates what operation the service component is, and the effects, assumptions, and input parameters of the atomic process. Data, output parameter metadata, etc. are included. When a service component group is detected, if the metadata vocabulary is different (for example, one person is defined as the car category but another person is defined as the car category), the equivalent function Even the service component group of cannot be detected. In this case, more flexible detection is possible by cooperating with the ontology DB 4, and details will be described later.

  The service component information DB 2 returns the URL information of the detected service component group OWL-S to the service cooperation engine 1, so that the service cooperation engine 1 uses the URL and the service component group metadata OWL- S can be acquired. The OWL-S may be stored in the service component providing terminal 6 or may be stored in the service component information DB2.

<Ontology solution>
As described above, when metadata defined by different vocabulary is set even with the equivalent function (for example, car and car), the vocabulary conversion is performed by tracing the relationship between the metadata stored in the ontology DB4. By doing so, it can be detected as an equivalent function. Vocabulary conversion can increase the number of alternative candidate service components and ensure detection flexibility.

Here, the ontology DB 4 will be described.
Metadata management must be easy for all service scenario writers, service component creators, and users to use. Therefore, the following three are required.

(1) A service scenario writer can immediately detect and select operation metadata necessary for a service scenario to be described.
(2) When the service component creator creates a new function, it is possible to add new operation metadata. It is also possible to register the relationship between metadata of different vocabularies.
(3) When searching for a service component based on a service scenario, the user can search for all service components having the same function as the desired function.

To realize these, we propose an ontology management method characterized by the following three features.
(1) The operation metadata group is categorized and managed for each purpose.
(2) A new category with new functions can be registered. Can describe relationships between categories defined in different vocabularies.
(3) Bidirectionally link metadata relationships (equivalent values, inheritance relationships) between categories.

  FIG. 6 is a conceptual diagram for explaining an ontology management method. Here, an operation metadata group categorized for each purpose is called a category (eg, video, travel reservation category, etc.). In FIG. 6, rectangles indicate categories, small letters (a1, a2, b1, b2,..., H3, i3, j4) indicate operation metadata belonging to the categories, and arrows indicate the relationship of metadata.

  For example, some operation metadata is defined in category A, but the service component creator who created a new function creates a category C, adds new operation metadata, and establishes an inheritance relationship with an existing category. Describe. By repeating this, a category tree is formed. Not only the inheritance relationship of categories, but also the equivalence relationship of metadata of different vocabularies can be described (categories C and K). The service scenario creator describes the service scenario with reference to the metadata registered in the ontology DB 4. Further, when the composition engine searches for a service component, if metadata C3 is described as a function required for the service scenario in FIG. 6, the link is followed, and C, E, F having c3 or c3 ′ are followed. , K are searched for service components mapped to the category.

  As described above, by enabling the service component creator to add metadata, it is not necessary to perform the work of completely sharing the interface for each industry and for each purpose. The root category must be created by someone first, but it is published on the Internet site (for example, travelXML http://www.xmlconsortium.org/wg/TravelXML/TravelXML_index.html) Alternatively, a common minimum metadata set may be used. Since service component creators add new functions, it is expected that categories that are easy to use for users will be widespread by natural selection.

  In this embodiment, the OWL-S process is used for the operation metadata, and the equivalence relation and inheritance relation of the metadata are described using the OWL equivalentClass and subClassOf properties, and the OWL file in which these are described is stored in the ontology DB4. The shape to be. As an operation method, it is assumed that the administrator of the ontology DB 4 confirms the registration of the equivalence, inheritance, new registration, and the like after registration is confirmed by the administrator of the ontology DB 4.

  As described above, since the metadata of the equivalent function is known by following the OWL link, the number of service components that can be used can be further increased by searching the service component information DB 2 using the metadata.

  Furthermore, as described in the ontology solution described above, when searching for the service component information DB 2, the metadata vocabulary is different by using the equivalence relation and the inheritance relation of the metadata managed by the ontology DB 4. (E.g., car and car) can detect a service component group of equivalent metadata. When a service component group is detected, OWL-S, which is a metadata description of the service component, is acquired from the service component providing terminal 6 or the service component information DB 2 (the service component information DB 2 By returning the URL of -S to the service cooperation engine 1, the service cooperation engine 1 can detect the URL of OWL-S and acquire OWL-S).

  Next, as shown in FIG. 5, the service cooperation engine 1 selects an appropriate service component from the detected service component group by the service component selection unit 1-3 (S3). When selecting, an appropriate service component is selected by matching user context information, user policy information, and profile information of the detected service component in accordance with a service component selection method described later. User context information and user policy information are acquired from the user context policy DB 3 by the service cooperation engine 1 based on the identifier of the user to be used. Further, the profile information of the service component is a part of OWL-S information. If there is no other candidate and there is no need to select it, the service component selection process need not be performed.

<Service component selection method>
Here, the service component selection method described above will be described.
By using the ontology DB 4 and the grounding description, it is possible to flexibly detect service components having equivalent functions, convert them into actual interfaces, and execute them. Here, selecting an appropriate service component from the detected service component group will be described.

  In order to realize a service according to a situation, it is necessary to select a service component appropriate for the user situation from a group of available service components. User policy information on what service components should be given priority in order to select an appropriate service component, user context information on what kind of situation the user is in, and service components on what nature the service component has By matching the three sets of profile information, points can be assigned to service components, and high-scoring service components can be selected automatically, or by selecting them manually with reference to the points, it is possible to select appropriate service components. is there.

  Each of the user policy, the user context, and the service component Profile is represented by a combination of several data. Taking the location as an example, the location of the user is part of the user context, the location of the service component is part of the service component profile, and the desire to prioritize the near service component is part of the user policy. In addition, for example, the user's money is part of the user context, the service component usage fee is part of the service component profile, and the desire to prioritize the cheap service component is part of the user policy.

Here, FIG. 7 is a conceptual diagram for explaining the scoring method described above.
First, the user policy will be described. The user policy is a superposition of several evaluation criteria, and there are evaluation criteria common to all components such as low price and evaluation criteria according to the category type such as closeness of distance. The user can set his own policies such as closeness and cheapness by setting weights for each evaluation criterion.

  The user context is a set of data indicating the user situation such as a position, and is stored in the user context policy DB 3 as a user context file. There are various context collection functions such as a GPS (Global Positioning System) and a temperature sensor, but these implementations are outside the scope of the present invention. In the present embodiment, it is assumed that a context file in which information collected from them and information input by the user are aggregated is stored in the user context policy DB 3.

  The service component Profile is described as a parameter of the OWL-S Profile, and describes the service component properties such as the position of the service component and the price.

Each evaluation criterion is set with a scoring function, and a score is assigned by matching the profile of the service component with the user context for each evaluation criterion. For example, in the case of the “proximity” evaluation criterion that is the proximity of the position, exp (− (user latitude−service component latitude) ² − (user longitude−service component longitude) ² using the user position and the service component position ² ) Is used. Alternatively, it may be a simple method in which the score is increased in ascending order.

  The score of each evaluation standard is overlaid according to the weight, and the total score of the service component is calculated. In this way, the user can set the policy in detail, thereby scoring the service component according to the situation, and automatically selecting the service component or manually selecting the service component with reference to the score. Note that it is also possible to prepare a default policy for users who do not want to make detailed policy settings. In addition, when there is little information to select, such as when there is no profile information of the service component, it may be selected randomly or manually by the user.

  As described above, after all the service components used in the service scenario are selected, the service cooperation engine 1 is described in the service scenario by the service component execution / cooperation unit 1-4 as shown in FIG. Based on the control logic described in the service scenario, it is converted to the actual interface (WSDL, UPnP, etc.) of the service component using the metadata and the OWL-S Grounding description of the selected service component. A cooperative service is realized by executing and linking the service components described in (4).

<Service component execution method>
FIG. 8 is a conceptual diagram showing a conversion process from a process to an actual interface. The service cooperation engine 1 performs service execution and cooperation according to the control logic described in the service scenario. As described above, control logic includes operation invocation, parameter copying, branching, and repetition. However, the interpretation of the control logic is the same as that of BPEL and the like, so it may be interpreted based on the service scenario control tag. . However, when an operation of a service component is called, the service scenario is described by metadata, so it needs to be converted into an actual interface of the service component and called.

  Since the process information, which is the operation metadata of the service component, and the actual interface (WSDL, UPnP, etc.) of the service component are mapped according to the OWL-S Grounding description, the service cooperation engine 1 selects the service component. When calling, a coordinated service is realized by performing conversion that matches the actual interface from the metadata via the Grounding description. This conversion is the same for not only an operation call but also an event reception.

<Service scenario setting method>
As described above, by setting a service scenario in the service cooperation engine 1, the user can use various services according to the situation. When a user sets a service scenario, various methods can be taken. First, there is a method in which the user white body describes a service scenario and sets the described service scenario in the local service cooperation engine. Next, there is a method in which the described service scenario is transmitted to the service cooperation engine 1 via the network 8 so that the service cooperation engine 1 is set and executed. Further, it is possible to search for a service scenario to be used from the service scenario DB 5 on the network 8 without having to describe the service scenario by itself.

  When searching for a service scenario from the service scenario DB 5, the service scenario is searched using search keys such as a service scenario name, a service scenario creator name, a service scenario identifier, a service scenario genre, and a service scenario description. The service scenario retrieved from the service scenario DB 5 may be transmitted to the service cooperation engine 1 to be set and executed. In the service cooperation engine 1, only the service scenario identifier is specified, and the identifier is received from the service cooperation engine 1. It can also be used to acquire and execute a service scenario.

  Up to this point, the method of specifying service components using metadata in the service scenario has been described. In the service scenario, a plurality of service components are used, but some or all of the service components to be used can be specified by actual interface information instead of metadata.

  In BPEL, it was described that all service components are specified by interface information described in WSDL. Even in a service scenario, when specifying a service component, it is possible to strictly describe an operation to be used by directly specifying WSDL, UPnP, or the like. For example, a service component that requires high reliability, such as a credit settlement service component, can be described strictly by WSDL direct specification, and a monitor, a rental car reservation service component, etc. can be specified abstractly by metadata. is there.

  Further, when all service components are designated by the interface, the operation is the same as that of BPEL. For this reason, when all service components are specified by the interface, BPEL, PD4J, or the like can be used instead.

  In the above-described embodiment, when the interface information is specified, when the service component is detected, the interface information described in the service scenario is used instead of searching from the service component information DB 2 using the metadata. Search form. For example, in the case of WS, the interface information used for the search is a port type name, an operation name, an input message name, an output message name, and the like. A service component group in which these match is detected.

  Further, when selecting from the detected service component group, if the detected service component has OWL-S Profile information, it may be selected by scoring with the scoring method as described above. If there is no metadata such as Profile information, it may be selected randomly or manually by the user.

  In addition, when executing and linking the service component specified in the interface information, it is not necessary to convert the service scenario metadata to the actual interface. Therefore, the interface information described in the service scenario remains as it is according to the control logic. The service component may be executed and linked.

  According to the above-described embodiment, in order to solve the problem of BPEL, the service scenario is not described using the interface information of each service component, but what operation the service component uses. By providing an abstract description using the metadata information of possession, it is possible to provide an appropriate service according to the user situation by detecting and selecting a service component having an equivalent function, although the interface is different be able to.

  In the above-described embodiment, the functions of each unit of the service cooperation engine 1, that is, the service scenario setting unit 1-1, the service component group detection unit 1-2, the service component selection unit 1-3, and the service component execution / cooperation unit 1-4 is realized by executing a program stored in a storage unit (not shown). The storage unit is configured by a hard disk device, a magneto-optical disk device, a nonvolatile memory such as a flash memory, a volatile memory such as a RAM (Random Access Memory), or a combination thereof. Further, the storage unit is a fixed time such as a volatile memory (RAM) in a computer system serving as a server or a client when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. Includes those holding programs.

  The program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in the transmission medium. Here, the “transmission medium” for transmitting the program refers to a medium having a function of transmitting information such as a network such as the Internet or a communication line such as a telephone line. The program may be for realizing a part of the above-described processing. Furthermore, what can implement | achieve the process mentioned above in combination with the program already recorded, what is called a difference file (difference program) may be sufficient.

It is a block diagram which shows the structure of the service cooperation system by embodiment of this invention. It is an example of the description of a service scenario. It is a conceptual diagram for demonstrating a service scenario. It is a block diagram which shows the structure of a service cooperation engine. It is a conceptual diagram for demonstrating a service cooperation flow. It is a conceptual diagram for demonstrating an ontology management method. It is a conceptual diagram for demonstrating the scoring method. It is a conceptual diagram which shows the conversion process from a process to an actual interface.

Explanation of symbols

1 Service linkage engine 2 Service component information DB
3 User Context Policy DB
4 Ontology DB
5 Service scenario DB
6 Service Component Providing Terminal 7 User Terminal 8 Network 1-1 Service Scenario Setting Unit 1-2 Service Component Group Detection Unit 1-3 Service Component Selection Unit 1-4 Service Component Execution / Cooperation Unit

Claims (10)

There is a service linkage method that links service components based on a specified service scenario.
A first storage step for storing a plurality of service components;
A second storage step for storing a user context indicating a service user status;
A service scenario setting step for setting a service scenario in which metadata information representing service component interface information or service component operation is described;
A service component group detection step of detecting a service component group to be used from among the plurality of service components based on interface information or metadata information described in the set service scenario;
A service component selection step of selecting a service component corresponding to the user context from the detected service component group;
A service component execution / cooperation step of executing and linking the selected service component. A third storage step of storing an equivalence relationship or inheritance relationship between the metadata of the service components;
2. The service cooperation method according to claim 1, wherein the service component group detection step detects a service component group to be used based on an equivalence relationship or an inheritance relationship between the metadata. From the detected service component group, user context information indicating a service user status, user policy information which is information indicating what kind of service component the service user prioritizes, and meta data indicating the nature of the service component A scoring step of scoring based on the degree of matching with the data information;
2. The service cooperation method according to claim 1, wherein the service component selection step selects a service component having a higher attached score.   The service component execution / cooperation step represents mapping between metadata information described in the service scenario and metadata information representing an operation of the selected service component and interface information of the service component. The service cooperation method according to claim 1, wherein the service information is converted into an actual interface of the service component using the mapping information, and the selected service component is executed and linked. The interface information includes at least operation information, input message information, and output message information.
2. The service cooperation method according to claim 1, wherein the service component group detection step detects an available service component group based on interface information including the operation information, input message information, and output message information. Further comprising a presenting step of presenting the detected service component group for selection by a service user;
6. The service cooperation method according to claim 5, wherein the service component selection step selects a service component selected by a service user as a service component to be executed and linked.   6. The service cooperation method according to claim 5, wherein the service component selection step randomly selects a service component to be executed and linked from the detected service component group.   The service component execution / collaboration step includes executing and linking a selected service component based on the interface information when the service component is specified by interface information in a service scenario. Item 6. The service cooperation method according to Item 5. The service scenario is
Entered directly over the network, or
The service scenario to be used is acquired and input from a plurality of service scenarios stored in advance, or
2. The service cooperation method according to claim 1, wherein identification information of a service scenario to be used is designated from among a plurality of service scenarios stored in advance.   The service cooperation according to any one of claims 1 to 9, wherein the detection of the service component group in the service component group search step is performed at the time of service execution based on a control tag included in the service scenario. Method.

Images