JP5650877B2 - Apparatus and method for providing a plurality of computing function sources - Google Patents

Description

  The present invention relates to dynamically configuring and executing complex tasks in real time based on a semantically described application, device and service rich computing environment.

  Personal computing may be referred to as a paradigm in which a user operates / accesses a single device and accesses applications resident on that device. Personal computing provides sufficient knowledge about the user's computer environment and the applications available on the user's computer so that knowledgeable users can properly utilize the resources available to perform complex tasks. Requires that the user has. This is the computing environment that most users experience every day; it is the user's duty to learn how to accomplish complex tasks, and that user is responsible for each and every application running on the user's equipment. Understand each function supported by the device, manually transfer data between applications (eg, cut and paste), manually launch each application or specific function associated with the task, and finally Requires all attention (and devoted time) to performing that complex task.

The shift from personal computing to more task-oriented computing environments would be as follows:
For example, as an example of an operating system, when a user inserts a music CD into a CD tray, a window is popped up that suggests to the user a task that can be performed from that point on. A list of these typical options is:
Playing an audio CD Copying music from a CD Opening a folder to view a file This may include taking no action.

  Each of these options also refers to the application used to perform that action. The concern is about the action or task to be performed, not the application used to perform the task.

  However, the current operating system uses a predetermined list of actions or tasks related to a particular event (eg, inserting a music CD, connecting a digital camera, etc.) and when that event occurs And a list of related actions is shown to the user at runtime. In this sense, the response of the system is hardwired and does not provide more flexibility than what is programmed into the system for possible events to be executed as a result of the triggering event. In other words, the system shows the same set of actions that can be performed when the digital camera is connected to the computer (a specific action list prepared by the operating system programmer for that particular event). Applications can change items in the list, but there is no easy way for end users to change them.

In another example of an operating system, the user is presented with a choice of actions depending on the file type. That is, a separate list of tasks is presented to the user for each of the file types, such as document, image, photo album, music, music artist, music album and video. For example, if the file type is image, a list of “image tasks” is displayed:
View (show) as a slideshow
Request online printing Print image Set image as background Copy image to CD.

  This list of tasks is again pre-combined and associated with a particular file type. There is no easy way for end users to modify this list.

In another example of software suitable for office work, smart tag characteristics (functions) are available. The smart tag feature highlights text in the current document using an editor and presents the user with a drop-down menu of actions that can be performed along with the object that the text (character) indicates. For example, if the text represents a name, this function determines the object associated with the person name and presents the following list of possible actions:
Send mail (to that person) Plan a meeting (with the person) Open the contact (for the person) Generate a contact (for the person).

  Options are enabled by checking that the string in the document may represent a name. The system relies on the syntax attribute (grammar) of the text to confirm that the particular text portion represents the name. However, strings that do not resemble common American names (eg, a lassage) may not be identified as names associated with a person. The reason is that the part of the system that confirms a part of the text as a name is just a very simple program (script) that simply tries to confirm a distinguishable pattern in the syntax format of the text. Because. When the “nature” of the text is verified (appropriately or inappropriately), such as a person, address, etc., a list of pre-compiled possible actions is presented to the user. Application programmers can create smart tags for other documents and applications, such as verifying addresses and launching map applications.

  Another example that attempts to present to the user from a more task-oriented perspective regarding the computing environment is described below. When a user types an address into the search engine search box, the service returns a link to a mapping function (beyond normal search results) and provides a map of addresses accordingly.

  However, it is not obvious that the user may be looking for a map of typed addresses. There is another reasonable possibility: if the user may want a list of phone numbers associated with the address, or if the address is a company, the user will have a better business guide (BETTER BUSINESS BUREAU) may want to see the record, or may be trying to check the weather in the vicinity, and so on. In this current form, the search engine infers the type of "thing" (address in the current example) that the typed text represents, and is related in a hardwired manner associated with that type of entry. Returns the task.

  Thus, from a task-oriented point of view of a computer environment, the concern is a task, which is executable and not with respect to the application used to perform the task. Furthermore, the user does not need to know which application is used for the task. When the user chooses to perform one of the suggested tasks, the appropriate application is started and called (started) accordingly.

  However, the above-described computing example exhibits similar properties that do not allow real-time, dynamic, executable complex tasks such as: In one approach, the type or nature of the user's input (text or event) is inferred; in effect, the system tries to determine the semantics of the string against its syntax attributes. The system estimates the plausible task that the user wishes to perform under that input; however, the estimate is inherent to the system (hardwired), so in practice, the system is real-time The system programmer only makes assumptions about the system at programming time before the user interacts with the system. The appropriate application (whenever the user selects in the second step) is automatically invoked at the user's selection, instantiated with its appropriate input (whenever the system estimates in the first step), and static causality (Or a mechanism that responds to an opportunity).

While the above computing examples may increase user convenience, conventional systems still have the following personal computing properties:
The functionality is designed into the application; the programmer of the application programs (fixedly) the response of the system. As a result, this is not a flexible and scalable approach. This is because the range of possibilities is determined at the time of design.

  This system is a limited approach to responding to user actions and wishes and cannot accurately "perceive" the nature (semantics or meaning) of the input. Despite the various techniques used in each of the above examples, the system relies on accurately guessing the meaning of the input through grammatical characteristics.

  Conventional personal computing systems use a causal (or trigger response) mechanism, meaning that a given type of input becomes a single action (launch of an application).

  Also, personal computing—ie, the concept that a user owns and operates a computer that executes a user's application and “retains” the user's data—provides an approach to a computing environment with unclear boundaries. When a computer is permanently connected to a computer network, the distinction between local and remote applications, data corruption, even worse, confuses computer users. In addition, the user can access and interact with the device, which is not a computer in the sense of a personal computer, but still has significant computing power and contributes to the user's purpose and performs various tasks. Help achieve (eg, cameras, printers, smart devices, etc.). As an example, the available resources (devices and equipment) may change constantly, but the average user may even realize what is feasible or feasible in such a computing environment. It may not be. In other words, it is impossible for the personal computer method to make settings full of devices and applications that are not known in advance by the user.

  Therefore, it is desirable to dynamically discover, publish, configure, manage and execute tasks in real time in a computer environment, and this approach is a challenge for users performing tasks in a computing environment. Requires a fundamentally different approach.

  One form of the present invention described herein dynamically discovers complex tasks in real time based on a semantically described application, device and service rich computing (computer system) environment. , Publish, configure, manage and execute. According to one aspect, a method, apparatus, and associated computer-readable medium dynamically manages a complex user's task of two or more services in real time, the service comprising a sequence or sequence of events and actions. A plurality of service workflows are required, and the workflow is difficult to easily perform with static or pre-designed causal programming used in conventional personal computing systems.

  According to another aspect of the present invention described herein, a user can rely on a real-time, flexible, and integrated task user interface that is realistic, effective, efficient, dynamic, and flexible. (Its interface discovers, publishes, configures, services and / or manages and executes tasks), and manages and interfaces with the general-purpose computing environment. According to another form, accomplishing a complex task (managing a set of services) on the one hand gives the user an understanding of the task and on the other hand an understanding of the available resources (devices and applications). Rely on and allow the user to configure them into workflows (the workflows that the user executes, the final outcome of which is a complete task).

  This application is filed with US Provisional Application No. 60 / 714,952 under 35 USC119 entitled “TASK COMPUTING” filed with the US Patent and Trademark Office by Rueske Matsuoka, Yannis Loverow, XX Anson and Sunley on September 8, 2005 Human management number 1634.1020P) and enjoy its benefits, the contents of which are incorporated herein by reference.

  This application is related to, and is related to, US Application No. 11 / 115,403, entitled “TASK COMPUTING”, filed with the United States Patent and Trademark Office by Janis Loverow, Ryuske Matsuoka and Zexanthon on April 27, 2005. Is also incorporated into the reference of the present application.

  This application is related to continuation application 10 / 733,328 of US application entitled “TASK COMPUTING” filed with the US Patent and Trademark Office by Ryuske Matsuoka, Yannis Loverow, XX Anson and Sunley on December 12, 2003, The contents thereof are also incorporated in the reference of the present application.

  The invention, as well as other aspects and advantages described below, will become more apparent from the detailed structure and operation, and will be described with reference to the drawings that form a part of the description. Like numbers in the figures indicate like parts.

  FIG. 1A is a system diagram illustrating the task computing architecture of a task computing environment (TCE) 100 according to one embodiment of the invention. In FIG. 1A, a computer-implemented method includes dividing a pervasive task computing system environment 100 into a plurality of task computing computer system execution tiers, the steps of which include presentation processing. Layer 104, remote processor call mechanism application program interface (API) 106, middleware (server) processing layer 108 interfaced to presentation layer 104 by remote processor call API 106, Networked, as a service 112 of the computer 100, for the source function 116 of the computer system described in It is not no, or as both (a computer system 110), (dynamically) dynamically in real-time task interface 130 that is implemented by a computer (e.g.,) to generate the presentation layer 104.

  According to one embodiment, the functional source implementation layer 114 is a computing source (eg, device or software 114) related to functionality, and may represent or indicate, for example, a service function 115 for a user. The service layer 112 has a Semantic Service Description (SSD) 116 associated with the service function 115 to semantically describe the service function 115. Thus, the SSD 116 represents or describes the service function 115 semantically. Thus, the term “service” 112 refers to the association of the SSD 116 with the service function 115. In other words, the SSD 116 represents “service”. More specifically, the term “service” 112 relates to functionality from the domain of the functional source implementation layer 114 of content readable by computer devices, computer applications / software, electronic services, and computer (or machine). Relevant to calculation examples. More specifically, the service layer 112 and the function source realization layer 114 prepare a computer system source in which the semantics of the function 116 are described as the computer service 112, and the middleware processing layer 108 is real-time in the computer system. It interfaces to executable tasks that are dynamically configured, and the tasks consist of one or more services 112 that follow the task interface generated in the presentation layer 104 for one or more services 112 in the computer system 110.

  Task computing 100 dynamically discovers, publishes, configures, manages, and executes complex tasks in real time in an application, device, electronic service, and content rich computer network environment 114 (i.e., tasks in the implementation layer 114). A new paradigm to execute. Task computing 100 is based on semantic description of service functions 115a-n of computing devices 114a-n (eg, via semantic service descriptions (SSDs) 116a-n), and by end users according to their semantics. It can be configured into tasks that can be performed on the fly. Thus, according to the embodiments described herein, the task computing 100 system has a multi-layer computer system architecture of three or more programmed computing and computer readable information layers, and the architecture Includes a presentation client processing layer 104, a middleware server processing layer 108 (eg, semantic instance, semantic service description 116), and multiple services in multiple computer system layers. The term “task” 126 relates to the configuration of one or more actions according to the discovered computer system service 112 that the user wishes to perform, for example. According to the embodiments described herein, “tasks” 126 are automatically driven by the user, or any combination thereof is configured and managed via a task interface 130 implemented on a computer. For a user, task 126 as a configuration of one or more services 112 is managed at presentation layer 104 (eg, discovered, published, configured, executed, etc.). As a configuration example of a non-limiting service, “view the weather information 112 at the work address 112 of the My Contact 112 with the projector 112” is “view with the projector”, “weather information”, “work address”, and “My Address”. It is composed of four services 112 of “contact”. In other words, a “task” consists of a combination of one or more services 112.

  The term “composition” refers to (but is not limited to) the semantic input and output of service 112, such as, for example, the data object type for input (consumption) / output (generation) of service 112. In other words, it is related to forming a plurality of services 112 together according to the prepared functional characteristics of the service 112 described semantically. The example functional characteristics of the service can be the influence and preconditions of the service 112 to determine service buildability. Specific examples of the impact and preconditions of service 112 can be the input and output data object types of service 112.

  The terms “semantic instance” or “semantic object” relate to a group of descriptions for an item based on one or more ontologies. Semantic service description (SSD) 116 describes service functions 115 based on one or more service function ontology.

  The term “publish” relates to making a Semantic Service Description (SSD) 116 available through one or more service discovery means.

  The term “semantic service description” 116 according to one embodiment relates to an intermediary for notifying service function 115 parameters from the service function 115 itself to an application (eg, task computing system (TCS) 118). To do.

  The term “discover” relates to the discovery of the semantic service description 116.

  Task computing specifies the type of computer system 110, which discovers and publishes "tasks" 126, either automatically or user-driven, or both in real time (in any appropriate combination) and dynamically. The tasks comprise one or more services 112 based on a semantically described 116 application, device and service rich computer computing (computer system) environment 110.

