Multi-Resource Orchestration in UBIWARE

ServiceURI is ?auri Although the abstract service includes input and output definitions, we still keep input and output patterns in the service description, because these descriptions may vary in detail level, however, they should obey class-subclass relationship. Such definition may seem redundant, D3.1: Multi-resource orchestration in UBIWARE © 2009 UBIWARE Deliverable D3.1 10 but we think that it may improve planning and avoid overheads in process execution. We discuss it further in this paper. Discovery and subscription Any agent can send search request to the ODF. Typical request may have following form: I want You answer { ?agent hasService { input is {pattern} output is {pattern} serviceURI is ?uri abstractServiceURI is ?auri serviceCategory is ?category ... } } As a search criterion, the requestor may use a URI of the abstract service description, or a category name. The category reference is a property of abstract service description and may be used in search cases, when input and output can not be properly specified. In such case, the search function is somewhat similar to the standard service discovery in UDDI. Categorization of services is a domain specific task therefore we leave it out of scope here. As a search result the ODF agent returns Ontonut services that match the search request. In terms of SOA, the ODF returns a list of endpoint entries (with service bindings). In case, when a search criterion defined as input and output patterns, the search procedure performs matchmaking. The search patterns provided are semantically matched against available abstract service descriptions and the descriptions, in turn, have service implementations (access points) bound to them. The semantic descriptions of services both abstract and real ones fall into the problem of pattern matching and completeness of the description. Well-known approaches in Semantic Web Service discovery like WSMO 4 suggest that abstract semantic service descriptions should be defined with low detail level to keep semantic reasoning and matching fast enough. The real world services are then bound to the abstract descriptions and the service consumption itself may be needed to clarify if the service fits the goal. Another option is to define in the design phase the annotations of services (bound service capabilities) as precisely as possible (all constants known before execution must be included into the description). Abstract capabilities in turn, should be defined in a way that makes it suitable for a process designer (human) to build business process logic. The attainability of the abstract process then can be checked against available bound capability descriptions. The reason for such detailed annotation is to avoid frequent null results in the runtime. In the planning phase, detailed description is used to detect the candidate process chains that will always result in null (empty set) because the dependable variables’ values may never match within the whole process chain, e.g. the sequence (1) A A ?a => B B ?a, (2) B B ?a => C C ?a 4 http://www.wsmo.org/ D3.1: Multi-resource orchestration in UBIWARE © 2009 UBIWARE Deliverable D3.1 11 may never have successful result (C C ?a), when first capability gives e.g. ?a = 1,2,3, whereas second capability works only with the value range from 5 to 10. Therefore, precise definitions make planning more efficient and increase the probability of non-null result (some null-resulting plans can already be excluded in the planning stage). It is also possible to supply capability description designer with the automated tool that would allow extraction of static data values from the underlying sources or code. In case of service matching, if a set of matching service providers was found, an agent can choose best suitable alternative by negotiating with the service provider agent and then request ODF for subscription for the service (and the provider) chosen. The mechanism of service discovery, however, heavily depends on the approach to service annotations and may fall into two stages of service discovery and process planning: 1. Find potentially suitable services for the process (semantic matching of abstract service ontology artifacts and the goal specified) 2. Negotiate with the potential service provider candidates on the details of service execution (pre-execution). For example, ask if the service provides flight bookings from Moscow to Paris at all, or if the payment can be performed with Visa card. Therefore, if the abstract capabilities will cover generic service classes, then the search and planning may take these two stages. Nevertheless, other scenario options are possible. A service provider may submit detailed service description if an ODF supports it. In this case, the second stage mentioned above can be done without direct service contact. For example, if a database provides additional metadata information on the value range of the parameters in it or some statistical calculations, like mean value of certain parameter, then the planner can take into account value ranges without preliminary database querying. We can distinguish between consuming informational part of the service (negotiation, when the physical state of the world does not change) and consuming the irrevocable service part that changes the state. Good example of both can be: collecting information about the flights available and booking the flight. The informational part of the service can in some cases be presented as an extended semantic annotation and may reside outside of the service (for example, the service registry may contain up-to-date information about destinations of airline company, whereas available seats may only be requested from the service itself). Therefore, the consumption of the service may not really happen unless the irrevocable part or timecritical informational part is used (e.g. ticket booking and seats available). 1.4 Conclusions and further work Service advertising and discovery are an intrinsic part of the process management scenarios. In the open environment the value of it should not be underestimated. With the adoption of automated contracting and legal mechanisms in the services world, the dynamic matchmaking and service discovery will become a cornerstone of business process management. We perceive that process management will be driven by autonomous entities D3.1: Multi-resource orchestration in UBIWARE © 2009 UBIWARE Deliverable D3.1 12 with certain degree of freedom to take decisive actions. The foresight of the future leads us towards further directions the dynamic process management area. In particular, within the framework defined in the introductory part of this Section we will define behavioral patterns and data structures that specify how the agent should (re-)act in order to support servicing agent interaction scenarios. The scenarios are domain independent and constitute three infrastructural layers: execution layer, process management layer and configuration layer. The execution layer defines how one agent can request another agent to execute an action and receive action results. Process management layer is built on top of the execution layer and allows agents to control composite actions in runtime, e.g. before the actual execution starts, the process handler agent can request for availability of candidate agents, if they confirm participation in the process or not. This layer also involves contracting. The configuration layer specifies a meta-level for agent-to-agent interactions that allows agents to negotiate about the processes they run and cooperatively agree on changes. D3.1: Multi-resource orchestration in UBIWARE © 2009 UBIWARE Deliverable D3.1 13 UBIWARE Deliverable D3.1: Workpackage WP2: Task T3.1_w2: Workpackage leader: Sergiy Nikitin 2 UbiBlog – Managing Distributed Resource Histories During WP2’s Year 2 (the Integration phase), we have realized the possibility of querying a set of distributed, autonomous and semantically heterogeneous resource histories as they were one virtual database. We have introduced a new concept of Ontonuts and a corresponding technology. The Ontonuts where tailored to solve the problem of distributed querying in the first place. However, we have generalized the concept to the level of semantic capabilities, which allows us to use goal-based dynamic planning and execution of agent’s actions. Therefore, the third year phase of the WP2 (Mining phase) as it was specified before would rather be an application case of the Ontonuts technology than a research topic. With respect to this fact we have decided to concentrate our efforts towards the fusion of the WP1 and WP2 3 year objectives. Shortly, the WP1 objective for the 3 year is to elaborate a mechanism for advertising of agent capabilities and role scripts (complex capabilities) amongst agents, whereas WP2 research targets data mining capabilities only. Therefore, it is reasonable to integrate WP1 and WP2 under one umbrella of Ontonuts technology which is targeting even more ambitious goal – to enable automated (re)planning and execution of semantically annotated agent actions including distributed data querying, data mining as well as distributed agent-to-agent servicing. 2.1 Servicing Data Mining in UBIWARE This section demonstrates the data mining capabilities as services. The project plan for the 3 year combines the WP1 and WP2 where WP1 should provide a technology for the WP2 to be developed as a case study. Therefore, we use service orientation for both data source as well as data mining capabilities. To model the data mining services we have to define a corresponding data mining domain ontology. The ontology will cover data mining methods and requirements for method inputs and respective outputs. The inputs and outputs should, in turn, refer to the data types. The data mining domain should be fine-grained; hence it can not D3.1: Multi-resource orchestration in UBIWARE © 2009 UBIWA