1.  Copyright 2005 Digital Enterprise Research Institute. All rights reserved. www.deri.org Enabling Components Management and Dynamic Execution Semantic in WSMX Authors: Thomas Haselwanter, Maciej Zaremba and Michal Zaremba WIW2005 2005/06/06

2. 6/06/20052 Overview

3. 6/06/20053 Why distribute components? Major factors driving a trend of distribution are clearly economic. The most cost-effective computation solution is to harness many low- cost microprocessors together and to spread tasks across them, instead of providing a heavy-duty mainframe runtime environment for a system. Distributing acquisitive tasks greatly improves system scalability. Component distribution increases involvement from third parties in system development, since it allows plug-in and plug-out strategy without affecting system as a whole. Distributed processing may facilitate compliance with particular component provider policy (e.g. prohibition on component dissemination or source code disclosure).

4. 6/06/20054 WSMX distributed architecture WSMX is a Service Oriented Architecture system composed of a set of distributed loosely coupled components (like Discovery, Data Mediation, Process Mediation, Communication Manager and others). There are no hard-wired bindings between components. Asynchronous communication between components is provided by a Tuple Space event based mechanism. Components are not aware of their distribution at all. An additional layer of wrappers responsible for a communication issues is provided to them. Overall system behavior is specified by Dynamic Execution Semantics, thus system behavior can be easily modified and new types of components might be incorporated.

5. 6/06/20055 Tuple Space Provides persistent shared space that enables seamless interaction between various parties. De-couples interacting parties by reference, time, and space: –Parties do not have to be aware of each other, –Parties do not have to be present at the same time, –Parties can run in totally different environments, as long as they can access the same Tuple Space, In the future it should be easier to switch to a RDF based Tuple Space, i.e. Triple Space.

6. 6/06/20056 Component Collaboration Communication in current WSMX implementation is based on a variant of a Tuple Space, namely JavaSpaces that handles issues like data transfer, synchronization, persistence, etc. JavaSpaces can be composed of multitude distributed spaces. Wrapper subscribes to events in Tuple Space by specifying event-type template. To maximize usage of local resources and limit data transfer across the network we propose priority of locally subscribed wrappers, i.e. set of event-type template rules is run first on local fragment of Tuple Space and afterwards synchronization with other Tuple Spaces takes place.

7. 6/06/20057 Wrappers Wrappers are generic units that separate component implementation from communication issues. Wrappers reduce the changes required in code if the transport layer changes. Wrappers are automatically attached to each component implementation during instantiation carried out by a WSMX Kernel.

8. 6/06/20058 Wrapper: Reviver and Proxy There are two major parts of a Wrapper: Reviver. Its responsibility is to interact with the transport layer (a Tuple Space) by subscription to a proper event- type template. Reviver publishes result events in a Tuple Space. Proxy. Its role is to enable a component to request other component’s functionality. In some cases there are dependencies between components, e.g. Data Mediation is required during execution of Discovery component.

9. 6/06/20059 Dynamic Execution Semantics Dynamic Execution Semantics enables composition of loosely-coupled WSMX components and provides necessary execution logic (e.g. conditional branching and fault handling). DES allows specifying system behavior tailored to various user requirements. For instance WSMX can be utilized only for Web Service discovery or can carry out discovery, selection, and a whole conversation with selected Web Service.

10. 6/06/200510 Dynamic Execution Semantics An instance of DES is part of each event published in a Tuple Space. Reviver takes an event from a Tuple Space and allows execution of the attached instance of DES. Local component functionality is invoked by the DES. State of DES changes over time whilst traveling and executing across distributed component locations.

11. 6/06/200511 DES - Current Status and our Vision DES in WSMX is fully implemented as a state-aware piece of Java code that is executed across distributed locations. We envision DES specified as workflow model as a next step in WSMX component composition and coordination. DES workflow models created for WSMX components should not be affected by WSMX Tuple Space communication paradigm and capability to use all workflow control and data patterns provided by the chosen workflow language should be preserved.

12. 6/06/200512 Microkernel Component-based plug-ins Modularity Isolation domains Life cycle management & Bootstrap Pooling Manageability Metric Monitoring Administration

13. 6/06/200513 Microkernel

14. 6/06/200514

15. 6/06/200515 Outlook