Semantic Task Execution Editor R (STEER) (software for discovering and configuring semantically described services 116 executable tasks) and General Purpose Provision Environment (PIPE) (Semantic Instance Examples of two task computing clients related to (and / or software for publishing and managing semantic services 116) are described in related US patent application Ser. No. 10 / 733,328, the entire contents of which are hereby incorporated by reference. Incorporated into the reference. The embodiments described herein are semantic in addition to technologies used in real time and / or improvements in the technology, dynamic configuration of the semantically described services 116 into executable tasks. In connection with the management (eg, discovery, generation / publication, operation, etc.) of the described service 116, in FIG. 1A, according to the embodiments described herein, one or more task computing systems (TCS) 118a-n are Prepared according to client-server computer system architecture based on remote procedure call mechanism. The TCS 118 is logical and is segmented into the presentation processing layer 104 at run time to provide a client type programmed processor as a task computing client 119a-n, and the middleware processing layer 108 is a server type programmed process. The segmented presentation and middleware processing layers 104, 108 can be used to enable any remote processor call such as a web service (WS) such as a task computing environment web service application programming interface (TCE-WSAPI) 106a-n. Interface according to the mechanism. The concept of web services is well known. Thus, in the embodiment described herein, the TCS 118 generally includes a task computing client (TCC) that prepares a client-type process at the presentation layer 104 and middleware via a remote processor call API such as a web service (WS). With a TCC119 interface for the server processing layer, where TCC119 is referred to as WSTCC199. As a specific example of the remote procedure call mechanism, the TCS 118 that uses the web service is referred to as the WSTCS 118. Any application including third party applications (eg, Microsoft Word, Excel, Outlook, Adobe Acrobat, etc.), remote procedure call mechanisms such as web services (remote procedure calls such as web service calls can be created ( Or a remote procedure call function can be incorporated)) to become a task computing client (TCC) 119. Although the embodiments described herein utilize web services as a specific example of a remote procedure call mechanism, the present invention is not limited to such a configuration, and any remote procedure call mechanism may be used.

  Therefore, when the web service is used as a specific example of the remote procedure call API, the semantic task execution editor web service task computing system (STEER-WS TCS) 118a is an example of the WSTCS 118, and the middleware server via the STEER-WSAPI12- It has a STEER-WS task computing client (STEER-WSTCC) 119a in the presentation processing layer 104 that interfaces with the processing layer.

  Pervasive Instance Provision Environment Web Service Task Computing System (PIPE-WSTCS) 118b is another example of WSTCS 118. The PIPE-WSAPI 122 reveals a middleware server management tool 124 that typically manages the SSDs 116 and / or semantic object instances used in the task computing 100 in addition to managing the tasks 126 (eg, creating / Used to publish, remove, manipulate, etc.) The application client 119 using the PIPE-WS 122 is referred to herein as a semantically described service control mechanism (SDSCM) 119b, a specific example of which is “White Hole” 119b- 1. “Service Manager” 119b-2, “Real World Object Semantizer” 119b-3, and “Database Semantizer 119b-4”, which are also related to US Application Nos. 10 / 733,328 and 11 / 115,403. Explained. For example, at the presentation processing layer 104 (which interfaces with the middleware server processing layer 108 via the PIPE-WSAPI 122), such as “white hole” task computing (white hole) 119b-1, the WSTCS 118b is the PIPE-WS122. And has a web service task computing client (application client) or SDSCM 119b.

  Web service task computing client (WSTCC) 119, such as (but not limited to) STEER-WSTCC 119a, white hole 119b-1, "service manager" 119b-2, "real world object semanticizer" 119b-3 and Utilizing the database semanticizer 119b-4 as a programmable computing element (eg, task computing client software) at the presentation layer 104 allows the TCE-WSAPI 106 to be used by any one or more of the computing environments. Based on the semantically described service 116 made available by the middleware server process 108 via, the user manages the task 126 (eg, discovery Published configuration can perform the operation) to.

  In FIG. 1A, in accordance with today's computing environment, the user is surrounded by functions related to the realization layer 114, which functions on an electronic service (e-service) available on the Internet, a computer device operated by the user. A device such as an application, content available on a computer readable medium, or a computer mediated service, or just a device that supports a particular function. Specific examples of such devices, applications, e-services and content include (but are not limited to) telephones, computer displays, cameras, entertainment devices / content, televisions, personal digital assistants (PDAs), wireless communication devices (eg, Mobile phones, etc.), audio players, facsimile machines, printers, weather forecast services, map services, office computer software (eg, email applications, address books, etc.), multimedia computer readable media (eg, music compact discs) Movie digital video discs (DVDs), Internet sites, databases, etc.

  In FIG. 1A, the functions or service functions 115a-n provided by the realization layer 114 may include, for example (but not limited to) listening to music (eg, for entertainment devices), downloading songs, streaming video. Includes viewing, listening to the radio, providing contact information, checking addresses on the map, etc. Traditionally, the realization layer 114 was designed to provide functionality to the user by interacting (and / or operating) with each device or service; for example, in the room the user is visiting If you want to call a colleague on the phone that is being used and the colleague's phone number is stored in the user's laptop's electronic address book application, the user is launching the laptop application and is in trouble You have to find the phone number and manually dial the phone number on that phone. In other words, the user cannot configure task 126. Even when applications, e-services, and devices are physically communicable with each other, i.e., there is a communication link between them, the designer of the implementation layer 114 can generate computer system function sources (e.g., computer devices). Unless the application is designed in consideration of the task, the application or the like cannot exchange data in a meaningful way for the user's task. When facing an excess of function sources 114a-n, the user cannot perform a task that takes advantage of the functions in all those sources unless the function sources 114a-n are designed for that task. In addition, indifferent users are often unaware of what such tasks are possible.

  In FIG. 1A, according to the embodiments described herein, service layer 112 includes service function 115a from function source implementation layer 114 and a computer system (including networked, non-networked parts, or both). The service 112 includes a semantic service description 116 a that semantically describes the service function 115 a of the function source implementation layer 114. According to the embodiments described herein, the relationship between service functions 115 and SSDs 116 can be many-to-many (n: m) for a particular function source 114. For example, in one SSD 116 and a plurality of service functions 115, the configuration of the service function 115 (along with the plurality of service functions 115 in the configuration) is stored as the SSD 116. In the case of one service function 115 and multiple SSDs 116, the meaning of multiple types or types of a single service function 115 is provided. For example, in the case of a book search service function 115 (a service that returns authors, prices, photos, etc. for ISBN input), the function can be based on the semantic service 116, where one person returns the author's contact information; The SSD 116 performs an operation such as returning an image. More specifically, according to example embodiments described herein, service layer 112 provides available computer system 110 services 112 (including networked, non-networked parts, or both). As well as forming, there is a service function 115a-n that is available to the semantic service description (SSD) 116a-n and implementation layer 114a-n corresponding to the service function 115a-n. The SSD 116 reveals the computer network service function 115 of the implementation layer 114. Certain embodiments of SSD 116 are also described in related US patent application Ser. Nos. 10 / 733,328 and 11 / 115,403, the entire contents of which are incorporated herein by reference.

  Accordingly, the task computing 100 does not emphasize the specific implementation method for accomplishing the task, but rather the service functions 115a-n (eg, the computer device 114) and the user of the implementation layer function sources 114a-n that emphasize the task 126. Is a new paradigm on how to interact, and task 126 is the task that the user wishes to accomplish while utilizing the computer device 114. Task computing 100 bridges the gap between what the user wants to do and service functions 115 of computing device 114 (available in that environment). Task computing 100 offers significant advantages over traditional approaches such as the current personal computing paradigm, is more suitable for non-expert computer users, saves time for all types of users, and is a general-purpose computer-type computing computer. It is particularly suitable for realizing a wing environment.

  In FIG. 1A, therefore, according to the embodiments described herein, individual modularization is provided to provide a flexible computer system architecture (software and / or programmable computing hardware) for expansion and construction. A middleware server processing layer 108 is created, and the functionality of that layer is made available to the presentation processing layer 104 via a remote procedure call application programming interface (API); application developers and users can use them to perform tasks Computing functions (eg, service 112 discovery and configuration to executable tasks 126, including construction, storage, execution, release, management, etc. of services 112 and / or tasks 126). ) To access. Remote procedure call mechanisms, such as web services, provide programming language independence, platform and location (ie, different processing layers on different computers) required for end user application development.

  As described above, the ubiquitous pervasive network computer computing environment is filled with numerous devices and other functions (e-services, applications, content) 114, 115 that are often temporary in nature; Or even a developer creating an application in a ubiquitous environment, what functions (resources) 114 and corresponding service functions 115 are available at a given time and more importantly what they are available to. You may not know in advance if there is. In order to take this dynamism into account, the service functions 114 and 115 need to be discovered and combined at run time rather than at design time. Thus, the embodiment described herein uses semantic web technology as an example because, if the computer network resources 114, 115 were themselves well described by machine-readable semantics 116, some infrastructure. The structure 100 can be built, the infrastructure fully understands the resources 114, 115, such as the computer system service 110, and what the resources 114, 115 provide for the application developer to do in general and This is because it is possible for the end user to use the developer's own knowledge such as what it can use. The concept of the Semantic Web is well known.

