Execution Manager

From Wsmx-WIKI
Revision as of 17:35, 7 January 2008 by Omasha (Talk | contribs) (Status)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


- Thomas Haselwanter (Component Leader)

- Omair Shafiq


The execution management component is responsible for the management of WSMX as a platform and for the coordination of the individual components. As the kernel of the system it enables and realizes the overall operational semantics of WSMX that let the system achieve the promised functional semantics of its client-side interface. It takes the functionality offered by the individual components of the framework and orchestrates these atomic pieces into a coherent whole in an orderly, and consistent fashion. These properties are guaranteed by the execution semantics, which are executed over the set of services that are available to the execution management component. There is documentation available.

Dynamic Components Management in WSMX using Triple Space Computing

By: Omair Shafiq

WSMX management component manages the overall execution of the system by coordinating different components based on dynamic execution semantics. The individual components have well-defined interfaces and have component implementation well separated with communication issues. Each component in WSMX have wrapper to handle the communication issues with WSMX manager and other components.

The objective is to make the WSMX manager and individual WSMX components to communicate and coordinate with eachother based on Triple Space Computing. Triple Space Computing is a new communication and coordination paradigm that allows asynchronous communication based on the principle of publish and read of data. When a goal is submitted to WSMX, the WSMX manager manages the coordination of all the components to fulfill the goal. During this coordination, it faces delays due to the involvement of heavy processing of semantic descriptions (i.e. matchmaking of goal with available Web Service descriptions in discovery process) which makes the processes in WSMX manager idle until the processing is completed and response is received by it. It causes problems in terms of long time delays in practical scenarios when multiple clients are communicating with WSMX by submitting goals. In order to avoid this, the components communication coordination is planned to be carried out in an asynchronous manner which will decouple the components from eachother and the WSMX manager and also allow to execute multiple goals simultaneously.

The WSMX manager and individual components wrappers are needed to be interfaced with Triple Space in order to enable the WSMX manager to communication with the components via Triple Space. The communication between manager and wrappers of the components will be carried out by publishing and reading the data as a set of RDF triples. The components wrappers will be provided with embadded TS Proxy that will enable the publication and read of data over Triple Space.


The evaluation of the integration of Triple Space Computing with Semantic Web Services is being carried out in terms of efficiency with respect to time, resources consumption, complexity reduction for Semantic Web Services and other applications using Triple Space Computing. The major target audience for the evaluation results of this thesis is the developers of Semantic Web Services and applications using Semantic Web Services. After achieving the integration of Triple Space Computing with WSMX, developers of WSMX will get benefit from the new features by Triple Space Computing.

Components in WSMX have wrappers that manage the communication and coordination of the components which contains proxies for all other components in order to be able to communicate with them. Whenever, a new component in WSMX is added, a proxy of new component is to be added in the wrapper of all the existing components to make them aware of the newly added component. After interfacing Triple Space Kernel with WSMX manager, wrapper of all the components will be provided with only one TS proxy only. There will be no more need to have any further update in the wrappers of other components while adding new component. Secondly the applications using the WSMX will also get benefit of Triple Space Computing integrated with WSMX. It will enable WSMX to execute Goals by Semantic Web Service applications in a more decoupled way and without causing any halting of its components during processing the semantic descriptions and ontologies. It will also enable WSMX to execute multiple Goals at the same time and at the same time be available for users to accept further Goals to be executed. It will give direct benefit to the applications using WSMX. Similarly, WSMX will also get advantage in-terms of having communication and coordination with other WSMXs over Triple Space. As mentioned above, distributed service discovery, selection, composition, mediation and invocation requiring inter-WSMX communication and coordination is even more critical to have decoupling of the WSMXs.

For results of evaluation procedure, a number of experiments will be performed by running similar use-cases on current WSMX and the WSMX enabled with Triple Space Computing. The data will be collected from both the scenarios and will be used to infer the level of efficiency achieved by WSMX and its applications in terms of time, resource consumed, benefits of having persistent publication of data and communication archiving; and the design complexity reduced in the WSMX (or Semantic Web Services in general) and its applications.

At the moment, there are no related solutions that exist with which the results could be compared. The only comparison that can be foreseen is the current WSMX and the one with having support of Triple Space Computing. All other related solutions like sTuples, Semantic Linda and Giga Spaces have been developed as general semantic based space based computing paradigms. Till the date, there is no work that exists to improve the communication and coordination of Semantic Web Services (WSMX, OWL-S tools and other SWS tools in general). However, the comparison will also include the reasons that why Triple Space Computing has been chosen to be supported with WSMX in our case and why not other related semantic enabled space based computing solutions.

