Overview & Scope of WSMX
Overview and Scope of WSMX
This deliverable presents the ongoing work within Web Services Execution Environment (WSMX) working group. WSMX is an execution environment which enables discovery, selection, mediation, invocation and interoperation of the Semantic Web Services (SWS). The development process for WSMX includes establishing a conceptual model, defining its execution semantics, developing the architecture of the system, designing the software and building a working implementation of the system.
Through our research on WSMX, we have provided in a first phase architecture for the SWS systems. In our deliverables we present the SWS architecture, we define its execution semantics, mediation, discovery and invocation mechanisms, and any other aspects that are needed in any SWS related systems. Work carried out by the WSMX working group, apart from its research focus also provides a reference implementation of the Web Services Modeling Ontology (WSMO). Apart from core SWS functionalities that should be available with any execution environment for the SWS, the research team is also addressing some more specific enterprise systems functionalities while developing the WSMX system Some of these additional functionalities, which are going to be available with the later versions of the WSMX: (1) a plugin mechanism to handle any distributed components that have been developed since the earlier versions of WSMX were designed, (2) an internal workflow engine capable of executing formal descriptions of the behavior of system components and (3) a resource manager enabling persistence of any arbitrary data (WSMO and non-WSMO related) produced by components during run-time of the WSMX server. As well as developing the system itself, the research group will also address all the key aspects of enterprise software. Thus the updated releases of the system will take account of aspects like reliability, scalability, security, etc. These will become an integral part of the WSMX server.
The goal of the working group is to develop further the WSMX architecture towards business process management (BPM) applications and GRID.
In this document, we briefly overview the research carried out by the WSMX working group and discuss WSMX functionality. We describe specific WSMX deliverables produced by the WSMX working group, detail projects were WSMX is the core execution technology and address further developments towards BPM and GRID.
[BPM] - Business Process Management
[GSMO] - Grid Service Modelling Ontology
[GSMX] - Grid Service Modelling eXecution environment
[WSMO] - Web Service Modelling Ontology
[WSML] - Web Service Modelling Language
[WSMX] - Web Service Modelling eXecution environment
Table of content
1.1 Scope of WSMX development
2. WSMX functionality
2.1 Current functionality
2.2 Future functionality
3. WSMX deliverables
4. Related systems
5. Projects where WSMX is the core system
6. WSMX for GRID Business Process Management
Web Services specifications have been developed to support distributed heterogeneous applications built by different vendors. Existing Web Services technologies as UDDI , WSDL  and SOAP  provide the basic functionality for discovering (UDDI), describing interfaces (WSDL) and exchanging messages (SOAP) in heterogeneous, autonomous and distributed systems. In practical terms, existing Web Services support operations which are limited to independent calls over a network, hard wired collaborations or predefined supply chains. Web Services specifications do not provide any mechanism to specify how to include any additional semantic information which would enable processing them without any human interaction.
The nowadays approach to systems integration based on semantically enhanced Web Services is designed to be achievable in the near future through SWS. The Web Services Modeling Ontology (WSMO) initiative1 is one of the several research efforts currently underway around the world working to develop a conceptual model, language and execution environment for SWS. Enhancing existing Web Services standards with semantics markup standardized through the WSMO initiative, promotes already existing Web Services standards for semantic-enabled integration.
The Web Services Execution Environment (WSMX) is one of the WSMO initiatives aiming at providing an execution environment for discovery, selection, mediation, invocation and interoperation of the SWS for various business and industrial applications and furthermore for GRID and Business Process Management (BPM).
WSMX research aim is to provide architecture and a prototype implementation for Semantic Web Service (SWS) systems. WSMX has been based on the conceptual model provided by Web Services Modeling Ontology (WSMO) which describes all aspects related to SWS. WSMX is also a reference implementation for WSMO being a vehicle for driving new projects and partnerships.
This document provides an overview of WSMX in terms of scope, functional objectives, development approach and deliverables in relationship with WSMO and further developments toward GRID and BPM.
1.1 Scope of WSMX development
WSMX started as the reference implementation of WSMO. The initial version of WSMX has been based on a refined and minimal set of WSMO concepts, while subsequent versions are taking into consideration the complete conceptual model provided by WSMO. For the initial version of WSMX, a complete architecture including discovery, mediation, selection and invocation components has been designed including also all the supporting components enabling exchange of messages between mock-up service requesters and providers. At this stage of WSMX development, the implementation of these components has been simple, but with each subsequent implementation new and more complex aspects are going to be addressed. WSMX initial functionality allows achieving a user-specified goal by invoking Web Service described with the semantic markup. The first version of WSMX has been available since June 2004 at the sourceforge portal. Subsequent versions of WSMX have incorporated the ongoing research of the SWS community, in particular the WSMO working group and the WSML working group, those augmenting and empowering WSMX to provide full SWS support.
The next WSMX directions are towards GRID and Business process Management applications. Thus WSMX will develop to become GRID compatible and become Grid Services Modeling Execution environment (GSMO), while it will be refined on real world case studies of business process management.
WSMX follows the best practice of staged component-based software development. The Initial phase was focused on constructing a rigid architecture for Web Service execution using decoupled, independent components. Once the basic WSMX framework was in place, subsequent phases are focusing on refining the individual components, improving the whole framework and providing new aspects. The rationale for this staged approach is to provide component-based software that is both maintainable and extensible. It is important to emphasize that because of this component based approach, changes can be implemented gradually over time. Furthermore, GRID and BPM will provide new technical specifications that are going to be taken into account for both development and architecture development.
2. WSMX functionality
2.1 Current functionality
The initial functionality of WSMX provides the basic components needed to run end-to-end communication. Later versions of WSMX will address the complete set of the functionality required to execute SWS. It is designed in such a way to extend and improve functionality later.
Core Component A central component of the system has been provided with the first release. We have adopted a multi-threaded approach for enabling components connectivity. JMX technology has been used for components management. The execution semantics has been hard-coded into this component.
Resource Manager The repository of available SWS and of available goals is stored locally. There is a discovery component, but its functionality is limited to searching in the internal WSMX repository (Resource Manager remains localized). The user has to manually fill this repository with available SWS. Over time the development of Resource Manager and its repositories has been moved from rigid JDBC technologies with MySQL6 database as the underlying repository, through EJB framework towards a more lightweight framework based on Hibernate and Spring.
Service Discovery The goal-capability matching has a simple implementation: a match is sought between the post-conditions and effects of the goal and the post-conditions and effects of some capability. This match is a logical equality; this means that capabilities subsuming the goal, or capabilities subsumed by the goal will not be returned. There is already a simply key-word matching discovery implemented. In WSMO Standard, a goal specifies the objectives that a client may have when he/she consults a web service. A capability describes a relation between a certain state that has to exist, and a certain state that can be achieved by a web service. If a user states his/her goal, the goal-capability matching component in the execution environment have to use a logical reasoner to search for all SWS having a capability that satisfies this goal. The reasoner must be able to find capabilities that exactly match this goal, as well as capabilities subsuming this goal (and possibly capabilities subsumed by this goal, maybe even to suggest close matches. However, since this is a logically difficult task, in the initial version of WSMX we do have this goal-capability matching component, but it is implemented in a simple way.
Service Selection In the initial version, the algorithm for selection is achieved by simply picking the first matching web service. However, user preferences and expectations as well as non-functional properties of services should be involved in the selection process. We also consider another scenario where service is selected outside the WSMX server by the service requester and the selected Web Service is already given to the system.
Mediation Mediation is not done by using some external mediator (as in WSMO), but by specifying mapping rules between ontologies. Mediation is achieved, if possible, by applying these mapping rules. In WSMO Standard, mediation is performed by some external mediator. To overcome differences in ontologies used by different SWS, different mediators can be used. In the initial implementation, WSMX mediation is performed by a mediation component, that uses predefined mapping rules to mediate between two ontologies. In WSMX mediation will adress both data mediation and process mediation.
Communication Manager So far, simple message exchange predefined patterns are the only interaction styles supported.
Choreography Choreography does not exist in the initial version of WSMX, only an initial set of interfaces has been defined.
WSMT WSMT does not exist in the initial version of WSMX, however tools supporting mapping processes or a WSMO editor do exist.
2.2 Future functionality
WSMX is being designed to offer full support for SWS. WSMX deliverables describe what the SWS architecture should look like, and define its execution semantics, mediation, discovery and invocation mechanisms, and any other aspects needed by any SWS related systems. A first expected functionality of WSMX can be described in terms of aggregated functionality of all its components. Then, new components and architectural re-design is planned once the GRID and BPM directions are adopted and projects related to them are in progress.
At this stage, the following main components have already been envisaged for WSMX:
Core Component The Core Component is the central component of the system, and all the other components are going to be connected to it. All interactions between components will be coordinated through core component. The business logic of the system, the events engine, the internal workflow engine, the distributed components loading etc. will all be subcomponents of the Core Component. While at this stage we still consider the Core Component to be a central module for the system, in the future to ensure reliability of WSMX, the clustering mechanism for distributed Core Components might be also developed. For resources intensive operations instead of having only one instance of Core Component, many instances could be instantiated on several machines to create a WSMX cluster.
Resource Manager The Resource Manager is responsible for management of repositories to store definitions of any WSMO (Web Services, goals, ontologies and mediators) and non-WSMO related objects for WSMX. Depending on the scope of information stored in the underlying registries, we distinguish registries to be local and global. Information stored in the local registry is relevant for domain-specific operations (e.g. most of the system run time information will be available only to the local instance of WSMX) whereas the global registry could be shared across several domains (e.g. registries of SWS descriptions). While both stored data and accessibility to this data might differ considerably between registries, the Resource Manager remain the only entry point for them (it is not possible to access any of registries directly, but only through ResourceManager).
Web Services Repository deals with semantic description of Web Services, such as their capabilities (pre-conditions, post-conditions, assumptions and effects), interfaces (choreography and orchestration) and non-functional properties, both general and Web Service specific. All information stored in the Web Services Repository is related to case scenarios in which this information is to be used, such as discovery of services or monitoring of services. Goals repository deals with semantic description of general goals. A WSMO Goal in most cases expresses the ”wish” that a user wants to achieve. Some of the goals may be reusable and provided as templates and therefore should be published using the repository. Non-reusable or frequently updated goals should be stored at the service requester side or other locations. The goal repository can thus contain predefined goals constructed by domain experts as well as user-specific goals. A tool to construct/refine goals will be created for this purpose.
Ontology repository deals with ontologies to be stored in the registry describing the semantics of particular domains. Any components might wish to consult an ontology, but in most of the cases the ontologies will be used by mediator related components to overcome data and process heterogeneity problems. We recognize the requirement for a visualization tool and a management mechanism for ontologies, that should be provided by WSMX. Ontologies stored by WSMX are expressed in terms of WSML, but we consider also the case that the syntactical adaptation from any ontology syntax is possible, before storing them.
Mediator repository deals with mediators to be stored in the registry. WSMO mediators have become a standard proposal covering various approaches for data and process mediation. While mediators in WSMO are still underspecified, we are already considering storing them in a repository for possible use of the data and process mediation components.
Data repository During run time of the system, lots of system specific data is produced. Also, components might generate data, which should be persistent. Data repository allows us to store any system data and any component-specific data required for correct system execution.
Service Discovery The main purpose of Service Discovery is to provide functionality on matching of usable SWS with the goals. When matching SWS, a number of them could be selected which are capable of satisfying criteria specified by a goal. A number of SWS could be returned from this step.
Service Selection Selection of the Web Service might happen in WSMX and for that purpose a selection component is used. Selection can also take place outside of WSMX after the service requester is presented with the set of potentialWeb Services satisfying his goal. When selectingWeb Services, one, possibly ”best” or ”optimal” variant of a service should be returned from a set of satisfying matching criteria. To select an optimal service, different techniques can be applied, ranging from simple selection criteria (”always the first”) to more sophisticated techniques, such as multi-criteria selection of variants also involving interactions with a service requester. Different variants of services could be described by different values of parameters (non-functional properties specific to web services), such as financial properties, reliability, security, etc.
Data and Process Mediator Mediation is needed when two entities that cannot communicate directly need to interact. The reason why they cannot communicate is that they are using different syntax or semantics of data they are dealing with and/or processes for the same operation might mismatch. WSMX offers mediation of data communicated and processes used to be understandable and useful for the selected Web Services. Data mediation is based on paradigms of ontology management, ontology mapping and aligning in particular.
Data Mediators deals with the heterogeneity problems that may appear at the data level of the communication between various entities. To enable this communication data has to be transformed from the format used by the source partner in the format required by the target partner. As a consequence, we offer support for creating mappings (in a semi-automatic manner) between the ontologies that semantically describe the data used by the parties involved in the communication, and means for representing and storing these mappings in an external repository. In addition, we make available a run-time data mediator to be used during run-time for applying the already existing mappings on the incoming data and to transform it in the required form.
Processes mediation is concerned with determining how two public processes can be matched in order to provide certain functionality. The Process Mediator component bases its functionality on the choreographies of both the Web Service and the goal that requests a certain functionality. By analyzing the two choreographies, the Process Mediator can determine if a certain message is expected by one of the partners, and in which particular phase of the conversation it should be sent.
Communication Manager WSMX will offer invocation of selected services, obeying their interfaces that are choreography and orchestration patterns. Communication Manager consists of two subcomponents: invoker and receiver. WSMX is an intermediary system sitting between service requester and provider, so communication in both directions is supported by these two subcomponents. In general, invocation of services could be based on any underlying protocol of service providers (e.g. SOAP, proprietary protocols, etc.) and for this purpose adapter framework in designed. It would be the responsibility of an adapter to implement interactions with a particular service provider using communication protocols different than SOAP.
Choreography The choreography of a Web Service defines its communication pattern, that is, the way a requester can interact with it. The requestor of the service has its own communication pattern and only if the two of them match, a direct communication between the requestor and the provider of a service can take place. Since the client’s communication pattern is in general different from the one used by the Web Service, the two of them will not be able to communicate directly, even if they are able to understand the same data formats. The role of the Choreography Engine is to mediate between the requester’s and the provider’s communication patterns. This means providing the necessary means for a runtime analysis of two given choreography instances and using Mediators to compensate for the possible mismatches that may appear, for instance, generating dummy acknowledgement messages, grouping several messages into a single one, changing their order or even removing some of the messages in order to facilitate the communication between the two parties.
WSMT Web Service Modeling Toolkit (WSMT) is a framework for the rapid deployment of graphical administrative tools, which can be used with WSMX.
Reasoner Although development of a reasoner is not part of the WSMX development process, a WSML-compliant reasoner will be an important element of the whole WSMX framework. Reasoner will provide reasoning services for the mapping process of mediation, as well as functionality relating to validation of a possible composition of services, or determination if a composed services in a process is executable in a given context. Also, this component will be used for finding capabilities that exactly match the requester’s goal, as well as capabilities subsuming this goal.
Additional functionalities Some of additional functionalities, which are going to be available with the later WSMX system implementations include
(1) a plug-in mechanism to handle any distributed components that have been developed since the earlier versions of WSMX were designed,
(2) an internal workflow engine capable of executing formal descriptions of the behavior of system components and
(3) a resource manager enabling persistence of any arbitrary data (WSMO and non-WSMO related) produced by components during run-time of the WSMX server.
As well as developing the system itself, the research group will also address all the key aspects of enterprise software. Thus the updated releases of the system will take account of aspects like reliability, scalability, security, etc. These will become an integral part of the WSMX server.
3. WSMX deliverables
WSMX development is described in several inter-related deliverables, as followings:
WSMX Mission Statement. The Mission Statement deliverable specifies the mission of the WSMX working group - to create an execution environment for the dynamic discovery, selection, mediation, invocation and inter-operation of SWS.
WSMX System Functionality Scope. This deliverable provides an overview of expected functionality the system is going to provide with each subsequent release.
Web Service Execution Environment - Conceptual Model. The conceptual model defines all concepts used in WSMX. This conceptual model is based on WSMO; if necessary, it will be extended by introducing several concepts.
WSMX Execution Semantics. The WSMX Execution Semantics deliverable defines the operational behavior of WSMX. This is a formal specification, describing exactly how the system behaves. The execution semantics ensures a common understanding among developers of what the system should do and how it should behave in all possible situations. The execution semantics also makes sure that different implementations of an execution environment for WSMO behave the same way to the outside world (if they follow the same execution semantics). Thirdly, the formal nature of the execution semantics enables checking (and proofing) certain properties of the system. WSMX Architecture and System Design. This deliverable presents the architecture of WSMX, this being the basis for the implementation. The deliverable explains the architectural decisions that were made, the design of the system, and describes the various components.
WSMO Discovery. The WSMO Discovery deliverable describes how discovery is dealt within WSMO. Different techniques for web service discovery are discussed including mediation support needed for different approaches to web service discovery. In detail, logic-based discovery of web services is discussed.
WSMX Data Mediation. The WSMX Data Mediation deliverable explains how mediation is dealt within WSMX. This deliverable describes several aspects related to WSMX mediation, for instance how to define mapping rules, how a reasoner can do mediation following those mapping rules, and it introduces a tool that helps users to write their own mapping rules.
Processes Mediation in WSMX. This deliverable tackles the process mediation problem, describing what process mediation means in the context of WSMX, and proposing a process mediation architecture.
WSMX Grounding. This document describes how WSMX handles the translation to and from WSML to other data representations at the boundary of the environment.
WSMX Documentation . WSMX Documentation provides the description of a step-by-step WSMX installation and gives examples of its usage.
WSMX Use Cases . The Use Cases deliverable exemplifies several usage scenarios of WSMX. Three possible use cases are identified, namely a Business-to- Consumer (B2C), a Business-to-Business (B2B) and an Application-to-Application (A2A) scenario. This showcase how WSMX can be utilized for such real-life tasks.
Web Service Modeling Toolkit (WSMT). The purpose of this document is to outline the Web Services Modeling Toolkit (WSMT). WSMT is a framework for the rapid deployment of graphical administrative tools, which can be used with WSMO, WSML and WSMX.
WSML Editor . This deliverable describes the WSML Editor plugin for the Web Service Modeling Toolkit. The WSML Editor is a graphical tool for editing Ontologies, Goals, Mediators and Web Services described in the WSML family of languages.
WSMX Monitor. This document outlines the WSMX Monitor plugin for the Web Service Modeling Toolkit. The WSMX Monitor is a graphical tool for monitoring the state of each of the WSMX components within the WSMX system, along with the system itself.
4. Related systems
Implementations based on SWS concepts are nowadays the subject of intensive research. Apart from WSMX as the reference implementation of WSMO, other implementations based on SWS concepts also exist such as IRS, OWLS or METEOR-S. It is the intention of WSMX to be interoperable with such systems where possible. The main components of IRS (Internet Reasoning Server) are the IRS Server, the IRS Publisher and the IRS Client. The IRS server holds descriptions of SWS. IRS Publisher links Web services to their semantic descriptions within the IRS server and generates a wrapper which allows a web service to be invoked. An IRS user asks through the IRS Client for a task to be achieved, and accordingly the IRS server selects and invokes an appropriate Web service. Recently, IRSIII provides infrastructure for creating WSMO-based SWS, building upon the previous implementation of IRS. A set of OWL-S tools exists rather than a complete execution environment based on OWL-S concepts. For example, OWL-S Editors allow the maintaining of OWL-S service descriptions, OWL-S Matcher provides an algorithm for different degrees of matching for individual elements of OWL-S, OWL-S Axis plugin advices service providers on how to provide service description using OWL Services, etc. The main components of METEOR-S are Abstract Process Designer, Semantic Publication and Discovery Engine, Constraint Analyzer, and Execution Environment. Abstract Process Designer allows a user to create the control flow of the process using BPEL constructs. Semantic Publication and Discovery Engine provide semantic matching based on subsumption and property matching. Constraint Analyzer dynamically selects services from candidate services, which are returned by the discovery engine. Execution environment performs actual late binding of services returned by the constraint analyzer and converts abstract BPEL to executable BPEL.
5. Projects where WSMX is the core system
5.1 DIP Project http://dip.semanticweb.org/index.html
DIP (Data Information and Process Integration with Semantic Web Services) is an EU integrated project targeting practical Semantic Web Service (SWS) technology implementation in e-Banking, Telecom and e-Government applications. The project aims to achieve its vision by developing and extending current semantic web and web service technologies in order to produce a new infrastructure for semantic web services - an open source architecture in which different web services can discover and invoke each other without the need for human intervention. In particular, DIP has the following four objectives (‘golden bullets’) as its target:
- An Open Source Architecture for Semantic Web services
- Practical, exploitable tools and methods that can be deployed for all kind of industries
- Impact on International Standards through W3C [W3C reference], Semantic Web Services Initiative (SWSI)
- Real Use Case Implementations of SWS in application scenarios for the Government, Telecommunications and Banking sector
The achievement of these objectives represents a variety of demanding research challenges in different areas, mainly in Information Management, Enterprise Application Integration (EAI) and Web-enabled eCommerce. Eighteen partners, consisting of European Universities and leading IT focussed companies are working together for three years to accomplish these results. They are structured in fifteen teams with individual research and development focus. Within DIP, WSMX is the execution environment platform for DIP prototype.
The scientific and technological objectives of SWING are to develop and open, easy to use semantic web service framework of suitable ontologies and inference tools for annotation, discovery, composition and invocation of geospatial web services. Further, to evaluate the appropriateness of such framework by developing a geospatial decision making application that can find and provide interoperable semantic web services.
The impact of the SWING framework will benefit several major user groups, i.e. geospatial decision makers, data and service providers, application developers and the research community. Geospatial decision makers will be able to use the dedicated application and hence decrease the time used to discover and utilise relevant data. Citizens are allowed to access the information from the decision making process and can thus better understand the rationale behind the decisions. Data and service providers will be able to use the catalogue component to annotate their services. Application developers will be able to use the development environment to create semantically annotated composed web services more effectively than before. The research community will be able to utilise the experience gained in the project and to directly experiment with, reuse or extend the core open source components, i.e. the ontologies, annotation engine, execution environment and the development environment.
5.3 SUPER http://super.semanticweb.org/
SUPER (Semantics Utilized for Process management within and between EnteRprises) is an EU Integrated project. The major objective of (SUPER) is to raise Business Process Management to the business level, where it belongs, from the IT level where it mostly resides now. This objective requires that BPM is accessible at the level of semantics of business experts. Semantic Web and, in particular, Semantic Web Services technology offer the promise of integrating applications at the semantic level. Therefore, we aim at providing a semantic-based and context-aware framework, based on Semantic Web Services technology that acquires, organizes shares and uses the knowledge embedded in business processes within existing IT systems and software, and within employees’ heads, in order to make companies more adaptive.
SUPER is build on top of the results of leading EU-funded projects and will make maximal reuse of (1) the Semantic Web technology developed in SEKT and (2) the Semantic Web Service technology developed in DIP, SWWS, and IBROW. As a result, SUPER will extend the generic architecture, languages, and tools of the DIP research project (WSMO/L/X) into actually deployable solutions for the chosen application area. SUPER will represent each existing business process or process fragment in the form of a WSMO Semantic Web Service, and business experts’ requirements as WSMO goals, and implement the coupling between the two by extending WSMO mediators.
6. WSMX for GRID and Business Process Management
Semantic Grid is 'an Internet centered interconnected enviroment that can effectively organise, share, cluster, fuse and manage globally distributed versatile resources based upon the interconnection semantics'. Its main capabilities are resembling some of WSMX ones and therefore there is a high interest in combining these Semantic Grid and WSMX (as SWS application) to take advantages for the both approaches. WSMX architecture is going to be modified in order to encapsulate the GRID needs. However the core concepts behind WSMX will form the basement for the new GSMX.
[..more to be added..]
Business process management is concerned primarly with managing the execution of IT-supported business operations from a business expert’s process view. The strict sequential model of IT design in enterprises has led to enormous problems, because organizations are in continuous change. Every requirements analysis becomes partly outdated while the implementation in the next stage of the systems engineering process is performed. The longer the cycles take, the more a problem this becomes. This was a lesser issue when (1) the use of IT in organizations was limited (there were few “legacy” systems), when (2) market structures were more stable, and when (3) the level of integration with suppliers and customers was low. Nowadays, however, organizations are trying hard to continuously align their actual business processes, as executed by the multiplicity of systems, with the should-be processes as derived from managerial needs. It is a common observation that the launch of a new product or the implementation of a new revenue scheme for the employees will be determined by the ability to setup the required processes within the existing IT landscape.
In short, the insufficient degree of machine-accessible representations of the processes and data about processes inside organizations creates the following problems in current BPM:
1) Low degree of automation in the implementation stage: The actual setup of business processes according to managerial needs is mainly done manually, often involving numerous consultants.
2) Implementation delay: The dynamic composition of business processes is mostly impossible, increasing the time to market and reducing an organization’s agility.
3) Cognitively inadequate complexity: The lack of a clear separation between business goals and implementation details makes the management of business processes overly complex.
4) Process blindness: Managers and other business experts cannot quickly determine whether a specific process can be composed out of existing atomic processes, nor can those stakeholders query the process space within their organization by logical expressions. Thus, checks for process feasibility (e.g. prior to the launch of new products or services) or compliance are still to be done manually by business analysts.
5) Invisible, complex interdependencies: It is impossible to use machine reasoning in order to identify potential side-effects of modifications. Also, process improvement should strive for a global process optimum, not local process optima; however, this cannot be achieved without a proper representation of interdependencies.
[..more to be added..]
As a first step, an execution environment for the dynamic discovery, selection, mediation, invocation and interoperation of SWS is being designed and implemented. We present how WSMX SWS architecture loos like, we define its execution semantics, and any aspect we perceive compulsory in any SWS related systems. In the initial stage we focus on delivering a component-based architecture, ensuring a basis for later extension. We have designed initially all the components based on the WSMO conceptual model. It is our intention to extend these components to fully support WSMO and to provide a fully-fledged enterprize system for execution of the SWS. A second step is going to be WSMX extension towards GRID and BPM and development of GSMX that will have a WSMX based architecture but extended for GRID. The current document will be updated as work evolves in WSMX working group and in the projects that are/will be using WSMX/GSMX.
The work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program. The editor would like to thank to all the members of the WSMO working group for their advice and input into this document.
 David Aiken and Maciej Zaremba. D22v0.1 WSMX Documentation. Technical report, Dec 2004. http://www.wsmo.org/2004/d22/v0.1/20041210/20041210.pdf.
 T. Bellwood, L. Clment, and C. von Riegen. UDDI Specification Version 3.0.1. UDDI Spec Technical Committee, October 2003. http://uddi.org/pubs/uddi v3.htm.
 R. Chinnici, M. Gudgin, J. Moreaum, and S. Weerawarana. Web Services Description Language (WSDL) Version 1.2. World Wide Web Consortium, March 2003 http://www.w3.org/TR/wsdl20/.
 Emilia Cimpian and Adrian Mocan. D13.7 v0.1 Processes Mediation in WSMX. Technical report, Jan 2005. http://www.wsmo.org/2005/d13/d13.7/v0.1/.
 Emilia Cimpian, Adrian Mocan, Matthew Moran, Eyal Oren, and Michal Zaremba. D13.1v0.3 Web Service Execution Environment – Conceptual Model. Technical report, Dec 2004. http://www.wsmo.org/2004/d13/d13.1/v0.3/.
 Armin Haller. D13.6v0.1 WSMX Use Cases. Technical report, Dec 2004. http://www.wsmo.org/2004/d13/d13.6/v0.1/20041205/.
 Armin Haller. D26v0.1 WSMX Grounding. Technical report, Dec 2004. http://www.wsmo.org/2004/d26/v0.1/20041206/.
 Armin Haller and Michal Zaremba. D7.3v1.0 Mission Statement - WSMX. Technical report, Jan 2005. http://www.wsmo.org/2005/d7/d7.3/v1.0/ 20050109/.
 Uwe Keller, Rubn Lara, Axel Polleres, Ioan Toma, Michel Kifer, and Dieter Fensel. D5.1v0.1 WSMO Web Service Discovery. Technical report, Nov2004. http://www.wsmo.org/2004/d5/d5.1/v0.1/20041112/.
 Mick Kerrigan. D9.1v0.1 Web Service Modeling Toolkit (WSMT). Technical report.
 Mick Kerrigan. D9.2v0.1 WSML Editor. Technical report, Jan 2005. http://www.wsmo.org/2005/d9/d9.2/v0.1/20050131/.
 Mick Kerrigan. D9.3v0.1 WSMX Monitor. Technical report, Jan 2005. http://www.wsmo.org/2005/d9/d9.2/v0.1/20050131/.
 N. Mitra. SOAP Version 1.2 Part 0: Primer. World Wide Web Consortium, June 2003. http://www.w3.org/TR/soap12-part0/.
 Adrian Mocan and Emilia Cimpian. D13.3v0.2 WSMX Data Mediation.Technical report, Jan 2005. http://www.wsmo.org/2005/d13/d13.3/v0.2/.
 E. Motta, J. Domingue, L. Cabral, and M. Gaspari. IRS: A Framework and Infrastructure for Semantic Web Services. In 2nd International Semantic Web Conference, 2003.
 OWL Services Coalition. OWL-S: Semantic Markup for Web Services. Available from http://www.daml.org/services/owl-s/1.1/, 2004.
 Prof. Amit Sheth, Prof. John Miller, Kunal Verma. METEOR-S: Semantic Web Services and Processes. Available from http://lsdis.cs.uga.edu/Projects/METEOR-S/, 2004.
 D. Roman, H. Lausen, and U. Keller. Web Service Modeling Ontology Standard. Technical report, WSMO Working Draft, 2004. Available from http://www.wsmo.org/2004/d2/v02/20040306/.
 Maciej Zaremba and Eyal Oren. D13.2v0.2 WSMX Execution Semantics. Technical report, Feb 2005. http://www.wsmo.org/2005/d13/d13.2/v0.2/.
 Michal Zaremba. D23v1. WSMX System Functionality Scope. Technical report, Nov 2004. http://www.wsmo.org/2004/d23/v1/.
 Michal Zaremba and Matthew Moran. D13.4v0.2 WSMX Architecture. Technical report, Jan 2005. http://www.wsmo.org/2005/d13/d13.4/v0.2/.