More specifically, according to the embodiments described herein, task computing 100 utilizes well-known concepts of the Semantic Web and Web services. However, to implement an actual functional system in a truly dynamic ad hoc ubiquitous computing environment, the following is set up and executed in the task computing 100 described herein:
(1) As shown in FIG. 1, a task interface for the computer system source 110 relating to functions is prepared. The task interface 130 includes (1) the presentation processing layer 104 having a task computing client (TCC) 119, (2) the middleware server processing layer 108 (the TCC 119 in the presentation layer 104 is a task computing environment (TCE) web service API 106). A task computing system (TCS) 118 that is logically segmented (to interface with a remote procedure call mechanism API 106 such as STEER-WSAPI 120 and PIPE-WSAPI 122). The API 106 reveals the middleware server processing layer 108 interfaced by the presentation processing layer 104. The task interface 130 also has a semantic service description (SSD) 116 that semantically describes the service function 115. The SSD 116 is discovered by the middleware processing layer 109 indicated by the presentation layer 104 via the TCC 119, and the service function 115 is performed, for example, via the TCC 119, for example, according to a prepared control command as part of the task 126 to be executed. It is executed by the middleware processing layer 108 based on the SSD 116 of the service function 115 executed in the presentation layer 104.

  (2) The semantic service description (SSD) 116 and the service means 115 are separated so as to provide the service layer 112 together.

  (3) The concept of a “sphere” as a subset of the remote procedure call API that is accessible on the remote task computing client 119 and operates on the computer 110 to achieve a range of searches for the service 112 The search mechanism (in some cases, for a service or stored task), the search scope, and the operational functions of the service are separated within and between those scopes.

  (4) The ability of users (and applications) to dynamically create and operate services is available (users have the ability) and can be shared with others (or shared as needed). (In other words, service control management is performed.)

  (5) Prepare various services 112 that enable the execution of interesting and truly useful tasks 126.

  Thus, as shown in FIG. 1A, the above-described layer separation is relevant to both logical and realization, and is useful for building task computing 100, in which users perform complex tasks. The task was not designed (implicitly or explicitly) in a computer network system, thus the user's source functions 114, 115 (devices, applications, content and e-services) Increase. The present invention is not limited to the Semantic Web, but other semantic types of technologies and frameworks (which allow data to be shared and reused across application, enterprise and collective boundaries) are here. It can be used in the described embodiment.

  In FIG. 1A, the function source realization layer 114 is shown as the lowest layer, covering areas such as computer devices, computer applications / software, electronic services and computer (or machine or both) readable content, to the user. All available functions occur. The service function 115 (described in more detail below) of the function source 114 is an example of an operation related to functionality. Such service functions 115 typically originate from at least three different types of sources 114 (device, application (software) and over-the-web e-service). These three sources 114 are not strictly hand, but loosely defined and do not limit categories. Because the boundary between them is very flexible. As an example, the device 114 issuing the service 115 is a core (core) function that the device 114 is designed to provide. For example, the main function of the telephone (device) 114 is to make a telephone call (service) 115. Similarly, an application (software) 114 that issues a function is a service function 115 of the software 114 executed by the computer device 114. For example, the functionality of a Personal Information Management (PIM) application includes storing and retrieving person contact information. Finally, the e-service and / or content 114 service function 115 is a service function 115 that operates on some remote server that provides the service function 115 via a web service, for example, across a user's local network boundary. Content such as the fourth source function 114 is very useful and that content is made available as a service function 115; this type of service function 115 is very useful as a means of sharing information between users. . Accordingly, "service" 112 is here related to functional examples of functions from the functional source realization layer 114 of computer devices, computer applications / software, electronic services and computer (or machine or both) readable content fields. . Accordingly, the “service” 112 as an example of the operation of the function from the function source realization layer 114 has an interface characteristic for interacting with the “service” 112, which is a description of the “service” including the service name, the function to be executed, and the like. , And service functional characteristics such as input / output to “service” 112. Further, according to the embodiments described herein, the user interface used on the computer for the computer system service 110 follows an ontology based on the semantically described output and input data of the “service” 112. For example, service 112 described in semantic service description 116 for displaying a file on a display projector is named “display on projector”, accepts “file” as input, and has no output parameters.

  In FIG. 1A, the service layer 112 is the source 114 of a function that has been made available for operation as a service function 115 via a semantic service description (SSD) 116. The SSD allows service functions 115 to be discovered and accessed. Each service function 115 is associated with at least one semantic service description (SSD) 116, for example encoded according to OWL-S, which is a web service ontology language based on the web ontology language (OWL) and is a resource description framework. Using the (RDF) / Extensible Markup Language (XML) exchange syntax, the SSD 116 is running via PIPE-WSTCS 118b so that the service 115 is dynamically created (as made available) (On the fly). The SSD example described is not limited to the OWL-S example, and any computer-interpretable language structure that describes the characteristics and functions of the computer system service function 115, including web services, can be used. The SSD 116 has three parts: profile, process and grounding, which part of the profile allows the user to actually activate the service 115. Services 115 represent the functions available in the task computing area 100, and the SSDs 116 of these services 115 hide the user from the complexity associated with the sources of the service functions 115 and perform complex tasks of interest. These service functions are to be made easier for users to use. Examples of semantically described services 116 are also described in related US patent application Ser. Nos. 10 / 733,328 and 11 / 115,403, the entire contents of which are incorporated herein by reference.

  In FIG. 1A, the middleware server processing layer component 108 is responsible for discovering the services 115, 116 (or 112), determining how the services 115, 116 can be configured into tasks that can be performed, Execute services, monitor services performed, and enable and support various management operations (including creation and publication of semantically described services 116). In other words, the purpose of the middleware server processing layer component 108 is to abstract all service resources 115 as semantically described services 116, which can be used by applications that seek to manipulate them or It can be made available to the user (eg, at the presentation layer 104 via TCC 199).

  In FIG. 1A, the presentation processing layer 104 utilizes the functions of the middleware processing layer 108 to combine all available service functions 116, 115 (112) to allow the user to perform tasks. Various programmable computing clients (e.g., software) using web services 118a-n called WSTCC, WS application and / or WS web-based interface application (accessible with a web browser) (all here called WSTCC) Hardware client, programmable computing hardware client, or the like), which performs the task by combining all service functions 112 available through the middleware processing layer 108. According to the embodiments described herein, the middleware layer component 108 is revealed via a clear web service application programming interface (WSAPI) 106, thereby enabling WS task computing clients (which use these APIs 106 ( WSTCC) 119 can be generated.

  It is enumerated to define a task computing environment web service API 106 with a middleware processing layer 108 that provides unlimited access to the core functions of task computing such as discovery, configuration, execution, storage, generation and management of services 112 Open all functions. For example, the WSTCS 119 is not tied to any particular implementation of task computing as long as the user can invoke the web service 106, and the user can work on any platform to create the WSTCC 119 and access the service 112. Any programming language can be used to do this.

In FIG. 1A, therefore, a task computing environment web service (TCE-WS) API 106 is provided according to the embodiments described herein. A subset of TCE-WSAPI 106 can be used for a variety of task computing purposes, when used with STEER-WSTCS 118a and when used with STEER-WSAPI 120 and one or more PIPE-WSTCS 118b. Is referred to as PIPE-WSAPI 122 and Sphere of Management (SoM) -WSAPI 123 when used to prepare a “Sphere” for cross-environmental task computing. Examples of the invention are described below:
Examples of various web service task computing clients (WSTCC) 119a, such as the Semantic Task Execution Editor Web Service (STEER-WSTCCC) 119a, are described in detail and are semantically described services based on STEER-WSAPI 120 Software that discovers 116 and configures it into executable tasks. The STEER-WSTCC 119a, such as the presentation layer 104 component 108 of the WSTCS 118, provides user interfaces implemented on various computers. Related US patent application Ser. Nos. 10 / 733,328 and 11 / 115,403 are computer display graphical user interfaces related to the STEER-WS extension (XT) TCC119a-1, a computer display implemented on a wireless device such as a mobile phone A graphical user interface is described, and they are called the mobile phone STEER-WSTCC119a-2, STEER-WS spatial information system (SIS) TCC119a-3, voice STEER-WSTCC119a-4 and tasklet-WSTCC119a-5. A tasklet WSTCC 119a-5 according to one embodiment of the present invention is described below.

User interface-STEER-WS-XT TCC119a-1:
FIG. 1B is a graphical user interface image displayed on a computer as a task interface implemented by a computer according to STEER-WS-XTTCC119a-1 in the presentation layer according to an embodiment of the present invention. In FIG. 1B, the computer display graphical user interface window 142 is a discovered service 112 window (or discovery plane), which is displayed according to the icon tree structure of the discovered service 112. According to the embodiments described herein, the service 112 may be any type of service based on ontology and / or other characteristics such as (but not limited to) nicknames, service types, alphabetical order, etc. Organized within the discovery service window according to the category hierarchy. The computer display graphical user interface window 144 is a task window 144 (or task 126 structure plane), which is a service graph intended to accommodate the non-linear service structure of the service 112 for multiple inputs / outputs. In FIG. 1B, task window 144 displays a task 126 that includes, but is not limited to, five services 112. In particular, the task 126 is “display the route 112 from the My contact 112 to the home address 122 and the business address 122 on the My projector 112”.

  In accordance with the embodiment described herein in FIG. 1B, SSD 116 window 150 displays SSD 116 parameters / characteristics for service 112 selected in service window 122. The SSD window 135 can be used when the task 126 is inspected as a part of the task 126, for example.

  In FIG. 1B, task window 144 provides a selectable graphical representation of service 112 that was selected in discovery service window 142. In the task window 144, when a discovered service 112 is selected, a compatible service that automatically follows the service's functional characteristics based on the ontology is automatically identified, and the graphical display of the service 112 is also automatically displayed with one or more selectable functional characteristics. Buttons 145a-n, which represent available or active (compatible) services 112 for the selected discovered service. Selecting the functional property button displays a selectable list of other discovered services 112 that can utilize the results of the preceding service 112, as indicated by the displayed line connecting the graphical display of the service 112. Configuring the above service 112 creates a task 126. More specifically, in the task window 142, the user configures a graph of the service 112 designated as the task 126. When using the input / output data object type of service 112 as a functional characteristic of service 112, output functional characteristic button 145a is distinguished from input functional characteristic button 147 by coloring or by some known method of distinguishing computer displays. The

Referring to FIGS. 1A and 1B, the task computing system 100 has an architecture that discovers services available in the current environment and tasks from a user-centric perspective of available services. Provides the basis for constructing and processing the resulting tasks composed of multiple services. If necessary, even end users can create new services dynamically and easily. The three characteristics / elements (1), (2), (3) of the task computing system 100 are as follows:
(1) Uniform abstraction of all functions 114 and 115 as the service 112. As described herein, in task computing 100, the middleware server processing layer 108 functions to abstract all resources as a semantically described service 112. Semanticly described services include (but are not limited to) remote procedure calls such as WSDL (Web Services Description Language), UPnP (Universal Plug and Play), CORBA, RMI, RPC, DCE, DCOM service functions 115. A service function 115 that can be used via the service specification, and a semantic description (file) 116 in a language (for example, OWL-S) for describing a service is designated. When such a semantic description 116 is specified, the specified ontology is instantiated for the area in which the services 116 and 115 (112) operate. With respect to ontology, software tools can be used to create an ontology and whenever a possible existing or available ontology is available. The OWL-S service description 116 represents the functional characteristics of the service function 115, which means, for example, input and output as semantic objects and with respect to the service 112 with owner, creator, location, etc. The description includes basic information that allows the actual WSDL and / or UPnP service to be properly performed. Semanticizer tools (such as, but not limited to, real world object semanticizer 119b-4, database semanticizer 119b-5, internal service instance creator, etc., described and / or mentioned herein) in preparing these descriptions Is used to map ontology objects to WSDL parameters and create any necessary basic information (the basic information (grounding) is expressed via an XSLT script). A web service interface 106 is provided for the middleware server processing layer 108 based on which an intuitive task 126 user interface at the presentation client processing layer 104 is provided.

  Task computing middleware can also be viewed as a dynamic repository of semantic service descriptions. Apart from the API 106 for accessing and manipulating these descriptions described here, means are provided for querying the repository directory by executing the API, and the API can use any RDF query language (RDQL) for service descriptions. ) Query is also processed (JENA 2.0 is used as an example for processing RDQL queries). For example, a developer can select a service presented to the user for task composition due to some property of the service, such as location, even if no explicit API for that purpose is provided. This capability extends the power of application developers and makes certain queries more useful, so they may be permanently added to the middleware as APIs 106 (perform pre-selected RDQL queries). According to one embodiment, based on the relevance between the discovered service for the user and the user's content by examining the semantic description of the service in the SSD, based on the discovery means that discovered the SSD, or each Based on the service compatibility according to the SSD determined by the functional characteristics of the service or any combination thereof, the discovered SSD becomes a dynamically screened and discovered service.

  The abstraction of functionality as a service 112 makes the functionality generally accessible and allows the task computing infrastructure to interact with such functionality. The task computing system 100 converts the e-service functions 114, 115 of the user's computer device (depending on the application and OS), the devices in the environment and available on the Internet into an abstracted service 112. While this abstraction paves the way for reducing the prior readiness to handle the functions available in the environment, by itself, to give the user the ability to configure real-time operational capabilities and functions into tasks 126. Not enough, the embodiments described herein provide a presentation layer 104 and support real-time, dynamic task management (tasks with multiple services).

  (2) To provide intuitive operability of the service 112 abstracted based on the semantic service description (SSD) 116 (to the user and / or the system). Intuitive operability of the service 112 is made possible through the use of a Semantic Service Description (SSD) 116; ontology is a mechanism for achieving such intuitive operation of the user and / or system. The concept of SSD 116 is also described in related US patent application Ser. Nos. 10 / 733,328 and / or 11 / 115,403, the entire contents of which are incorporated herein by reference.

  For example, instead of SSD 116, if only WSDL (Web Services Description Language) function source 115 is used to describe the functional characteristics of a web service, a WSDL-based web service allows programmers to define their meaning (WSDL description). There is a need to develop code to understand (and more than content) and use the service appropriately. As a result, end-user interaction with functionality is limited to those program categories that are predetermined by the developer. Additional semantics (supplied by SSD 116) by mapping ontology objects to source function 115 parameters (eg, parameters such as, but not limited to, WSDL parameters) and creating any necessary basic information are: The task computing 100 infrastructure allows users to assist in operating their services without detailed knowledge. For example, semantics can be used to constrain the user's operation of the service, or to prohibit the user from possible tasks 126 in the environment. If only WSDL relies on a service configuration based on the service's semantic inputs and outputs, that configuration is not constrained to any configuration of the service, eg, a CML schema definition (XSD) along with another using an XSD string. ) Generate a string and derive a possibly non-executable (invalid) service configuration. Thus, according to the embodiment used herein, “composition” means (but is not limited to) the semantics of a service 112 of a data object type, eg for input (consumption) / output (generation) of the service 112. It relates to being formed by putting together a plurality of services 112 according to the provided functional characteristics of the service 112 as described semantically, such as typical input and output. A specific example of the functional characteristics of a service may be service preconditions and effects for determining a service configuration. Specific examples of preconditions and impacts of service 112 may be input and output data object types for service 112. In particular, the SSD 116 of the service 112 provides fine-grained service inputs and outputs, for example, a service that generates an “address” semantic object may only be configurable with a semantically compatible service.

  Another mechanism for the intuitive operation of the service 112 by the user is by giving an appropriate service name according to a natural language such as a service name such as “Route from My Home”, and a compatible service configuration. The service name may function as a natural language task 126 expression (for example, “view with projector” 112+ “my file”, 112 “route from company 1” 112 “city name airport” 112). Ontologies can support mechanisms such as construction based on subclass-super-class relationships and semantic object transformations that are very natural for the end user. Therefore, the configuration of the task 126 is based on a natural language sentence, or in other words, the configured task 126 can be read like a natural language sentence. More specifically, the embodiments described herein provide a service for assigning a name to a service, such as an element (eg, a phrase) of a prenatal language sequence, and associating it with a configuration of a natural language element, such as a natural language sentence. Support the buildability of Thus, the task computing system 100 enables a very rich and interesting way for end users to interact with the services of the environment 110.

  (3) The user performs real-time and / or dynamic (later combined form) configuration of task 126 via a computer-implemented user interface, eg, based on (1) and (2) as shown in FIG. 1B be able to.