Proposed Evaluation Strategies

Based on the above discussion, the first step of evaluation of WSMX-TSC integrated prototype is to analyze the first version that enables WSMX to perform its internal component management using Triple Space Computing middleware. It enables WSMX manager to exploit benefits provided by Triple Space Computing middleware as mentioned in previous sections.

Comparing Resource Availability

While WSMX manager schedules the Goal execution by coordinating the between the components, Triple Space enables the WSMX manger to be released from waiting for response and makes it available to facilitate scheduling of other incoming Goals execution requests while previous Goal is already executing. In this evaluation strategy, we plan to perform the evaluation by submitted Goals to WSMX and checking for availability of WSMX manager to schedule other upcoming Goal execution requests.

Analyzing performance on concurrent execution of Goals

Based on the comparison of resource availability and consumption, in this evaluation strategy we plan to compare the overall execution time taken by WSMX Manager. The comparison has to be done with the WSMX manager operating on SOAP based communication and the WSMX manager using Triple Space Computing middleware.

Comparing communication overhead

While performing the components management over Triple Space, the WSML descriptions are converted into RDF Named Graphs and then are published on Triple Space. It involved some extra steps to be performed than typical message based communication of WSML description. These extra steps include conversion of WSML description, in the form of WSMO4J (WSMO Objects Modeling in Java) into RDF Named Graphs, publishing RDF Named Graphs over Triple Space, retrieving RDF Named Graphs from Triple Space, as well as converting RDF Named Graph back to WSMO4J object. Hence, these extra steps enforce some overhead on the communication of two communicating components. In this evaluation strategy, we plan to analyze and to have an idea about the overhead that is caused in write and read of data from Triple Space.

Communication overhead vs. time saved in multiple Goal execution

In the above mentioned evaluation strategies, we analyzed the behavior of increase in availability of resources and increase in the performance of overall Goal execution by WSMX while using Triple Space Computing for its internal components management. At the same time, we also plan to analyze the overhead caused by required transformation of WSML data into RDF, communicated between the components of WSMX during Goal execution.

Comparing the time taken in Distributed Service execution

WSMX is envisioned to run by interconnecting to other WSMX nodes over Triple Space.. The communication and coordination of different WSMX systems over Triple Space will help the WSMX in providing distributed service discovery, selection, composition, mediation and invocation. The communication model used in the current implementation of WSMX is synchronous. WSMX is dealing with reasoning, therefore, immediate responses are usually not available which is reason for such high response latency being network congestion and slow processing. In such situations, the synchronous communication will be costly as it forces the system to remain idle until the response is available. Triple Space serves as a communication channel between WSMXs by introducing a-synchronicity between communicating parties. The Triple Space supports purely asynchronous communication that optimizes performance as well as communication robustness, especially in the web-scale distributed coordination. This comparison strategy aims to compare the time taken in Goal execution different WSMX systems together, coordinated by SOAP based messages as well as Triple Space.

Comparing time saved by applications while Goal execution

WSMX-TSC integration envisions decoupling between the user invoking WSMX with a Goal and WSMX itself. A goal may take some significant amount of time in execution WSMX might have to match the Goal with large number of Web Service descriptions. It might also need to use selection, composition and mediation mechanisms. In the mean while, it is important for the user application providing Goal to WSMX not to hang-up until the Goal execution has been completed which can be the case if a message based communication mechanism is used between the communication of user and WSMX. User can however avoid this situation having a thread-based approach (i.e. to run a separate thread invoking WSMX) but all kind of users (i.e. light-weight users) can not afford it. Therefore, the WSMX gets this support at middleware level when users communicate with it via Triple Space. The comparison strategy aims to compare the time that a WSMX user can save (to perform other tasks, or at least be available to handle any further request) during the Goal execution by WSMX.

Comparing time save in Resource retrieval by WSMX

