Semantic Web Services Challenge 2006
Challenge on Automating Web Services Mediation,
Choreography and Discovery
organized by DERI Stanford

Phase I: March 8-10, 2006
Stanford University
Phase II: June 15-16, 2006
Budva, Montenegro
co-located with ESWC and the Knowledge Web Plenary

The goal of the SWS Challenge is to develop a common understanding of various technologies intended to facilitate the automation of mediation, choreography and discovery for Web Services using semantic annotations. The intent of this challenge is to explore the trade-offs among existing approaches. Additionally we would like to figure out which parts of problem space may not yet be covered. The workshop aims to provide a forum for discussion based on a common application. This Challenge workshop seeks participation from industry and academic researchers developing software components and/or intelligent agents that have the ability to automate mediation, choreography and discovery processes between Web services. best crypto trading platform in philippines

This Challenge is related to but distinct from the IEEE Contest in several respects. First, the SWS Challenge focuses on the use of semantic annotations: participants will be provided with semantics in the form of natural language text that they can formalize and use in their technologies. Second, this is a challenge rather than a contest, meaning that workshop particpants will mutually evaluate and learn from each others' approaches. Finally, because of this methodology, we will limit the number of participants to a relatively small group. There will be a publishing opportunity.

Challenge Organization

The SWS challenge consists of two very interactive and dynamic phases:

Phase I - Challenge Refinement: Participants present initial reports about the applicability of their technologies to the challenge problem. While the initial challenge problem has been already defined, the potential participants will meet to discuss the scope and details of the challenge requirements. Legacy software prepared for the purpose of this challenge will be distributed and comments will be collected to update and modify both the challenge and software to suit of the participants. Finally, we will jointly determine the best way to compare the results of Phase II.

Phase II - Solution Testing: Prior to the Phase II meeting, participants are asked to deliver a working solution and submit full papers describing their solution. These papers will be reviewed and a small working subset of the best will be invited to participate in Phase II based upon these papers. During the Phase II challenge workshop, participants will be asked to reconfigure their software to meet new requirements (as specified in challenge description). Participants will present their papers and then work on new challenge scenarios, presenting their results the following day.

Design Evaluation

The SWS is a challenge, not a competition. The complete set of comparison criteria will be defined during Phase I, the objective being to best arrive at a common understanding of the space of technologies. In general, solutions prepared for Phase II of SWS Challenge will be compared based on the design and functional capabilities of delivered components/agents.


For the Phase I participants are required to submit a technical description of their technology of no more than two (2) pages showing how their technology addresses described problems. Clarity and specific relevance to the scenario described will be of the utmost importance in the selection of participants.

For the Phase II we invite papers describing original contribution in data, service, and process integration. Papers should be no more than ten (10) pages in length. The selection criteria are the same as in Phase I.

For both Phases, submissions of a paper should be regarded as an commitment that, should the paper be accepted, the author(s) will attend the workshop to discuss their approach and further participate in onsite challenge. All submissions should be formatted in Springer's LNCS style [1], and sent by e-mail to

Problem Description (Challenge Phase I)

Data, process mediation, Web Services choreography and discovery are indispensable requirements to enable the interoperation of heterogeneous Web services. They are required by the emerging service-oriented architectures in order to facilitate the next-generation of e-Business applications. For the Phase II of this challenge, the participants are requested to provide an integration solution based on existing simplified RosettaNet PIP 3A4 [2] for the hypothetical MOON company.

bitcoin exchange philippines During this challenge participants pretend to be a team of IT professionals, employed by MOON, responsible for maintaining the integration between software systems of the company and the systems of its business partners. For this challenge we focus on the very basic and well-known scenario of sending Purchase Order Requests and receiving ReceiptAcknowledgements, then receiving Purchase Order Confirmation (POA) and sending back  ReceiptAcknowledgement as formalized by RosettaNet PIP 3A4. So you should basically implement the PO receiving role part of the interaction described in the PIP. As the company signed contracts with all of their partners to trade electronically using RosettaNet standards, all the external interfaces to interact with the MOON computer systems expects RosettaNet messages, sent in a sequence as described by the RosettaNet process.

While the external interfaces are standardized by the RosettaNet specification, internally MOON uses propriety legacy systems in which data model and message exchange patterns differ from those of RosettaNet. The legacy system is provided and may not be changed by any of challenge participants.