Web Service Application Program Interface (TCE-WSAPI) 106:
FIG. 2 shows an example of a definition list of STEER-WSAPI 120 according to an embodiment of the present invention. In FIGS. 1A and 1B, STEER-WSTCC 119a is WSTCC 119, which provides a convenient user interface for discovering, screening, configuring and executing services 112 and saving services 112 as tasks 126. STEER-WSAPI 120 is TCE-WSAPI 106 that extracts task computing functions from independent modules and clarifies them as a standard web service interface accessible by some WSTCC 199, such as STEER-WSTCC 119a.

  As shown in FIG. 2, by clarifying the functionality of the task computing middleware server processing layer 108 by the web service 106, the WSTCC 119 in the presentation processing layer 104 enables the module of the task computing middleware server processing layer 108. It is possible to release from the realization means. The WSTCS 119 developer can use any programming language on any operating system as long as no web service 106 is called, resulting in WSTCC 119. Even a third party application (Microsoft Word, Excel, Outlook, Adobe Acrobat, etc.) capable of making web service calls (or incorporating web service call functionality) may be a potential WSTCC 119.

  In FIG. 2, functions such as discovery, configuration, execution, monitoring, saving, and the like are supported by the STEER-WSAPI 120. In general, TCE-WSAPI 106, such as STEER-WSAPI 120 and PIPE-WSAPI 122, relies on service 112 identifier (SID) parameters, which are specific to a service function 115 described semantically described in SSD 116. It is something to identify. Typically, according to the embodiment described herein, the SID is a uniform resource locator (URL) string to the semantically described service 115 described in SSD 116. For example, FIG. 3A shows an example of computer source code 300 that utilizes STEER-WSAPI 120 to synchronize with local information about discovered services 112. FIG. 3B shows another example computer source code 310 that uses the STEER-WSAPI 120 to invoke a task 126 with multiple services 112. As a non-limiting example, in FIG. 3B, the service list parameter is an input string that distinguishes multiple tasks using, for example, “&” and distinguishes service 112 identifiers within the task using “|” WSTTCC 199 can have the program loop of FIG. 3B in its code to launch and monitor task execution. Accordingly, in the present invention, the source code as shown in FIGS. 3A-3B is an implementation example of the WSTCC 119 such as the STEER-WSTCC 119a by activating the remote procedure of the middleware server processing layer 108 using the TCEWSAPI 106.

  FIG. 4 is a functional block diagram of the middleware processing layer 108 program module of STEER-WSTCC 119a according to an embodiment of the present invention. As shown in FIGS. 1 and 4, the middleware processing layer 108 of the STEER-WS-TCC 119a has a central module 402, which follows the web service 106 request via the STEER-WSAPI 120 from the presentation processing layer 104. , Control the discovery module 404, execution module 406, and monitor module 408 of the service 112. The central module 402 includes a service 112 disassembly and index module 410 and a service 112 configuration and task 126 execution plan unit 412. Service 112 teardown and index module 410 registers interface 412 and allows discovery module 404 to register / unregister discovered services 112. The discovery module 404 includes individual discovery modules such as a local discovery module 414, a third party service function 115 discovery module 416 such as UPnP, a remote site discovery module 418, and a discovery module manager 420. Has a management function that determines whether each discovery module should be used in various environments 110.

  According to the embodiments described herein, a local service discovery unit 414, a third party service discovery unit 416, a remote site service discovery unit 418, a temporary service discovery unit 428, a native (unique) service discovery unit 426, or any of them. The service function 115 is discovered by discovering the associated SSD 116 according to a plurality of discovery means including one or more of the combinations. The local service discovery unit 414 opens the “socket” port, monitors the SSD 116 announcement message from an application started on the same device (computer), and the local service discovery module 414 is executed on the device. For example, when an application starts, the application publishes an SSD 116 and sends an SSD announcement message to a predetermined “socket” port opened by the local service discovery unit 414 for notification. According to the present embodiment, the SSD announcement message received by the local service discovery unit 414 from the application includes the location of the announced SSD 116. Then, the location service discovery module 414 creates an SSD 116 that can be used by the TCC 119.

  The third party discovery unit 416 discovers the SSD 116 using a third party discovery standard. Third party discovery mechanism 416 may be, for example, Universal Plug and Play (UPnP) technology, Gini technology, Bluetooth, etc., or any combination thereof. For example, Cyberlink UPnP and / or Intel UPnP toolkit means may be used in the Daidan discovery module 416 to discover service descriptions broadcast within a UPnP subnetwork. The remote site discovery unit 418 uses a web service protocol (web service call) for a remote web service to discover an SSD that can be identified by the web service interface.

  According to the embodiment described herein, JENA by the Hewlett-Packard development company is used to store the SSD 116. The decomposition and index module 410 has a decomposition and analysis function for decomposing and analyzing the SSD 116. For example, according to the embodiment described herein, the SSD 116 is disassembled with MINDLAB pellets (PELLET) and OWL-SAPI from the University of Maryland, USA using JENA from the Hewlett-Packard development company. In particular, “discovering the service 112” is equivalent to “discovering the SSD 116 that semantically represents the service function 115 of a certain function source 114 (eg, device, software 114)”. The SSD 116 can be discovered by any of the service discovery modules 404 and is sent to the central module 402 via the registration interface 422 and the SSD 116 is first analyzed by JENA, for example with pellet support. Once the SSD is analyzed, the pellet is ready to answer the RDQL query. The service configuration and task execution plan module 412 assumes the configuration of the service 112 as the task 126 by querying from the service analysis and indexing module 410 and based on the query result, and responds to the task 126 execution command from the TCC 199. An execution plan for task 126 is determined. Once the execution plan is determined, the central module 402 calls the associated service function 115 via the execution module 406, which executes the grounding invocation provided in the SSD 116 to call the service function 115. 424. The discovery module 404 discovers services that may include a service function 115 and a semantic service description (SSD) 116. The above description of the service 112 disassembly and index unit 410 is not limited to such a configuration, and any mechanism for disassembling and analyzing SSDs 116 other than JENA and pellets can be used.

  According to the embodiments described herein, WSTCC 119 is integrated as a separate module (eg, by implementing web service interface 106 for underlying Bluetooth SDP, IR, RENDEZVOUS, JINI, etc. 404, 406). Any type of service 112 discovery means 404 or execution means 406 can be used as long as the highly abstracted and highly abstracted discovery and execution means are executable according to the web service API 106. Thus, for example, the only thing a user needs to specify is a uniform resource locator (URL) of the Web Service Definition Language (WSDL) file for the STEER-WSAPI 120 for interfacing with the service layer 112. As long as the web service API 106 is provided, the entire discovery procedure underlying the TCE-WSAPI 106 is transparent to the user at the WSTCC 119 at the presentation layer 104. For example, one STEER-WSAPI 120 can utilize the Bluetooth discovery module 404 to discover and execute a Bluetooth-based service 112. Another STEER-WSAPI 120 can utilize the UPnP discovery module 404.

  According to one aspect, the following two service 112 discovery methods are described: (1) a native service discovery module 426; and (2) a temporary service discovery module 428. As described herein, the discovery of the service 112 becomes an effective discovery of the SSD 116 associated with the service function 115. The native service discovery module 426 is a one-time file-based discovery function. Some services 112 are frequently used and are desired to be available on a regular basis. For example, there is a service 112 that can be executed by a WSTCS 118 (STEER-WSTCS 118a) based on an “ON” web service 115 (eg, an Amazon web service) or without grounding. According to one form, for an “always on” web service 115, the availability of the web service is not related to the execution state of the task computing system 118. In many cases, a third party vendor may provide such an “always on” web service 115. For these “always on” web services, the associated service description 116 may be fixed. This is because information about the web service 115 (such as where the web service 115 is provided) is immutable. Thus, it is possible to create a “fixed” (meaning always constant) service description 116 for such an “always on” service 115. In such cases, costly dynamic service discovery means (eg, means by PIPE-WSTCS 118b as described in related US patent application Ser. Nos. 10 / 733,328 and 11 / 115,403) are unnecessary. is there.

  Native service discovery module 426 is a one-time light weight discovery module for frequently used services 112 that include a fixed description. According to one embodiment, the native service discovery module 426 operates only once in the initial start phase of the WSTCS 118, such as the STEER-WSTCS 118a. For example, STEER-WSTCS 118a loads or installs all service description files 116 discovered as services 112 in a specified directory (eg, the default “My Documents \ My Services”), and locates these discovered services 112 as STEER. Register with WSTCS 118a (eg, discovered service 112 window (or discovery plane) 142—available in FIG. 1B). Thereafter, the native service discovery module 426 can be closed. Table 1 below provides a comparative overview of the native service discovery module 426 and the local service discovery module 414. Local service discovery 414 is based on “socket communication”. The local discovery module 414 opens and monitors a pre-formed socket. When a local service is published by an application, the application sends a message to a predetermined socket to be discovered by the local discovery module 414. This approach is considered dynamic and local to devices operating on TCC 119. This is because the TCC device provides a service through an application that operates on the TCC device. When the TCC IP (Internet Protocol) address changes, its service description must also change.

