D22 WSMX Documentation
From The Scuba Wiki
Contents |
Introduction
The Web Services Modeling Execution Environment (WSMX) is an execution environment for dynamic discovery, mediation and invocation of web services. WSMX is based on the Web Services Modeling Ontology (WSMO) [Roman et al., 2004], an ontology for describing various aspects related to Semantic Web Services. So far web services are mostly hard-wired into the provider's software and their abilities are not too sophisticated. Their main drawback is lack of semantic description and because of that it is difficult to perform automatic or semi-automatic service retrieval. WSMO aims to change this situation in order to fully enable web service functionality through adding semantic means that will result in web services vast proliferation. WSMX is a reference implementation and test bed environment for WSMO. Web Services Capability Description are stored in the WSMX repository and they are described in terms of logic expressions so they can be derived from. When service request (Goal) is sent to WSMX, then WSMX components start to perform their actions.
Purpose and Overview of this Document
This document provides the description of a step by step WSMX installation and examples of its usage. It starts with an installation guide and in the next section explains implementation details, especially the event architecture approach. Section 2 gives a guide of WSMX installation. Section 3 provides implementation details. Section 4 concludes the document and looks at future work.
WSMX Installation
In this section we explain a step by step WSMX installation on a Windows operating system. WSMX is currently available on the CVS on the SourceForge server (WSMX hosting site -http://sourceforge.net/projects/wsmx/).
Neccessary Software
Following software is necessary to run WSMX:
| Software | what it does | why we use it |
| J2SDK | Java™ Standard Edition 2, Software Development Kit(SDK) supports creating J2SE applications. | J2SDK supports the various WSMX components developed with Java. |
| Tomcat | Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. | Allows WSMX to deploy and test web services. |
| MySQL Server | an open source database. | Some components depend on a database system to retreive and store vasious files. |
| Eclipse | The Eclipse Platform is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as web sites, embedded JavaTM programs, C++ programs, and Enterprise JavaBeansTM. | Allows WSMX developers to dynamically compose and edit Java code. |
J2SE SDK
Step 1. Go to the following address: http://java.sun.com/j2se/1.5.0/download.jsp for downloading Java(TM) 2 SDK, Standard Edition 1.5.0.
Step 2. Run the installer j2sdk-1_5_0-windows-i586-p.exe you have just downloaded.
License Agreement: Follow the link from the Step 1 to find the license agreement.
Tomcat
Step 1. Download Tomcat and make sure that if you have downloaded J2SDK v1.5.0, that you also download Tomcat version 5 or greater. http://jakarta.apache.org/site/binindex.cgi#tomcat
Step 2. Run the startup.bat(windows) or startup.sh(linux) to start Tomcat and the shutdown.bat(windows) or shutdown.sh(linux) to stop Tomcat. These files can be run from the command line or found at; C:\my Program Files\tomcat\bin
License Agreement: Follow the link from the Step 1 to find the license agreement. The license agreement can also be found at; http://www.apache.org/licenses/LICENSE-2.0
Eclipse
Step 1. Download eclipse-SDK-3.0.1 from: http://www.eclipse.org/downloads/index.php
Step 2. Unpack the eclipse-SDK-3.0.1 -win32.zip file and run eclipse application file.
License Agreement: The license agreement can be found in ..\eclipse\notice.html
MySQL
Step 1. Download MySQL Server 4.1 http://dev.mysql.com/downloads/mysql/4.1.html
and MySQL Control Center http://dev.mysql.com/downloads/other/mysqlcc.html
Step 2. Unpack and run the execute files.
License Agreement: The license agreement can be found in at: http://www.mysql.com/products/licensing.html
Configuration
● create new database: wsmx.
● add new user login/pass: wsmx/wsmx, host: localhost. User should have all privileges to wsmx database.
Download WSMX from CVS at SourceForge
CVS (Concurrent Versions System) is a tool used by many software developers to manage changes within their source code tree. CVS provides the means to store not only the current version of a piece of source code, but a record of all changes (and who made those changes) that have occurred to that source code. Use of CVS is particularly common on projects with multiple developers, since CVS ensures changes made by one developer are not accidentally removed when another developer posts their changes to the source tree. Information about CVS client software may be found in our document titled, "Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services".
Once you have connected to the CVS successfully, you will see the WSMX folders divided into the various components outlined in Section 3. To begin editing code you must first create a BRANCH, then when the code has 'compiled' and 'run' without error, commit your work to the HEAD. The components various classes can be found at the following root;
COMPONENT/src/main/ie/deri/wsmx.....(various classes)
Anonymous access to CVS
This will allow the user to navigate through the WSMX project only for reading, using Eclpise.
● Start Eclipse and open the CVS perspective.
● Right-click on the CVS pane and create “new CVS repository location”.
● Add the following details:
connection type: pserver
user: anonymous
host: cvs.sourceforge.net
repository path: /cvsroot/wsmx
SSH access to CVS
This will allow the user to be part of the WSMX development team.
You must complete the following steps;
- Create an account at SourceForge.net. No nicknames for username, simply, FirstnameLastname and a password.
- Contact Michal.Zaremba@deri.org so that he may register you as a WSMX developer.
- Generate encryption keys and post the public encryption key at SourceForg. Do this as follows;
You need to download PUTTYGEN.exe from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. Complete the following steps;
1. Execute PUTTYGEN.EXE
2. Select the desired key type ("SSH2 DSA", within the "Parameters" section).
3. Click on the "Generate" button.
4. Follow the on-screen instructions ("Please generate some randomness by moving the mouse over the blank area"). Key generation will be performed immediately afterward.
5. Enter username@shell.sf.net (or username@cf.sf.net) in the "Key comment" field, replacing 'username' with your SourceForge.net user name. This comment will help you to identify the purpose of this key.
6. Enter the desired passphrase in the "Key passphrase" and "Confirm passphrase" fields.
7. Click on the "Save private key" button; use the resulting dialog to save your private key data for future use. You may use a filename such as "SourceForge-Shell.ppk" or "SourceForge-CF.ppk". The .ppk extension is used for PuTTY Private Key files.
8. Go to the SSH key posting page on the SourceForge.net site (http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1#keyposting). Copy your public key data from the "Public key for pasting into OpenSSH authorized_keys2 file" section of the PuTTY Key Generator and paste in to the provided form on the SourceForge.net site.
For extra documentation please go to http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1#keygenopenssh
- Access CVS via Eclipse as in section 2.2.1 but changing the following;
connection type: extssh
username and password: that you created when registering with SourceForge.net.
Further Settings
Environmental Variables
Choose Start, Settings, Control Panel, and double-click System. Select the Advanced tab and then Environment Variables. Look for "Path" in the User Variables and System Variables. If you're not sure where to add the path, add it to the right end of the "Path" in the User Variables. A typical value for PATH is:
C:\jwsdp-1.5\bin
Capitalization doesn't matter. Click "Set", "OK" or "Apply". The PATH can be a series of directories separated by semi-colons (;). Microsoft Windows looks for programs in the PATH directories in order, from left to right.
Following System Environment Variables should be set:
● JAVA_HOME - e.g. c:\Java\j2sdk
● CLASSPATH - e.g. c:\Java\j2sdk\lib
● Tomcat_HOME - e.g. c:\Java\Tomcat
● WSMX_HOME - e.g. d:\development\webapp\wsmx
WSMX configuration
Some WSMX components are running as Web Services (e.g. compiler, adapters) that are deployed using Apache Axis libraries that are compiled into WSMX. Particular policies for deployed application on Tomcat server must be specified so you can restrict or grant permissions to system resources and system functions (e.g. write file, connect, resolve for particular java libraries etc.).
WSMX configuration files:
● $(USER_HOME)\wsmx.properties - specifies connection to JDBC, login/password, paths to log4j properties files, etc.,
● $(WSMX_HOME)\build.properties - specifies paths to JDBC driver librarites,
● $(WSMX_HOME)\bin\startWSMX.bat - starts WSMX,
WSMX Usage
WSMX as an Event Driven Architecture
In this section we provide WSMX Usage description and an overview of WSMX approach to handling incoming messages and its internal workflow policy.
WSMX is a Event Driven Architecture. This means that there are no direct invocation between components. Each component is subscribed to the WSMX Manager listener and has its type and status. Type specifies data type of the Event (e.g. WSML_MESSAGE, NON_MEDIATED_OBJECT, MEDIATED_OBJECT). Examples of event's status are: BEFORE_PARSING, AFTER_PARSING, ERROR, CONSUMED etc. Each component expects certain Event status and type respectively. When new Event appears in system then all components that are subscribed as a listeners receive information that there is an Event to pick up. There is a notion of double lock. When component enters its critical path (i.e. check what is the type and status of an awaiting Event) then the first lock is imposed in order to avoid checking this Event by other components. If appropriate then the second lock is imposed and it means that the particular Event is being processed by a component.
WSMX Entry Point
There are two entry points to WSMX:
● WSMX Manager - receives WSML goal from the back-end application, then it creates an Event for this message that is picked up next by the WSMX components. Entry point is depicted on the Figure 1 this on left hand side. If the back-end application output format is other than WSML, it is necessary to send it first to the adapter that performs a format conversion and then forwards a WSML message to WSMX manager.
● WSMX Compiler - receives Web Service Capability Description from WSMX Editor and if appropriate adds this Capability to its repository. WSMX-Compiler is a Web Service application, is does not create an Event. It is depicted as topmost element on the following diagram, Archtecture image: File:Architecture.jpg
WSMX Components
This section details each of the components listed in the architecture and describes them under three headings; 1) Introduction, 2) Functionality and 3) how to run a test program.
Adapter Framework
1. Introduction
Adapters reside as an intermediary between incompatible systems and facilitate communication between them. To enable compatibility an adapter converts data presented in one format to another. Depending on the system and business application, adapters can be used individually or grouped in clusters for more complex usage. The clusters are designed as frameworks where adapters can be plugged -in or -out according to the communication needs.
2. Functionality
On the conceptual level, an adaptor transforms the received message from its source format to the target format. The transformation is concerned only with the syntactic mapping between message formats, leaving the semantics of the message intact. The semantic part is enforced by personalized ontologies that are used to build the outgoing message format. The main problem tackled by the WSMX adaptor framework is the transformation from UBL (XML) into the language comprehensible by WSMX (WSML). The syntactic mapping between ontologies in different formats is done by extracting the instances from the source ontology fragment, then mapping them and finally populating the target WSML ontology fragment.
3. Test program
A new component emulates WSMX behavior (fake WSMX) in receiving and replying back messages to the adaptor framework. Test messages are sent in XML via the back-end application; XML2WSML adapter transforms this XML into WSML and forwards the message to the fake WSMX. The fake WSMX replies back a WSML message following the logic hard coded in it for that specific test. WSML2XML Adapter transforms back the reveiced WSML to XML and forwards it to the back-end application.
Choreography
1. Introduction
A choreography defines how to interact with the web service in terms of exchanging messages, the so called communication patterns. It describes how a requester can interact with the service provider (in the case of a WSMX execution a Web Service). The requestor of the service has its own communication pattern and only if the two of them match precisely, a direct communication between the requestor and the provider of a service may take place. By matching precisely we understand the full matching of the communication pattern from the source and target parties, also called process equivalence. That means that for each possible instance of the source choreography at least one instance of the target choreography is available. Since usually the client has its own communication pattern that in general is different from the one used by the Web Service, the two of them will not be able to directly communicate, even if they are able to understand the same data formats. In order to invoke the Web Service the two parties must either redefine their communication patterns (or at least one of them) or to use an external mediation system as part of the process. The second approach is exactly what the WSMX choreography engine tries to achieve. The role of the Choreography Engine is to put together the necessary means for the runtime analyses of two given choreography instances and to use the mediators to compensate the possible mismatches that may appear, for instance, to generate dummy acknowledgement messages, to group several messages in a single one, to change their order or even to remove some of the messages in order to facilitate the communication between the two parties. The above presented functionality is based on a design time process which identifies the equivalences between the choreographies’ conceptual descriptions, that is, a set of rules are created and stored, in order to be later applied on the particular choreography instances, during runtime.
2. Functionality
In the first release of the Choreography component we intend to provide a simplified matching of correspondent nodes of stored Choreographies. Nodes are defined by a databinding, a nextnode parameter and an identifier. For the first version there are no dependencies on other components. This will change when mediation will be considered to overcome process heterogeneities. Currently no mediation is performed, which implies that no communication can take place if the choreographies of the provider and requester are not equal.
3. Test program
There is no Test program implemented yet.
Mediator
1. Introduction
WSMX Data Mediation Component has the role of reconciliation the data heterogeneity problems that can appear during discovery, composition, selection or invocation of Web Services. This component offers support for both the runtime phase and design time phase of the mediation process. That is, the design-time subcomponent offers a graphical interface that assists the user in the creation of mappings and the run-time component makes use of the already created mappings and performs the actual data transformation in a completely automatic manner. In fact, only the second subcomponent is explicitly part of the WSMX architecture, but its functionality is enabled by the outputs of the design-time component.
2. Functionality
Design-time component
This component consists of a graphical interface that offers support to the domain expert placing its inputs (i.e. mappings). The user can browse the ontology and can decide, based on the offer suggestion, what mappings would be more suited to capture the semantic similarities of the two ontologies. When the process is completed the mappings are stored in an external storage for further usage (by the run-time component or by the domain expert for further refinements). The main dependencies of this component are on the lexical analyser level and on the storage level. For the lexical analyser a critical requirement is that WordNet has to be installed on the machine where the mediation component runs. As for the storage used by the mediation component for saving the mappings, it is in the current version an independent relational database (MySQL Server is used). For the future versions some of the functionality offered by this storage will be covered by WSMX persistency layer, and as a consequence, the mediation storage will be the subject of important restructurings.
Run-time Component
The run-time component has the role to retrieve from the storage the already created mappings, to transform them in rules and finally to execute them against the incoming instances in order to obtain the target instances. Since the mappings represents the connection point between the two sub-components (design-time and run-time) one of the dependencies for run-time component is on the mapping storage level as well. Another crucial dependency is the reasoning system used for executing the rules in the final stage of the mediation process. For this, Flora2 engine together with its underlying system, XSB Prolog, are used; they are integrated in Java by using InterProlog, a Java front-end and enhancement for XSB Prolog. The installation of this system is completely handled by a set of scripts coming with the mediation component, without any burdensome from the user side.
3. Test program
The design time component is meant to be run as a stand-alone applications (as is mentioned in a previous section, it is not explicitly part of the WSMX architecture). The component can be started by running: ie.deri.wsmx.mediation.ooMediator.newgui.RunMe.java On the other hand, the runtime component is explicitly part of the WSMX architecture and it is invoked by WSMX each time data mediation is required. In addition the design-time component contains a special panel that allows you to simulate a WSMX invocation on the runtime component. In this way you can very easy test this component and also the results of the mappings that have been just created.
Parser/Compiler
1. Introduction
The parser performs syntactic validity checks of WSML documents provided by the execution manager. It determines whether a WSML document can be processed and converts it into an internal representation. The parser makes use of the WSMO API, which defines methods for validating a document against a certain WSML variant and returning a memory-model of the elements of the document. The WSMO API is complemented by a reference implementation, which includes a parser to check the validity of documents against a certain WSML variant. The reference implementation returns an in-memory model of the elements of the parsed document. This in-memory representation is passed to the DBManager for persistent storage.
2. Functionality
- parses wsml file and stores content in persistent storage
depends on:
- wsmo4j parser for parsing
- dbManager for storage.
3. Test program
run main method in AlphaParser.java.
Discovery
1. Introduction
Discovery Component of WSMX will provide a full implementation of discovery mechanism provided in WSMO Discovery Error! Reference source not found.. This component is developed within the deliverable D5.2: WSMO Discovery Engine Error! Reference source not found.. Different tools and formalisms are tested to see which of them are more suitable for what is needed. For keyword-based discovery described in D5.2 a simple implementation is already available and integrated with WSMX. Future plans for implementation include the distributed discovery.
2. Functionality
In this section the implementation of keyword-based discovery functionality is provided. Two methods can be used if the keyword-based discovery functionality is required. These are: matchByGlobaNFP and matchByAxiomNFP.
The matchByGlobaNFP method performs a keyword-based match over the NFP of the goal description and web services descriptions. Given a Goal, a set of known Web Services and a KeywordDiscoveryPreference this method returns a set of match services. A KeywordDiscoveryPreference contains the NFP attribute over which the keyword search is performed, the type of match (Full match or Partial match) and the threshold, which is used only if the type of match is Partial. For the Full match the whole value of the NFP attribute from the goal is compared with the whole value of the each web service. For the Partial match individual keywords from the goal NFP are compared with initial keywords from the web services NFP and a score is computed for each service. These score is normalized and then in the selection process only the normalized scores that have a bigger value then the given threshold are selected.
The matchByAxiomNFP method performs a keyword-based match over the NFP of the axioms that describe goal postconditions and NFP of the axioms that describe service capabilities and postconditions. The algorithm is the same as in matchByGlobaNFP method but applied to NFP attributes of the axioms that define the postconditions of the goal and web services.
The next step is to investigate how distributed discovery can be performed in WSMX. In order to discover other WSMXes we envision three fundamental approaches. The first one is an UDDI 0 like approach that uses a central repository where different WSMXes are registered. The second approach uses a P2P infrastructure. Finally the third approach is based on Triple Space paradigm Error! Reference source not found.. We think that the last two approaches are more suitable for WSMX distributed discovery, the UDDI approach being a too centralize approach.
For the next version of the Discovery component we will investigate and implement P2P distributed discovery for WSMX. We see two options to build the P2P infrastructure: the first one is based on JXTA Error! Reference source not found., the second one, which we call it “Hypercube” approach is described in Error! Reference source not found.. On top of the P2P network we will implement the distributed discovery mechanism.
3.Test program
To test the keyword-based discovery a simple JTest Unit is provided. This program test can be as a standalone program, and it dose not required any parameters. Using the wsmo4j we create the goal and web services java objects that are needed for the discovery process. The functionality of matchByGlobaNFP and macthByAxiomNFP is tested. These methods return a set of matched services given a goal and a set of known services. The test program returns how many web services were matched for each method.
Communication Manager
1. Introduction
The Communication Manager is responsible for sending and receiving WSML messages to/from entities external to WSMX or adapters representing such external entities. In this context, the term entity means any external system acting as a service requester as well as services that can be invoked by WSMX adapters are expected to be used where the external entity does can not directly support communication using WSML messages and translation to another data representation is required. Translation from WSML to another data representation is often referred to as ‘lowering’ while translation from another data representation to WSML is often referred to as ‘lifting’. The two central functionalities of the Communication Manager - sending and receiving messages - are described in the next sections.
2. Functionality
Sending Messages The Communication Manager provides an interface to receive the WSMO description of the service to be invoked along with data to be sent in the message to the service. The data must consist of instances of concepts described in the ontology used by the service. Both the service description and data will be represented in WSML. The Communication Manager interprets the interface part of the service description to determine which binding is necessary to invoke the service or, the adapter representing the service, where one is required.
Receiving Messages The Communication Manager provides an interface to external entities to accept WSML messages. The WSML messages may represent a goal to be achieved by another WSMX instance or be a message corresponding to a choreography or orchestration instance that already exists. From the perspective of the Communication Manager, the distinction is irrelevant. The Communication Manager accepts the message, handling any transport and security protocols used by the sending adapter.
3. Test program
The Communication Manager will be provided with a set of unit tests that can be run using the JUnit (http:\\www.junit.org ) test framework.
Resource Manager
1. Introduction
The WSMX Resource Manager is responsible for storing every data WSMX uses. Because WSMX is developed with the programming language Java and and every data is represented as a Java object, the resource manager uses an O/R-Mapper for storing the data. An O/R-Mapper provides functionality to map an object oriented data model to a relational data model, i.e. a database.
2. Functionality
The domain model of WSMX is based on the WSMO API which is just a set of interfaces representing the data structure of WSMO 1.0. The Resource Manager provides an implementation of those interfaces which should be used to transfer data between every WSMX component. The implementation is independent of the O/R-Mapping. The O/R-Mapper which is used by the resource manager is Hibernate (http://www.hibernate.org). The information how Hibernate should map the Java objects to the database is stored in XML files. Out of those files Hibernate is managing the whole database, the structure of the tables and the data itself. Besides Hibernate the resource manager uses the Springframework (http://www.springframework.org) to manage the connection to Hibernate. Spring is a lightweight container which provides a generic access to different O/R-Mapping tools and strategies. This makes it easier to switch to other tools or strategies without influencing the application.
For accessing the data/objects with data from the database the resource manager uses the Data Access Object (DAO)– design pattern. This means that there is for almost every object of the domain model a class with store/update and several find-methods. On top of those DAOs is a single manager facade which simply provides the access to every DAO. This is the single entry point/interface to the resource manager. So for loading/storing the objects of the domain model only the interface of the manager facade should be used.
3. Test program
There is a simple client class with a main method which generates some objects, tries to store and update them and then load them again from the database. Besides this every DAO has its own Junit test case which tests every functionality provided by this DAO.
Core Components
Pending…(Michal)
WSMX Dependent Libraries
|
Dependent Library
|
.jar
|
Location | Purpose | Dependent Component |
| activation | activation | activation/lib | contains the classes that make up the JavaBeans Activation framework. It allows developers to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and to instantiate the appropriate bean to perform said operation(s). | Adapter, backend |
| apache-axis | axis-ant | apache-axis/axis-1_2RC2/ant-lib | Axis comes with Ant tasks to automate aspects of the build process inside ant. | Adapter, backend |
| axis | apache-axis/axis-1_2RC2/lib | Apache Axis is an implementation of the SOAP submission to W3C | ||
| commons-discovery | ||||
| commons-httpclient-3.0-alpha1 | ||||
| commons-logging | ||||
| jaxrpc | ||||
| log4j-1.2.8 | ||||
| saaj | ||||
| wsdl4j | ||||
| apache-commons | commons-beanutils | apache-commons/lib | defines a simple interface for a pool of object instances, and a handful of base classes that may be useful when creating pool implementations. | Adapter, backend |
| commons-collections | ||||
| collections-2.0 | ||||
| commons-dbcp | ||||
| commons-discovery | ||||
| commons-fileupload | ||||
| commons-httpclient | ||||
| commons-lang | ||||
| commons-logging | ||||
| commons-pool | ||||
| commons-validator | ||||
| apache-log4j | log4j-1.2.8 | apache-log4j/lib | With log4j it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that these statements can remain in shipped code without incurring a heavy performance cost. Logging behavior can be controlled by editing a configuration file, without touching the application binary. | Adapter, backend |
| apache-tomcat | catalina-ant | Tomcat is a free, open-source implementation of Java Servlet and JavaServer Pages technologiewshich allows WSMX to deploy and invoke web services | ||
| declarativa-interprolog | interprolog | declarativa-interprolog/lib | mediator | |
| dtd-parser | dtd_parser | dtd-parser/lib | mediator | |
| jboss-client | jboss | jboss-client/lib | An Enterprise JavaBean(EJB) encapsulates business logic in a component framework that manages the details of security, transaction, and state management. Low-level details such as multi-threading, resource pooling, clustering, distributed naming, automatic persistence, remote invocation, transaction boundary management, and distributed transaction management are handled by the EJB "container." | Choreography, Communication Manager, Core, Discovery, Matchmaker, ooMediator |
| jbossall-client | ||||
| jboss-plastic | jboss-j2ee | jboss-plastic/lib | ||
| jena | jena | jena/lib | Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, including a rule-based inference engine. | core, matchmaker |
| junit | junit | junit/lib | dbManager | |
| mail/lib | Adapter, backend | |||
| mysql | mysql-connector | mysql/lib | dbManager | |
| mysql-java-3.0.16 | ||||
| mysql-ga-bin | ||||
| spring | c3p0-0.8.4.5 | spring/lib | dbManager | |
| cglib-full-202 | ||||
| dom4j | ||||
| hibernate2 | ||||
| hsqldb | ||||
| jdbc2.0-stdext | ||||
| jta | ||||
| log4j | ||||
| admg | ||||
| spring | ||||
| wordnet | commons-logging | wordnet/lib | mediator | |
| jwnl | ||||
| wsmlparser | wsmlparser | wsmlparser | parser | |
| wsmo4j | wsmo4j | wsmo4j | parser | |
| wsmoapi | wsmoapi | wsmoapi | core, dbManager, parser | |
| xdoclet-xdoclet | commons-logging | xdoclet-xdoclet/lib | ||
| xdoclet-1.2.2 | ||||
| xdoclet-bea-module-1.2.2 | ||||
| xdoclet-ejb-module-1.2.2 | ||||
| xdoclet-hibernate-module-1.2.2 | ||||
| xdoclet-java-module-1.2.2 | ||||
| xdoclet-jboss-module-1.2.2 | ||||
| xdoclet-jdo-module-1.2.2 | ||||
| xdoclet-jmx-module-1.2.2 | ||||
| xdoclet-spring-module-1.2.2 | ||||
| xdoclet-web-module-1.2.2 | ||||
| xdoclet-xdoclet-module-1.2.2 | ||||
| xdoclet-xjavadoc-1.2.2 | ||||
| xmlsec | xmlsec | xmlsec/lib | ||
| tools | ant | tools/lib | ||
| tools | buildmagic-tasks | tools/lib | ||
| tools | optional | tools/lib |
Conclusions and Further Directions
This document presents the general overview of the WSMX first release Implementation Installation and Usage. Although first WSMX version remains incomplete in terms of its functionality, it is already able to pass incoming WSML messages throughout the system and match simple goals. A great effort has to be put into further development of the WSMX components. There are ongoing works on developing expressivity of WSML language and its reasoner. Most crucial parts in current version are Matchmaker (demands logic reasoning) and OOMediator (import ontologies and resolve possible representation mismatches between ontologies). In current implementation there is only OOMediator for simplicity reason, whilst in WSMO [Roman et al., 2004] there are many more Mediators describedIn next WSMX version new components will be introduced. There might be the following components:
● WWMediator - link two Web Services,
● MessageManager - in current version communication is two-way communication for which we need a special component. There are additional issues with regard to communication, for example, a return message may need to be mediated and/or send through some dedicated adapter if back-end application doesn't speak WSML language,
● CorrelationManager - in some cases in order to execute Web Service some conditions must be fulfilled, for example, it is required to check if telecom provider can provide ADSL line for a particular phone number before ordering a line (see Niva use case). So new sub-events need to be created in order to determinate whether execution conditions are fulfilled or not. The main Event should be put to sleep and when the sub-events are finished, it should be woken up and check if the sub-events results allows him to invoke Web Service.
Additionally WSMX should use WSIF (Web Services Invocation Framework) in order to separate invocation from technical issues (e.g. SOAP message document style or RPC-style). In the current version, execution semantics is hard-wired in Java code. Each component expects particular Event type and status, and execution logic (i.e. condition branching) is coded in Java as well. In order to make execution semantics more flexible we introduce a workflow engine to run WSMX based on sound theoretical foundations (e.g. Petri Nets). It could be YAWL [van der Aalst et al., 2004] , it has a good theoretical basis (i.e. one can simulate and analyze any potential deadlocks). This approach would make WSMX semantic execution far more flexible, however, it also needs to create a proper interface for objects. One of the most important demands for workflow engine is asynchronous execution. If possible, workflow has to switch between transitions (invoking components) to avoid awaiting for particular components to responsed.
References
[van der Aalst et al., 2004] W.M.P. van der Aalst, L. Aldred, M. Dumas, and A.H.M. ter Hofstede, Design and implementation of the YAWL system, http://www.citi.qut.edu.au/yawl/ docs_for_yawl/yawls.pdf
[Roman et al., 2004] D. Roman, H. Lausen, U. Keller. Web Services Modeling Ontology -Standard (WSMO - Standard), http://www.wsmo.org/2004/d2/v0.2/20040306/
Acknowledgments
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, and SWWS; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the CoOperate program.
The editors would like to thank all the members of the WSMO working group for their advice and inputs to this document.