For this challenge participants are provided with:
(1) the interface of the legacy system in the form of a WSDL interface and textual description of the operations available at [3], and
(2) the RosettaNet specification for messages and message exchange pattern that must be supported for external communication (full specification is available at [2], but for the purpose of the challenge we simplified some of its aspects and describe it at [3]). The biggest difference is use of WSDL/SOAP instead of RosettaNet Implementation Framework solution and also the security and non-repudiation related issues are not that strict.

Every participant (team) is responsible for presenting how their approach to mediation choreography and discovery can be used to deliver the integration solution for this scenario. As part of this challenge, every participant should provide a standard WSDL interface available publicly on the Internet to which messages in RosettaNet format can be sent. It is responsibility of the participant to implement components/agent so that correct messages are forwarded to [3], which is provided by organizers of this challenge.

Problem Description (Challenge Phase II)

During the Phase II workshop, the challenge will be to revise, dynamically, the solution of Phase I of the Challenge according to the following three scenarios:

  1. Internal System Upgrade: The top management of the MOON company has been convinced by the vendor of the legacy system into buying an upgrade to the legacy system, which is again not compatible with the RosettaNet standard and it must be up and running ASAP. The interface of the internal legacy system [3] changes (the participants are provided with a new set of WSDL interfaces) and they must adjust their solutions to handle this new scenario.
  2. RosettaNet releases next version of PIP: In the next scenario, RosettaNet decides to go ahead with a new version of PIP. The MOON IT team must extend the existing interface so the new and/or extended messages and processes are supported by the existing integration components/agent.
  3. Discovery of new Business Partner: In this final scenario, MOON wants to find new supplier for some part. The challenge for the IT tema is twofold: a) give a formalization for a set of suppliers (described by the workshop organizers using PIPs and natural language) and b) illustrate the discovery algorithm used, showing that it can filter correctly unrelated operations (e.g. a availability notifications) and unrelated products or incompatible business terms. how to sell cryptocurrency philippines





Key Dates

1st Paper submission: 13 January, 2006

Acceptance Notification: 13 February, 2006

First Workshop: 8-10 March, 2006
Stanford University, Stanford, California

2nd Paper submission: 16 April, 2006

Acceptance Notification: 16 May, 2006

Second Workshop: 15-16 June, 2006
Budva, Montenegro


Charles Petrie, Stanford University, Palo Alto, USA

Steering Commitee:
Dieter Fensel, DERI Innsbruck & DERI Galway
Michael Genesereth, DERI Stanford
Frank Leymann, University of Stuttgartt
David Martin, SRI
Terry Payne, University of South Hampton
Norman Sadeh , CMU
Amit Sheth, University of Georgia & Semagix
Gordon Simpson, SAP USA
Stuart Williams, HP Labs Bristol,
Andreas Wombacher, University of Twente

Program Committee Co-Chairs:
Michal Zaremba,DERI Galway, and Holger Lausen, DERI Innsbruck

Program Committee Members:
Anupriya Ankolekar, AIFB, University of Karlsruhe
Christoph Bussler, CISCO
Siobhán Clarke, Trinity College
Liliana Cabral, Open University
Stefano Ceri, Politecnico di Milano
Dario Cerizza, CEFRIEL
Jos De Bruijn, DERI Innsbruck
Marin Dimitrov, Onto Text
John Domingue, Open University
Kuropka Dominik, Hasso-Plattner-Inst. für Softwaresystemtechnik
Paul Downey, BT
Christian Drumm, SAP
Martin Hepp, DERI Innsbruck
Michael Huhns, University of South Carolina
Silvestre Losada, ISOCO
Tiziana Margaria, University of Göttingen
E. M. Maximilien, IBM Almaden Research Center
Jeff Pan, University of Aberdeen
Axel Polleres, DERI Innsbruck
Marc Richardson, BT
Thomas Risse, Fraunhofer IPSI
Marta Sabou, Knowledge Media Institute, Open University
Munindar P. Singh, North Carolina State University
Emanuele Della Valle, CEFRIEL
Richard Waldinger, SRI
Holger Wache, Vrije University
Alexander Wahler, NIWA WEB Solutions
Sam Watkins, BT

Legacy (Moon) System Support: Daniel Janiaczyk
Contact for all technical questions: <>

Further Information

More information will be posted on this website in the near future.