表１：ネイティブサービス発見モジュール４２６対ローカルサービス発見モジュール４１４

テンポラリサービス発見モジュール４２８はサービス１１２用に設計され、そのサービスは、STEER-WSTCS118aのようなＷＳＴＣＳ１１８の現在の実行セッションの中でのみ必要とされ、タスクパッケージ（後述）で使用されるそのようなサービス１１２は、ユーザがタスクパッケージのタスクレット(tasklet)と共に作業する場合にのみ必要とされる。一形態によれば、テンポラリサービス発見モジュール４２８は以下の２つのウェブサービスＡＰＩを用意する：
１．レジスタＡＰＩ（これは、入力としてサービス記述を使用し、登録が成功すればサービスＩＤを返す。）。

Table 1: Native Service Discovery Module 426 vs. Local Service Discovery Module 414

Temporary service discovery module 428 is designed for service 112, which is only needed during the current execution session of WSTCS 118, such as STEER-WSTCS 118a, and is used in task packages (described below). 112 is only needed if the user works with tasklet tasklets. According to one form, the temporary service discovery module 428 provides the following two web service APIs:
1. Register API (which uses a service description as input and returns a service ID if registration is successful).

  2. Unregistered API (this uses the service ID and returns nothing).

  The temporary service discovery module 428 allows a user to publish / unpublish the service 112 via a web service. However, the service 112 discovered through the temporary service discovery module 428 is only temporary during the current execution session of the WSTCS 118, such as STEER-WSTCS 118a. For example, when STEER-WSTCS 118a is restarted, these services 112 are no longer discovered. This is because information on the temporary service 112 is cleared.

  In FIG. 1A, PIPE-WSTCS 118b is another example of WSTCS 118 for publishing and managing semantic object instances. The PIPE-WSAPI 122 extracts the task computing management function 124 from the independent module, and “white hole” 119b-1, “service manager” 119b-2, “real world object semanticizer” 119b-3 and “database semanticizer” 119b. Reveal them as a standard web service interface 106 accessible by some WSTCS 119 such as -4. More specifically, the PIPE-WSAPI 122 provides a web service interface 106 to the PIPE-WSTCS 118b to manage services 112 such as publishing operating systems, application objects, device services, etc. PIPE-WSTCS 118b is also described, for example, in related US patent application Ser. Nos. 10 / 733,328 and 11 / 115,403.

