Potential Enhancements

This section identifies possible enhancements to the proposed approaches and the implemented software tools.

6.2.1 Enhanced BPEL Support

The Orchestration Tools framework currently provides only limited BPEL support and flexibility. In particular, several BPEL constructs remain unsupported, and the tools are capable of only synchronous BPEL execution. Asynchronous execution would probably require a web-server-based approach.

6. Conclusions 142

6.2.2 More Advanced use of Semantic Service Descriptions

Further research is required to achieve automated service selection based on entire semantic service descriptions. While Service Monitor currently considers only the input and output types of OWL-S Processes in semantic service selection, it should also consider the descriptions of the preconditions and results of the web service op-erations. Since preconditions and results are essentially represented as expressions, comparing their semantic meanings is problematic.

The selection of web services for BPEL partner links in the Orchestration En-gine component should be further developed. Because only semantic information is relevant in expressing service requirements, an apparently compatible service may have an interface that is syntactically incompatible with the current BPEL process.

Hence, Orchestration Engine must modify the executed BPEL process so that it refers to the new WSDL port types and operations after determining the services that are semantically compatible with the partner links. However, the logic for modifying the orchestration instructions to apply to unexpected service interfaces remains largely unimplemented in Orchestration Engine. Modifying the various ex-pressions that can be embedded into a BPEL process and refer to syntactic elements appears to be a particularly difficult problem. On the other hand, Service Monitor could probably be extended to provide support in BPEL modification as well.

6.2.3 Support for Alternative Formalisms

While orchestration instructions for the Orchestration Engine are currently devised in BPEL, other languages should also be considered. In particular, OWL-S might be a competitive alternative for BPEL, since it is able to express complex processes and naturally uses semantic data, while BPEL purely relies on syntactic web service interfaces.

The current Orchestration Engine implementation uses the syntactic WSDL de-scription when invoking a web service. However, while the OWL-S specification mainly presents WSDL groundings, it supports other types of groundings as well.

Hence, web service invocation based on the semantic OWL-S descriptions might al-low the invocation of web services without WSDL descriptions. However, invoking web services by executing their OWL-S processes would require either extending the BPEL specification similarly to the BPEL4SWS [65] specification or entirely switching to another modeling language, such as OWL-S, in specifying workflows.

6.2.4 Support for Real-time Requirements

Because the proposed web service orchestration framework is implemented in Java, and the communication between the individual components depends on network

con-6. Conclusions 143 nections, the operation delays are indeterministic. For example, the communication between Ontology Service and Ontology Manager includes the risk that a query is performed while an update operation has been requested but is still pending. More-over, an event notification sent by a domain web service may be delayed because of high network traffic, causing Orchestration Engine to make decisions based on out-dated information. On the other hand, the semantic service composition process, in particular, includes noticeable delays, which may be unacceptable in settings impos-ing strict real-time requirements. While some optimization can be performed to the search algorithm, a domain-independent planning process must generally explore a vast state space. Thus, high real-time performance is difficult to achieve.

Real-time or deterministic aspects are largely ignored in this dissertation, since the main focus is on the overall approach. At the implementation level, the reason-ing libraries may require optimization to allow deterministic performance in some specific cases. For example, the libraries might perform unnecessary memory reser-vation and release, since they are designed to be integrated in desktop environment applications in which delays of a few seconds are tolerable. Nonetheless, the problem is more related to implementation details than the actual research aspects.

The main research problems include estimation of the performance needs of rea-soning to provide results before commencing the execution of a workflow. For ex-ample, the requirement for deterministic performance can be mitigated if time-consuming and indeterministic operations are performed only at initialization phase before commencing the actual execution of a web service workflow. In the case of geographically distributed applications, the communication delays can be estimated at the system design phase and be taken into account at the right level of control implementation. For example, considering the control of a robot manipulator, the trajectories can be calculated remotely and uploaded to the manipulator controller with arbitrary communication delays. Nevertheless, the actual interpolated motion of the manipulator joints can be locally performed, complying to strict real-time requirements. Some research that is related to distributed applications as well as considers real-time performance and avoiding unnecessary memory reservations in Java-based controllers can be found in [59; 50; 15].

6.2.5 Increased Decentralization

In the web service composition pattern proposed, decision-making is solely the re-sponsibility of the Service Monitor web service. Currently, exactly one instance of Service Monitor is assumed to exist at a time. While Service Monitor can com-pose and execute solution plans that involve concurrent operations, parallel goal processes typically lead to a conflict at plan execution time. Moreover, the case of several Service Monitor instances would require the development of a coordination

6. Conclusions 144 mechanism.

All of the presented approaches are vulnerable to network disruptions. In partic-ular, an event notification lost during transmission may render the domain model inconsistent with the actual system status. To protect against such errors, the approaches can incorporate periodic polling of web service states. Nonetheless, de-centralization could be increased by developing a collaboration mechanism between several Ontology Service instances.

Semantic integration between potential alternative ontologies is mainly ignored in this dissertation. Consequently, the proposed approach should be extended to allow the use of several alternative domain models instead of a single commonly agreed ontology.

6.2.6 Improved Service Description Derivation

To improve the OWL-S derivation approach, results indicating failures should also be considered. Currently, Service Monitor generates only process results represent-ing successful service invocations. Nonetheless, the services may return special codes indicating a failure to fulfill the request, for example if the input parameters con-tain incorrect values. Currently, the failure cases can only be detected if none of the results of the executed OWL-S process corresponds to the perceived results of invoking a service.

6.2.7 Transparent Cloud Resource Reservation

A current limitation of the proposed approach is that cloud resources are somewhat inefficiently used. While it is possible to create a network of Cloud Gateway services residing on separate virtual machines, the machines must be leased in a static man-ner, before launching the corresponding Cloud Gateways. Cloud Gateway could be enhanced so that it dynamically created new virtual machines as the utilization of the existing ones reached a certain level.

Cloud Gateway measures the percentage of used memory and the system load average to avoid the overuse of computing resources. The method appears effective in preventing severe performance degradation when starting several applications.

However, currently, Cloud Gateway is unable to estimate the amount of resources an application will consume once it has been started. Therefore, future research should target the implementation of a mechanism for evaluating the run-time re-source consumption of the started applications.

In addition, this research work has experimented with web service Orchestration spanning separate computing clouds. The results suggest that using computing cloud resources causes no considerable performance drawbacks. However, deploying

6. Conclusions 145 several web services on separate virtual machines requires considerable effort. Future research should investigate the use of Cloud Gateway in automating this task.