The WSML based Web Service descriptions, Goals, Mediators and Ontologies can be grounded to Triple Space. The storage of the semantic data in RDF will help in enhancing and fastening the process of accessing the data afterwards. For instance, in the current discovery mechanism of WSMX, the WSML reasoners have to reason on each and every Web Service description available in the local repositories which takes significant amount of time. When the Web Services descriptions will be stored over Triple Space, the template matching based simpler reasoning will be used as a first step in order to filter-out the most relevant and possibly required Web Service descriptions. The filtered Web Services descriptions based on template based matching over Triple Space are retrieved and converted back to WSML to be reasoned over by WSML reasoners. It makes the process of discovery simpler and faster by performing reasoning operation only on relevant Web Service descriptions rather than all. Based on this assumption, this comparison strategy aims to compare the time taken in resource retrieval by the Resource Manager of WSMX with and with-out using Triple Space.


Task # - Details - Status

1 - Investigation of current state of WSMX Manager and Components Communication - Done

2 - Interfacing WSMX Manager with Triple Space Kernel - Done

3 - Embedding Triple Space Proxies in WSMX Components Wrappers - Done

4 - Defining communication channels for multiple components coordination simultaneously - Done

5 - Inter-connecting WSMX managers in different WSMX systems to enable inter-connection of different WSMX systems for distributed service discovery, selection, composition and invocation - To be done (dependency on TS Kernel prototype)

6 - Implementation (WSMX TSC Prototype) (In final stages with evaluation in progress)

7 - Designing evaluation strategies - Done

8 - Evaluation Results - In progress

Relevant Publications

Journal Publications

Dieter Fensel, Reto Krummenacher, Omair Shafiq, Eva Kuehn, Johannes Riemer, Ying Ding, and Bernd Draxler; TSC - Triple Space Computing, special issue on ICT research in Austria, journal of electronics & information technology (e&i Elektrotechnik & Informationstechnik), January/February 2007.

Conference and Workshop Publications

Omair Shafiq, Michal Zaremba and Dieter Fensel, "On communication and coordination issues of Semantic Web Services", in the proceedings of IEEE International Conference Web Services (ICWS 2007), July 9-13, 2007, Salt Lake City, Utah, USA.

Omair Shafiq, Matthew Moran, Emilia Cimpian, Adrian Mocan, Michal Zaremba and Dieter Fensel, "Investigating Semantic Web Services execution environments: A comparison between WSMX and OWL-S tools", in proceedings of the 2nd International Conference on Internet and Web Applications and Services (ICIW 2007), May 13-19, 2007, Morne, Mauritius.

Omair Shafiq, "Triple Space Computing for Semantic Web Services - a PhD roadmap", Doctoral Symposium at 5th International Semantic Web Conference (ISWC 2006), Springer-Verlag LNCS 4273, 5-9 November 2006, Athens, Georgia, USA.

Tomas Vitvar, Adrian Mocan, Mick Kerrigan, Michal Zaremba, Maciej Zaremba, Matthew Moran, Emilia Cimpian, Thomas Haselwanter, Dieter Fensel; Semantically-enabled Service Oriented Architecture : Concepts, Technology and Application, Service oriented Computing and Applications (accepted; to be published)

Thomas Haselwanter, Paavo Kotinurmi, Matthew Moran, Tomas Vitvar, Maciej Zaremba WSMX: a Semantic Service Oriented Middleware for B2B Integration. In proceedings of the 4th International Conference on Service Oriented Computing, Springer-Verlag LNCS Chicago, USA, 2006.

Thomas Haselwanter, Maciej Zaremba, Michal Zaremba Enabling Components Management and Dynamic Execution Semantic in WSMX. In Proceedings of the 2nd WSMO Implementation Workshop (WIW05) Innsbruck, Austria, 2005. Get the document.

Thomas Haselwanter, Paavo Kotinurmi, Matthew Moran, Tomas Vitvar, Maciej Zaremba Dynamic B2B Integration on the Semantic Web Services. In Proceedings of the Semantic Web Service Challenge Workshop - Phase II Workshop at ESWC2006, Budva, Montenegro, 2006.

O. Shafiq, R. Krummenacher, F. Martin-Recuerda, Y. Ding, D. Fensel: Triple Space Computing middleware for Semantic Web Services, The 2006 Middleware for Web Services (MWS 2006) Workshop at 10th IEEE International Enterprise Computing Conference (EDOC 2006), 16-20 October 2006, Hong Kong.

O. Shafiq, M. Zaremba, D. Fensel: How Triple Space Computing and Semantic Web Services can meet together? In poster session, 1st Asian Semantic Web Conference. (ASWC 2006), Beijing, China, September 3-7, 2006.