Presentation Processing Layer 104 user interface:
The implementation of STEER-WSAPI 120 and PIPE-WSAPI 122 makes it possible to prepare a wide variety of task computing 100 user interfaces for WSTCC 199. This is because the presentation processing layer 104 of the WSTCC 199 can be released from the module implementation means of the task computing middleware processing layer 108. An example of the user interface 104 of WSTCS 119 is described herein with respect to tasklet WSTCC 199a-5.

Tasklet WSTCC119a-5:
The tasklet TCC 199a-5 is a task computing client (TCC) 119 with very light processing, and executes a service OWL-S file or configures a service (task 126). Of the techniques for creating a tasklet TCC to execute an OWL-S file included in the command line, the preferred technique is to double-click the OWL-S file to be executed (or any other appropriate method) To call tasklet TCC). When the tasklet TCC reads the OWL-S file, the service or service configuration is executed by using the STEER-WSAPI 120. The tasklet TCC shows the control UI of the service function 115 in its own window. In particular, referring to FIG. 2, the tasklet TCC 119a-5 calls the “Execute OWLS” API 120 to execute the OWL-S description. The tasklet TCC119a-5 uses the service grounding that stores the OWL-S “process model” and the task 126, and prepares a “process model” tasklet. According to one embodiment, a service workflow (and tasklet plus service workflow) and a task package are provided.

FIG. 5A shows a task package file structure according to an embodiment of the present invention. According to one aspect, the “task package” 500 includes a service workflow tasklet (SW-tasklet) 502 that includes service workflow information. The SW-tasklet 502 service workflow information and task package 500 improves the ability and portability to edit the SSD 116 (service 112) of the configured task 126 included in the SW-tasklet 502. The term “SW-tasklet” relates to a semantically described task 126 (a computer interpretable semantic description composed of two or more services 112). For example, if tasklet TCC 119a-5 is based on OWL-S and is an OWL-S file and the user can use the “process model” tasklet to store, publish, execute and share task 126, task 126 Once created, the service 116 (112) is not editable. This is because the task 126 is stored in accordance with the “process model” defined in the OWL-S standard. An OWL-S “process model” can be defined in many ways; for example, a “process model” is only about execution. Thus, according to one embodiment, SW-tasklet 502 is extended to include a “service workflow”. Here are three approaches to storing tasks 126 based on OWL-S:
The “process model” defined in OLW-S is the purpose of execution. Only individual service processes are included, and service workflows cannot be extracted beyond the process model.

  “SW-tasklet” is “process model” plus service workflow information. With the SW-tasklet, a service workflow can be extracted and the task 126 can be listed as a configuration of the service 112.

  However, if a service 112 is considered lost (eg, not found in the current environment), its execution and editing will fail. Thus, “task package” 500 is a description of all or all SSDs 116 of “SW-tasklet” 502 plus included service 112. With respect to task packages, even if certain services 112 are lost, WSTCS 118 can still look for them (eg, using temporary service discovery means) and is included in SW-tasklet 502 of task package 500. You can continue to edit or execute the current task.

  In particular, each OWL-S file can contain three parts: (1) a profile (which is a service name, a service description (a description from which a person can read the service description) and / or a semantic input / output. (2) Process (which determines information related to execution) and (3) Grounding (which maps execution information to the actual calling method). According to one form, each SSD 116 is an OWL-S file. Further, the SW-tasklet 502 describing the tasks 126 of two or more SSDs 116 is an OWL-S file file. SW-tasklet 502 as the semantic description of the configured task is based on the SSD of the configured task, and the execution plan as the SSD process model of the configured task description, and the service of all the configured SSDs A grounding is generated, and a service workflow of a task configured as a profile attribute of a task description configured as described later is extracted and added. Thus, in the OWL-S file that describes the task 126 or in the SW-tasklet 502, the process section or “process model” of the tasklet OWL-S file contains the execution plan, and for the SSD 116 during the configured task 126 Includes only the process section of the OWL-S file. Thus, once tasks 1126 are built, from there TCC 119 cannot know what services are included and what role they are in task 126. This is because service 112 may include multiple processes, or multiple services may share the same process. In any case, it is difficult to specify which service 112 the process belongs to from the “process model”. In other words, the “process model” does not reveal a one-to-one correspondence between services 112 and processes. Because the “profile” of the service 112 is not included in the “process model”, it is difficult for the TCC 119 to open the “process model” tasklet, which includes only the process model and the task window (or As shown in the service work flow chart for building the block of the service 122 shown in (task 126 configuration plane) 144, the user returns to the stage where the task 126 is initially constructed from the service 112.

  Therefore, according to one form, SW-tasklet 502 has a service workflow information concept, and TCC 119 can open SW-tasklet 502 and configure multiple tasks 112 via SSD 116 to configure the task. Return 126 to the stage where the user builds. In the tasklet service workflow, not only the related service 112 but also the relationship between services 112 (such as how the output of one service 112 is mapped to the input of another service 112) is defined. . From the tasklet service workflow, the TCC 119 can load tasklets / task packages and display the tasks that configure the service 112 (initial construction stage) within the task window (or task 126 configuration plane) 144. . The tasklet service workflow function provides the user with the ability to load an existing task 126 and see how that task 126 was built from the service 112. With respect to the same TCC 119, from task 126, the user can add / delete / edit service 112 and create a new task 126 via task interface 130 provided by TCC 119 (eg, FIG. 1B). This is referred to as task 126 “editability”.

  For example, service workflow information includes: (1) a number of services 116 (112) having tasks 126, (2) IDs of these services 112 (ie, SSD 116 IDs), and (3) services 112 form tasks 126. Including how it was linked for. By referring to the tasklet service workflow information, the TCC (task computing client) 119 can restore the original design content of the SW-tasklet 502 task 126 as a service workflow having the linked service 112. .

  FIGS. 6A-D show computer interpretable source code for SW-tasklet 502 according to one embodiment of the invention. In particular, FIGS. 6A-6D are OWL-S files for describing a task 126 of “Open My File”, which are “Open” 116a and “MyFile”. It is composed of two services 112 via the SSD 116 of 116b. 6A-6D, SW-tasklet 502 is a valid OWL-S task 126 description, and SW-tasklet 502 is executable. In FIG. 6B, the following line is the service workflow information 512 for the SW-tasklet 502 (Open My File.owls).

図６Ｂでは、サービスワークフロー５１２がサービスＩＤ５１６，５１８それぞれを介して２つのサービス「開く（オープン）」及び「マイファイル」の２つのサービスを特定する。更に、サービスワークフロー５１２は、「マイファイル」出力５２０及び「マイファイル」出力５２０に合致する「開く」５２２をサービス１２２（１１６）リンケージとして確認する。

In FIG. 6B, the service workflow 512 identifies two services, “Open (Open)” and “My File”, through the service IDs 516 and 518, respectively. Further, the service workflow 512 confirms the “My File” output 520 and the “Open” 522 that matches the “My File” output 520 as the service 122 (116) linkage.

  In FIGS. 6B-6C, process flow line 514 is part of the OWL-S standard and is required to perform task 126 as follows.

サービスワークフロー情報を利用して、タスク１２６の詳細を容易に共有することができる。しかしながらSW-タスクレット５０２の考えられる１つの欠点は、TCC１９９は示される構成サービス全てにその詳細を正確に表示することを要求することである。なぜなら、SW-タスクレット５０２サービスワークフロー情報はサービスIDのみを与え、サービス名、サービス記述、セマンティック入力／出力のような他の重要な情報をタスク１２６の個々のSSD１１６から検索することを当てにしているからである。サービスワークフロー情報と共にSW-タスクレット５０２は、コンパクトな手法でタスク１２６の詳細を共用することを可能にするが、サービスワークフロー情報を備えたSW-タスクレット５０２はタスク１２６を編集する能力及び移植性(portability)を制限するおそれがある。なぜなら何らかのサービス１１２が見失ったと思い（例えば、現在の環境で発見されなかったと思い）、実行も編集も失敗するかもしれないからである。従ってタスクレットサービスワークフロー情報を用意することに加えて、本実施例は「タスクパッケージ」を用意する。サービスワークフローに含まれるサービス１１２がその環境内で発見可能であった場合には、そのサービスワークフローは単体でそのタスク１２６を復元するのに充分である。

The details of the task 126 can be easily shared using the service workflow information. However, one possible drawback of SW-tasklet 502 is that TCC 199 requires all of the configuration services shown to accurately display their details. Because the SW-tasklet 502 service workflow information only gives the service ID and relies on retrieving other important information such as service name, service description, semantic input / output from the individual SSD 116 of the task 126. Because. SW-tasklet 502 with service workflow information allows sharing of task 126 details in a compact manner, while SW-tasklet 502 with service workflow information has the ability to edit task 126 and portability (portability) may be limited. This is because some service 112 may have been lost (eg, it was not found in the current environment), and execution and editing may fail. Therefore, in addition to preparing tasklet service workflow information, this embodiment prepares a “task package”. If the service 112 included in the service workflow can be found in the environment, the service workflow is sufficient to restore the task 126 by itself.

  In FIG. 5A, the “task package” 500 is a package file that includes three types of files: SW-tasklet 502, the associated service 504 overall SSD 116, and an index file 506. The index file 506 stores the correspondence (mapping) between the service ID (recorded in the tasklet workflow information) and the related service description 5-4. According to one aspect, for example, the package file 500 may follow a zip (ZIP) file format. FIG. 5B is a file list of a zip task package according to an embodiment of the present invention.

  In FIG. 5A, the task package 500 is a zip file that includes the following parts: “Services” subfolder (stores all the semantic descriptions 116 that make up the task 126 (eg, open 116a and my file 116b), SW-tasklet 502 (describes task 126 in OWL-S format together with workflow information) (open my file SW-tasklet 502) and index file (services.idx) 506 (service ID appearing in SW-tasklet 502 is “service”) Corresponding to SSD 116 of task 126 stored in a subfolder.) FIGS. 7A-C show example computer interpretable source code representing a semantic service description for an “open” service according to one embodiment of the present invention. FIG. FIG. 8 illustrates example computer-readable source code representing a semantic service description of a “MyFile” service according to one embodiment of the present invention, thus “Open” 116 a and “My File” 116 b shown in FIGS. Is in the “Services” subfolder of the task package 500.

  Therefore, the SSDs 116 of all the service functions 115 included in the task 126 composed of a plurality of service functions 115 are stored in the service subfolder of the task package 500. The SW-tasklet 502 also provides service workflow information 512. The index file “services.idx” 506 determines the correspondence between the service ID (used in the SW-tasklet 502) and the SSD file 116 (stored in the service subfolder).

  When the task package 500 is opened at TCC 119, a first SW-tasklet 502 such as STEER-WSTCS 119a is extracted. The TCC 119 checks whether all the services 112 required by the SW-tasklet 502 are available (ie, already discovered by the TCC 119). If the SW-tasklet 502 service 116 has already been discovered by the TCC 119, no action is taken. Otherwise, from index file 506, TCC 119 finds descriptions of all missing services 116 and publishes them via temporary service discovery module 428. The SW-tasklet 502 service 116 can be published through a discovery means other than the temporary service discovery module 428, but if the temporary service discovery module 428 is not used, the discovered task package 500 service 116 is currently It can survive past the task configuration session of the task package. Once all missing services 116 have been published and discovered by the TCC 119, the SW-tasklet 502 can resume loading the procedure by the TCC 119. According to one form, the TCC 119 opens the task packet file 500 and executes and / or edits the SW-tasklet 502 (eg, to display a configured task diagram for editing). Retrieves any missing or required SSD 116 of configured task 126 from the SSD of task package 500. The TCC 119 publishes the retrieved SSD 116 and makes the SSD 116 available to the TCC 119 by registering the SSD 116 via the temporary service discovery module 428. The TCC 119 calls the temporary service discovery unit 428 web service, submits the searched SSD 116 from the task package 500 to the temporary service discovery 428 web service, and the temporary service discovery unit 428 receives the input SSD 116 from the TCC 119 via the web service interface. accept. The temporary service discovery unit 428 web service registers the accepted SSD as the discovered service 116 (112) for authentication by the TCC 119. According to one embodiment, the temporary service discovery unit 428 analyzes the received SSD and creates a service instance 112 of the TCC 110. According to one embodiment, the service published by the temporary service discovery unit 428 can be used only by the TCC 119 that starts the temporary service discovery unit 428 in addition to the execution session of the TCC 119, for example.

  Thus, SW-tasklet 502 is an executable OWL-S description that defines an execution plan for task 126 based on the process of included service 112 in addition to the service workflow of included service 112. To do. The SW-tasklet 502 having service workflow information has a specific tag, and the tag represents the service workflow of the task 126 described by the SW-tasklet 502. Along with the tasklet service workflow information, the TCC 119 opens the SW-tasklet 502 and displays, for example, the included services 112 and their relationships in a user interface window 144. However, in the TCC119 environment, if one or more services 112 of the SW-tasklet 502 are deemed to be missing due to such services 112 not being found or registered with TCC119. The open procedure may fail due to missing information. Thus, task package 500 includes a description of all included services 112 (or SSD 116) and SW-tasklet 502. When the TCC 119 opens the task package 500, the user is given the option to load that service 112 from the attached semantic service description 116, even if one or more services 112 of the SW-tasklet 502 are missing. Once all the missing services 112 have been loaded, the complete task 126 is restored. In short, task package 500 is the most robust way to store task 126. Both tasklets and task packages with service workflows support “task editability”.

  According to one form, both SW-tasklet 502 and task package 500 can be created with TCC 119. For example, after a user creates a task 126 from a group of services 112, the user can have an option to save the task 126. While saving the task 126, the user can view the task 126 as an SW-tasklet 502 with a service workflow or a task package (tasklet with service workflow information-plus-individually included in the task 126. As a description of the service 112). Once the user makes that decision, the SW-tasklet / task package can be generated.

The procedure for generating a SW-tasklet can be as follows:
1. A task OWL-S is generated as a tasklet dedicated to the “process model”.

  2. The service workflow information of the task is extracted, and the extracted service workflow information is added to OWL-S as a profile attribute. According to one aspect, when the user creates a task in TCC 119 (eg, FIG. 1B for STEER-WSTCS 119a), service workflow information is extracted from the editor of STEER-WSTCS 119. According to one form, in FIG. 1B, the displayed structured task diagram is represented in a data structure, and an extraction procedure analyzes the user's task structure, including editing, from the task data structure and calculates a service workflow. For example, the number of services 116 (112) constituting the task 126 is confirmed, and which services are included in the task 126 is confirmed by, for example, the ID of these services 112 (ie, the ID of the SSD 116). , See which services 116 (112) are linked together to form task 126 (eg, service 1 output goes to service 2 input, etc.).

  3. The OWL-S is stored as the SW-tasklet 502 together with the service workflow for a certain file.

The task package procedure can be as follows:
1. Create SW-tasklet as determined in advance.

  2. Add a description of all the services 116 included.

  3. Create a correspondence (mapping) between the service id and the service description file name and store the mapping in the services.idx file. FIG. 9 shows an example task package index file 506 according to one embodiment of the invention.

  4). Zip the content.

  The task package 500 provides a significant improvement over the unmodified method, and the user manually zips the “process model” tasklet and related services and sends them to other users; The user needs to unzip the file, publish the missing service, and finally open the “process model” tasklet. The benefits of task packages are clear. Because during task package construction in TCC 119, the task package format automatically detects all of the services 112 that TCC 119 is associated with and packs those service descriptions 116 in the task package along with the SW-tasklet and the corresponding index file. It is because it is allowed to do. When a task package runs on TCC 119 or is opened, TCC 119 includes any missing services 112 and automatically determines task configuration services. In the above unimproved method, the receiving user needs to manually extract the missing services 112 and publish them manually.

  Here, an example task computing system is described by segmenting the task computing 100 environment into a plurality of computer system execution stages, which includes a presentation client processing layer, a remote procedure call application program interface (API), Middleware service processing layer (presentation layer interfaces in real time via remote procedure invocation API, computer execution task interface in presentation layer, to computer system source functions described semantically, in computer system Dynamically generated as a service); service layer and functional source realization layer (denoted semantically) Computer system source functions as a service in a computer system interfaced by a middleware processing layer; and an executable task dynamically configured in real time (presentation layer for one or more services in a computer system) (Consisting of one or more services). Computer services are dynamically configured into executable tasks in real-time, generated for services on the computer based on semantically described applications, devices and services-rich computers. Interface. According to the embodiments described herein, a user can apply a flexible, integrated user interface (configuration and execution functionality) in a practical, effective, efficient, dynamic, and real-time manner. Manage interactions and interact with general-purpose computer environments.

  The apparatus, method, computer readable medium (including its carrier signal) provides a plurality of computing function sources, each of which relates to a function, for example providing services to a user and / or computer, and a computer of the apparatus In the environment and in a computer environment in network communication with the device. The device associates a semantic service description (SSD) with the service. An SSD has a semantic description of a service, a semantic description of service parameters according to a computer interpretable language, and a correspondence between a computer interpretable language that expresses an SSD, such as service grounding, and an interface ( Service interface parameters). The apparatus dynamically discovers one or more SSDs as usable services through a plurality of discovery means for discovering SSDs, and services based on the semantic description in each SSD related to each service. Generate and configure a user interface for dynamically configuring tasks based on selecting services and selecting services to continuously screen possible tasks A semantic service workflow description that can be executed as a task description composed of tasks is generated.

  Executable semantic service workflow description generation is based on the SSD of the configured task, and an execution plan is generated as an SSD process model of the configured task description, and a service grounding list of all SSDs of the configured task is generated. And extracting and adding the service workflow of the configured task as a profile attribute in the description of the configured task.

  Task computing is an approach that uses (a) Semantic Web technology to make more (semantic) web resources quickly available to ubiquitous computing applications, and (b) It has nothing to do with the nature of the resource, it is an abstraction regardless of how the resource is discovered, how it is accessed, how it is connected or how it communicates The service 116 makes them available to the task computing system 100. Task computing relies on services 116 that are semantically described as a universal abstraction of all functions, and furthermore, configurable tasks 126 may include many services 112, so task computing Covers a greater range than device-to-service interoperability. For example, task 126 of a typical task computing 100 system can dynamically use 5-6 services 112 in real time.

  The above preferred embodiment of the present invention is a programmable computing device / controlling software / programmable device / computing device (as stored on any known computer readable medium). Hardware (eg, a programmable electronic device that can store, retrieve, present (eg, display) and process data) —may be implemented on any type of programmable computer device. Such computer devices include, but are not limited to, for example, personal computers, server and / or client computers in the case of a client-server network architecture, networked computers, terminal devices, personal digital assistants, mobile devices in a distributed network architecture Etc.

  Many features and advantages of the present invention will become apparent from the detailed description, and thus, the appended claims shall cover all such features and advantages within the true spirit and scope of the present invention. Is intended. Further, since many modifications and variations will be apparent to practitioners skilled in this art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and thus all suitable modifications and variations are within the scope of the invention. is there.

1 is a system diagram illustrating the architecture of a task computing environment according to one embodiment of the invention. FIG. FIG. 3 is a diagram illustrating a graphical user interface image displayed on a computer as a task interface in a computer-implemented presentation layer according to an embodiment of the present invention. It is a figure which shows the example of a definition list of STEER-WSAPI by one Example of this invention. It is a figure which shows the computer source code using STEER-WSAPI by one Example of this invention. It is a figure which shows the computer source code using STEER-WSAPI by one Example of this invention. FIG. 4 shows a functional block diagram of a middleware processing layer 108 program module according to one embodiment of the present invention. It is a figure which shows the task package file structure by one Example of this invention. FIG. 6 is a diagram showing a file list in a packaged task package according to an embodiment of the present invention. FIG. 4 is a diagram illustrating computer interpretable source code of a tasklet together with a service workflow according to an embodiment of the present invention. FIG. 4 is a diagram illustrating computer interpretable source code of a tasklet together with a service workflow according to an embodiment of the present invention. FIG. 4 is a diagram illustrating computer interpretable source code of a tasklet together with a service workflow according to an embodiment of the present invention. FIG. 4 is a diagram illustrating computer interpretable source code of a tasklet together with a service workflow according to an embodiment of the present invention. FIG. 4 illustrates computer interpretable source code representing a semantic service description for an “open” service according to one embodiment of the invention. FIG. 4 illustrates computer interpretable source code representing a semantic service description for an “open” service according to one embodiment of the invention. FIG. 4 illustrates computer interpretable source code representing a semantic service description for an “open” service according to one embodiment of the invention. FIG. 5 is a diagram illustrating an example of computer interpretable source code representing a semantic service description of a “MyFile” service according to one embodiment of the present invention. FIG. 5 is a diagram illustrating an example of computer interpretable source code representing a semantic service description of a “MyFile” service according to one embodiment of the present invention. FIG. 5 is a diagram illustrating an example of computer interpretable source code representing a semantic service description of a “MyFile” service according to one embodiment of the present invention. FIG. 6 is a diagram illustrating a task package index file according to an embodiment of the present invention.

Explanation of symbols

100 task computing environment 104 presentation processing layer 104
106 remote procedure call mechanism application program interface 108 middleware processing layer 110 computer system 112 service layer 114 function source realization layer 115 service function 116 semantic service description 126 task

Claims (17)

A device providing a plurality of computer function sources, each computer function source providing a service, in a computing environment of the device, in a computing environment in network communication with the device, or a combination thereof And the device has a controller for controlling the device according to a process, the process executed by the computer is:
According to a computer interpretable language, and semantic description of the parameters specifying the service function, as a service grounding to enable the activation of the service by the user, in a computer interpretable language to represent semantic service description (SSD) Associating an SSD with a service semantic description that includes the expressed SSD and the correspondence between the service interface including the interface parameters with the service;
A process of dynamically discovering one or more SSDs as available services via a plurality of discovery means to discover SSDs;
A process for dynamically selecting services based on the semantic description of each SSD associated with each service;
A process of generating a user interface for dynamically configuring tasks based on service selection and dynamic screening of services to continuously present executable tasks;
A process for generating an executable semantic service workflow description as a configured task description of the configured task;
Have
The process of generating the executable semantic service workflow description is:
Based on the SSD of the configured task, an execution plan is generated as an SSD process model of the description of the configured task, and a service grounding list of all the SSDs of the configured task is generated, and the service workflow of the configured task is generated. Including the process of extracting as a profile attribute of the configured task description and adding it to the executable service workflow description ,
The plurality of discovery means have a native service discovery unit as a one-time service discovery unit that discovers a regularly available service having a certain service description.
A device characterized by that. The apparatus according to claim 1, wherein the service workflow includes multiple SSDs in a task, the identity of the SSD in the task , link information describing the connectivity of the SSD in the task , or a combination thereof. The controller process further comprises generating a task package file having an executable semantic service workflow description of the configured task, an SSD and an index for the service of the configured task;
The apparatus according to claim 1, wherein the task package file is a cross-computing environment execution file. 4. The apparatus of claim 3, wherein the task package file follows a zip format. 4. The apparatus of claim 3, wherein the controller process further comprises a process of restoring a task configured with a user interface for editing, execution, or a combination of both according to the task package file. . The process of restoring the configured task is:
A temporary service discovery unit for the current task configuration including editing and execution, which accepts an associated SSD in a task package file via a web service interface and registers the received associated SSD as an available discovered service;
Native service discovery unit as a one-time service discovery unit that discovers regularly available services with a certain service description,
A service discovery unit local to the device that follows the socket announcement service message from the application,
A third party discovery department, or a combination thereof,
Having
A process of discovering a service of a configured task based on a plurality of discovery means for discovering the SSD associated with the service of the configured task;
A process of presenting, via a user interface, services included in the configured task based on profile attributes in the configured task description;
6. The apparatus of claim 5, comprising: Temporary service discovery for current task configuration including editing and execution, wherein the plurality of discovery means accepts an SSD associated with a service via a web service interface and registers the accepted SSD as an available discovered service The apparatus according to claim 1, further comprising: a section. Configured task description service grounding for the controller process to translate for each service between the semantically described parameters and service interface parameters of the service in the configured task description SSD process model The apparatus according to claim 1, further comprising: a process for executing a task by using and managing a sequence for executing a service through an SSD process model of a configured task description. The service in which the discovered SSD is discovered based on the association between the discovered service and the user and the user's situation by examining the semantic description of the SSD service and / or based on the discovery means that discovered the SSD The apparatus of claim 1, further comprising a process of dynamically sorting as: The apparatus of claim 9 , wherein the screening follows a resource description framework data query language (RDQL) query. The apparatus of claim 1, wherein the computer interpretable language for expressing the SSD is a web ontology language (OWL) based web service ontology (OWL-S) language. Each SSD determines the functional characteristics of each service according to an ontology,
The apparatus according to claim 1, wherein the services are selected according to the compatibility based on the SSD that determines the functional characteristics of each service. The association of an SSD with a service assigns a name to a service as an element of a natural language sentence, supports the possibility of constructing a service mapping to the constructability of a natural language element as a natural language sentence,
13. The apparatus of claim 12 , wherein generating a user interface includes supporting configuring a task of a service selected and screened based on a natural language service name according to a natural language sentence. The user interface is a computer display screen graphical user interface, the graphical user interface comprising:
In the first graphical user interface window, a selectable graphic display of the discovered SSD is displayed as an available service according to a tree structure;
Presenting a second graphical user interface window that supports dynamically configuring one or more services to tasks in real time according to a process, the process comprising:
Let the user select a discovered service in the first window,
Automatically displays a selectable graphical representation of other compatible services related to the selected discovered service,
Let users select compatible services,
Dynamically displaying in real time the service graph indicated in the second graphical user interface window according to the user selecting the discovered and compatible services as tasks;
14. The apparatus of claim 13 , wherein a selectable graphical display for task execution is displayed to execute the task. The apparatus of claim 14, wherein the displayed and discovered services are organized in a first graphical user interface window according to the functional characteristics of the discovered services. A method performed by a computer to provide a plurality of computer function sources, each computer function source providing a service, in a computing environment of the device, in a computing environment in network communication with the device, or Present in their combination, the method is
According to a computer interpretable language, and semantic description of the parameters specifying the service function, as a service grounding to enable the activation of the service by the user, in a computer interpretable language to represent semantic service description (SSD) Associating the service with an SSD having a semantic description of the service including the represented SSD and the correspondence between the service interface including the interface parameters;
Dynamically discovering one or more SSDs as available services via a plurality of discovery means to discover SSDs;
Dynamically screening services based on the semantic description of each SSD associated with each service;
Generating a user interface for dynamically configuring tasks based on service selection and dynamic selection of services to continuously present executable tasks;
Generating an executable semantic service workflow description for the configured task;
I have a,
Generating the executable semantic service workflow description comprises:
Based on the SSD of the configured task, an execution plan is generated as an SSD process model of the description of the configured task, and a service grounding list of all the SSDs of the configured task is generated, and the service workflow of the configured task is generated. Extracting as a profile attribute of the configured task description and adding it to the executable service workflow description ,
The plurality of discovery means have a native service discovery unit as a one-time service discovery unit that discovers a regularly available service having a certain service description.
A method characterized by that. A device providing a plurality of computer function sources, each computer function source providing a service, in a computing environment of the device, in a computing environment in network communication with the device, or a combination thereof Present in the device
According to a computer interpretable language, and semantic description of the parameters specifying the service function, as a service grounding to enable the activation of the service by the user, in a computer interpretable language to represent semantic service description (SSD) Means for associating the service with an SSD having a semantic description of the service including the represented SSD and the correspondence between the service interface including the interface parameters;
Means for dynamically discovering one or more SSDs as available services via a plurality of discovery means to discover SSDs;
Means for dynamically selecting services based on the semantic description of each SSD associated with each service;
Means for generating a user interface for dynamically configuring tasks based on selecting services and dynamically selecting services to continuously present possible tasks;
Means for generating an executable semantic service workflow description as a configured task description of the configured task;
I have a,
The means for generating the executable semantic service workflow description comprises:
Based on the SSD of the configured task, an execution plan is generated as an SSD process model of the description of the configured task, and a service grounding list of all the SSDs of the configured task is generated, and the service workflow of the configured task is generated. Means for extracting as a profile attribute of a configured task description and adding it to an executable service workflow description ,
The apparatus, wherein the plurality of discovery means include a native service discovery unit as a one-time service discovery unit that discovers a regularly available service having a fixed service description .

Images